agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedFrom: Jeff Davis <pgsql@j-davis.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Jeff Davis <jdavis@postgresql.org>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Perform provider-specific initialization in new functions.
Date: Tue, 21 Apr 2026 21:48:17 -0700
Message-ID: <4524ed61a015d3496fc008644dcb999bb31916a7.camel@j-davis.com> (raw)
In-Reply-To: <2153399092d446bc1137eee5f70ad7af70e9039e.camel@j-davis.com>
References: <E1tINJx-000sMi-Vr@gemulon.postgresql.org>
<D18AD72A-5004-4EF8-AF80-10732AF677FA@yandex-team.ru>
<dba69ec2334f9cff04d102de243ea912a3166586.camel@j-davis.com>
<2FCB31FC-43E9-45F6-9AF4-4E199132B4E5@yandex-team.ru>
<9e74ecd519ac5a1a2a5fefec86d261037f3db311.camel@j-davis.com>
<2153399092d446bc1137eee5f70ad7af70e9039e.camel@j-davis.com>
On Thu, 2026-04-16 at 11:42 -0700, Jeff Davis wrote:
> I plan to commit this soon.
>
> I don't plan to backport unless someone sees a reason that it should
> be
> backported (and if so, how far?).
Actually, this does need to be backported, a NULL pointer dereference
is easily reproducible on master and v18:
PGOPTIONS="-c zero_damaged_pages=on" \
pg_receivewal -D archive -U repl
On 17 the symptom is slightly different but the fix is the same.
I attached a new patch, and only the commit message is different, which
I plan to backport to 17.
There's another bug, though. Even with the patch applied, if you do the
same pg_receivewal command immediately after starting the server
(without any other connections), you get:
FATAL: cannot read pg_class without having selected a database
The path is similar: it's trying to do pg_parameter_aclcheck, but is
unable to open pg_parameter_acl at all because it can't read pg_class.
It seems to work if you connect another backend first, where it does
some initialization first, through I haven't worked out the details. I
think it goes back to when parameter ACLs were introduced in
a0ffa885e47, so CC Mark Dilger.
Regards,
Jeff Davis
Attachments:
[text/x-patch] v2-0001-catcache.c-always-use-C_COLLATION_OID.patch (3.2K, ../4524ed61a015d3496fc008644dcb999bb31916a7.camel@j-davis.com/2-v2-0001-catcache.c-always-use-C_COLLATION_OID.patch)
download | inline diff:
From 39f0bc866b092a5def31184bf7f8ce7b7fcd7f89 Mon Sep 17 00:00:00 2001
From: Jeff Davis <jeff@j-davis.com>
Date: Mon, 13 Apr 2026 12:09:40 -0700
Subject: [PATCH v2] catcache.c: always use C_COLLATION_OID.
The problem report was about setting GUCs in the startup packet when
initiating a replication connection. Setting the GUC required an ACL
check, which performed a catalog lookup on pg_parameter_acl.parname
(type TEXT). The catalog cache was hardwired to use
DEFAULT_COLLATION_OID for text attributes, but walsender never calls
CheckMyDatabase(), so the default collation was uninitialized and it
caused a NULL pointer dereference.
As the comments stated, using DEFAULT_COLLATION_OID was arbitrary
anyway: if the collation actually mattered, it should use the column's
actual collation. (In the catalog, some text columns are the default
collation and some are "C".)
Fix by using C_COLLATION_OID, which doesn't require any initialization
and is always available. When any deterministic collation will do,
it's best to consistently use the simplest and fastest one, so this is
a good idea anyway.
There may be other problems in this general area, so this should not
be considered a complete fix. But this is an independently good change
and solves the immediate problem.
Reported-by: Andrey Borodin <x4mmm@yandex-team.ru>
Discussion: https://postgr.es/m/D18AD72A-5004-4EF8-AF80-10732AF677FA@yandex-team.ru
Backpatch-through: 17
---
src/backend/utils/cache/catcache.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/src/backend/utils/cache/catcache.c b/src/backend/utils/cache/catcache.c
index 87ed5506460..a8e7bf649d2 100644
--- a/src/backend/utils/cache/catcache.c
+++ b/src/backend/utils/cache/catcache.c
@@ -205,6 +205,10 @@ nameeqfast(Datum a, Datum b)
char *ca = NameStr(*DatumGetName(a));
char *cb = NameStr(*DatumGetName(b));
+ /*
+ * Catalogs only use deterministic collations, so ignore column collation
+ * and use fast path.
+ */
return strncmp(ca, cb, NAMEDATALEN) == 0;
}
@@ -213,6 +217,10 @@ namehashfast(Datum datum)
{
char *key = NameStr(*DatumGetName(datum));
+ /*
+ * Catalogs only use deterministic collations, so ignore column collation
+ * and use fast path.
+ */
return hash_bytes((unsigned char *) key, strlen(key));
}
@@ -244,17 +252,20 @@ static bool
texteqfast(Datum a, Datum b)
{
/*
- * The use of DEFAULT_COLLATION_OID is fairly arbitrary here. We just
- * want to take the fast "deterministic" path in texteq().
+ * Catalogs only use deterministic collations, so ignore column collation
+ * and use "C" locale for efficiency.
*/
- return DatumGetBool(DirectFunctionCall2Coll(texteq, DEFAULT_COLLATION_OID, a, b));
+ return DatumGetBool(DirectFunctionCall2Coll(texteq, C_COLLATION_OID, a, b));
}
static uint32
texthashfast(Datum datum)
{
- /* analogously here as in texteqfast() */
- return DatumGetInt32(DirectFunctionCall1Coll(hashtext, DEFAULT_COLLATION_OID, datum));
+ /*
+ * Catalogs only use deterministic collations, so ignore column collation
+ * and use "C" locale for efficiency.
+ */
+ return DatumGetInt32(DirectFunctionCall1Coll(hashtext, C_COLLATION_OID, datum));
}
static bool
--
2.43.0
view thread (8+ messages) latest in thread
Message-ID: <4524ed61a015d3496fc008644dcb999bb31916a7.camel@j-davis.com>
Permalink: ../4524ed61a015d3496fc008644dcb999bb31916a7.camel@j-davis.com/
Also on: postgresql.org/message-id/4524ed61a015d3496fc008644dcb999bb31916a7.camel@j-davis.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: pgsql@j-davis.com, x4mmm@yandex-team.ru, jdavis@postgresql.org, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Perform provider-specific initialization in new functions.
In-Reply-To: <4524ed61a015d3496fc008644dcb999bb31916a7.camel@j-davis.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox