public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 04/10] wal_compression_method: default to zlib..
3+ messages / 3 participants
[nested] [flat]
* [PATCH 04/10] wal_compression_method: default to zlib..
@ 2021-03-11 23:36 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Justin Pryzby @ 2021-03-11 23:36 UTC (permalink / raw)
this is meant to exercise the CIs, and not meant to be merged
---
src/backend/access/transam/xlog.c | 2 +-
src/backend/utils/misc/guc.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 6eb46ea8a7..f5d4450654 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_PGLZ;
+int wal_compression_method = WAL_COMPRESSION_ZLIB;
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 8084027465..c37a8313d3 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -1269,7 +1269,7 @@ static struct config_bool ConfigureNamesBool[] =
NULL
},
&wal_compression,
- false,
+ true,
NULL, NULL, NULL
},
@@ -4728,7 +4728,7 @@ static struct config_enum ConfigureNamesEnum[] =
NULL
},
&wal_compression_method,
- WAL_COMPRESSION_PGLZ, wal_compression_options,
+ WAL_COMPRESSION_ZLIB, wal_compression_options,
NULL, NULL, NULL
},
--
2.17.0
--jozmn01XJZjDjM3N
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0005-re-add-wal_compression_method-lz4.patch"
^ permalink raw reply [nested|flat] 3+ messages in thread
* Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13)
@ 2023-01-10 07:43 Michael Paquier <[email protected]>
2023-01-10 07:57 ` Re: Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13) Tom Lane <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Michael Paquier @ 2023-01-10 07:43 UTC (permalink / raw)
To: Postgres hackers <[email protected]>; +Cc: Imseih (AWS), Sami <[email protected]>; Nathan Bossart <[email protected]>
Hi all,
The problem mentioned in $subject has been discussed here:
https://www.postgresql.org/message-id/[email protected]...
Ths issue has been fixed by 947789f, without a backpatch to v12 (as
per 96cdeae) as the risk seemed rather limited seen from here, back
when the problem was discussed. Unfortunately, I have seen customer
deployments on v12 and v13 playing with pg_database entries large
enough that they would have toast entries and would be able to trigger
the problem fixed in v14 at the end of a vacuum.
Any objections about getting 947789f applied to REL_13_STABLE and
REL_12_STABLE and see this issue completely gone from all the versions
supported?
Thanks,
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13)
2023-01-10 07:43 Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13) Michael Paquier <[email protected]>
@ 2023-01-10 07:57 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2023-01-10 07:57 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Postgres hackers <[email protected]>; Imseih (AWS), Sami <[email protected]>; Nathan Bossart <[email protected]>
Michael Paquier <[email protected]> writes:
> Any objections about getting 947789f applied to REL_13_STABLE and
> REL_12_STABLE and see this issue completely gone from all the versions
> supported?
No objections to back-patching the fix, but I wonder if we can find
some mechanical way to prevent this sort of error in future. It's
surely far from obvious that we need to apply heap_inplace_update
to a raw tuple rather than a syscache entry.
A partial fix perhaps could be to verify that the supplied tuple
is the same length as what we see on-disk? It's partial because
it'd only trigger if there had actually been a toasted-field
expansion, so it'd most likely not catch such coding errors
during developer testing.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2023-01-10 07:57 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-03-11 23:36 [PATCH 04/10] wal_compression_method: default to zlib.. Justin Pryzby <[email protected]>
2023-01-10 07:43 Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13) Michael Paquier <[email protected]>
2023-01-10 07:57 ` Re: Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13) 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