public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 6/8] Default to LZ4.. 3+ messages / 3 participants [nested] [flat]
* [PATCH 6/8] Default to LZ4.. @ 2021-03-12 21:35 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 3+ 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/utils/misc/guc.c | 2 +- 3 files changed, 7 insertions(+), 5 deletions(-) diff --git a/configure b/configure index 9b590eb432..3afa1e87e3 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 2b3b5676eb..d62ea5f742 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/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 --f0KYrhQ4vYSV2aJu Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0007-add-wal_compression_method-zstd.patch" ^ permalink raw reply [nested|flat] 3+ messages in thread
* evtcache: EventTriggerCache vs Event Trigger Cache @ 2023-05-04 11:38 Daniel Gustafsson <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Daniel Gustafsson @ 2023-05-04 11:38 UTC (permalink / raw) To: PostgreSQL Hackers <[email protected]> When reading a memory contexts log I realized that we have this: LOG: level: 2; EventTriggerCache: 8192 total in 1 blocks; 7928 free (4 chunks); 264 used LOG: level: 3; Event Trigger Cache: 8192 total in 1 blocks; 2616 free (0 chunks); 5576 used The reason is that BuildEventTriggerCache sets up a context "EventTriggerCache" which house a hash named "Event Trigger Cache" which in turn creates a context with the table name. I think it makes sense that these share the same name, but I think it would be less confusing if they also shared the same spelling whitespace-wise. Any reason to not rename the hash EventTriggerCache to make the logging a tiny bit easier to read and grep? -- Daniel Gustafsson ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: evtcache: EventTriggerCache vs Event Trigger Cache @ 2023-05-04 12:09 Tom Lane <[email protected]> parent: Daniel Gustafsson <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Tom Lane @ 2023-05-04 12:09 UTC (permalink / raw) To: Daniel Gustafsson <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]> Daniel Gustafsson <[email protected]> writes: > When reading a memory contexts log I realized that we have this: > LOG: level: 2; EventTriggerCache: 8192 total in 1 blocks; 7928 free (4 chunks); 264 used > LOG: level: 3; Event Trigger Cache: 8192 total in 1 blocks; 2616 free (0 chunks); 5576 used > The reason is that BuildEventTriggerCache sets up a context "EventTriggerCache" > which house a hash named "Event Trigger Cache" which in turn creates a context > with the table name. I think it makes sense that these share the same name, > but I think it would be less confusing if they also shared the same spelling > whitespace-wise. Any reason to not rename the hash EventTriggerCache to make > the logging a tiny bit easier to read and grep? Hmm, I'm kinda -1 on them having the same name visible in the contexts dump --- that seems very confusing. How about naming the hash "EventTriggerCacheHash" or so? regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2023-05-04 12:09 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-03-12 21:35 [PATCH 6/8] Default to LZ4.. Justin Pryzby <[email protected]> 2023-05-04 11:38 evtcache: EventTriggerCache vs Event Trigger Cache Daniel Gustafsson <[email protected]> 2023-05-04 12:09 ` Re: evtcache: EventTriggerCache vs Event Trigger Cache Tom Lane <[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