public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 06/10] Default to LZ4.. 2+ messages / 2 participants [nested] [flat]
* [PATCH 06/10] Default to LZ4.. @ 2021-03-12 21:35 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Justin Pryzby @ 2021-03-12 21:35 UTC (permalink / raw) this is meant to exercise in the CIs, and not meant to be merged --- configure | 6 ++++-- configure.ac | 4 ++-- src/backend/access/transam/xlog.c | 2 +- src/backend/utils/misc/guc.c | 2 +- 4 files changed, 8 insertions(+), 6 deletions(-) diff --git a/configure b/configure index fed440adcf..8d76be00c1 100755 --- a/configure +++ b/configure @@ -1575,7 +1575,7 @@ Optional Packages: --with-system-tzdata=DIR use system time zone data in DIR --without-zlib do not use Zlib - --with-lz4 build with LZ4 support + --without-lz4 build without LZ4 support --with-gnu-ld assume the C compiler uses GNU ld [default=no] --with-ssl=LIB use LIB for SSL/TLS support (openssl) --with-openssl obsolete spelling of --with-ssl=openssl @@ -8598,7 +8598,9 @@ $as_echo "#define USE_LZ4 1" >>confdefs.h esac else - with_lz4=no + with_lz4=yes + +$as_echo "#define USE_LZ4 1" >>confdefs.h fi diff --git a/configure.ac b/configure.ac index 8c454128bb..bfcdc88be0 100644 --- a/configure.ac +++ b/configure.ac @@ -990,8 +990,8 @@ AC_SUBST(with_zlib) # LZ4 # AC_MSG_CHECKING([whether to build with LZ4 support]) -PGAC_ARG_BOOL(with, lz4, no, [build with LZ4 support], - [AC_DEFINE([USE_LZ4], 1, [Define to 1 to build with LZ4 support. (--with-lz4)])]) +PGAC_ARG_BOOL(with, lz4, yes, [build without LZ4 support], + [AC_DEFINE([USE_LZ4], 1, [Define to 1 to build without LZ4 support. (--without-lz4)])]) AC_MSG_RESULT([$with_lz4]) AC_SUBST(with_lz4) diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 984ce39cc7..3657f74de9 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -99,7 +99,7 @@ bool EnableHotStandby = false; bool fullPageWrites = true; bool wal_log_hints = false; bool wal_compression = false; -int wal_compression_method = WAL_COMPRESSION_ZLIB; +int wal_compression_method = WAL_COMPRESSION_LZ4; char *wal_consistency_checking_string = NULL; bool *wal_consistency_checking = NULL; bool wal_init_zero = true; diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c index c37a8313d3..52f9cd0242 100644 --- a/src/backend/utils/misc/guc.c +++ b/src/backend/utils/misc/guc.c @@ -4728,7 +4728,7 @@ static struct config_enum ConfigureNamesEnum[] = NULL }, &wal_compression_method, - WAL_COMPRESSION_ZLIB, wal_compression_options, + WAL_COMPRESSION_LZ4, wal_compression_options, NULL, NULL, NULL }, -- 2.17.0 --XsQoSWH+UP9D9v3l Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0007-add-wal_compression_method-zstd.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Make COPY format extendable: Extract COPY TO format implementations @ 2025-02-05 07:31 Sutou Kouhei <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Sutou Kouhei @ 2025-02-05 07:31 UTC (permalink / raw) To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; pgsql-hackers Hi, In <[email protected]> "Re: Make COPY format extendable: Extract COPY TO format implementations" on Tue, 04 Feb 2025 17:46:10 +0700, Vladlen Popolitov <[email protected]> wrote: > I think, in case of USING PostgreSQL kernel will call corresponding > handler, > and it looks secure - the same as for table and index methods > handlers. We use similar approach that is used by table sampling method. We can use a new table sampling method by just adding a "method_name(internal) RETURNS tsm_handler" function. Is it not secure too? > If you add extensibility, than every handler will be the > extension, that can handle one or more formats. Hmm. It may be a needless extensibility. Is it useful? I feel that it increases complexity when we implement a custom format handler. We can just implement one handler per custom format. If we want to share implementation details in multiple handlers, we can just share internal C functions. If we require one handler per custom format, it'll simpler than one handler for multiple custom formats. >>> it assumes some SetOptions interface, that defines >>> an options structure according to the new method requirements. >> Sorry. I couldn't find the SetOptions interface in source >> code. I found only AT_SetOptions. Did you mean it by "some >> SetOptions interface"? > Yes. >> I'm familiar with only access method. It has >> IndexAmRoutine::amoptions. Is it a SetOptions interface >> example? > Yes. I think, it would be compatible with other modules > of source code and could use the same code base to process > options of COPY TO/FROM Thanks. I thought that there is a common interface pattern for SetOptions. But it seems that it's a feature that is implemented in many extension points. If we implement custom options support eventually, does it satisfy the "SetOptions interface"? Thanks, -- kou ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-02-05 07:31 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-03-12 21:35 [PATCH 06/10] Default to LZ4.. Justin Pryzby <[email protected]> 2025-02-05 07:31 Re: Make COPY format extendable: Extract COPY TO format implementations Sutou Kouhei <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox