public inbox for [email protected]
help / color / mirror / Atom feedRe: Add pg_get_acl() function get the ACL for a database object
15+ messages / 6 participants
[nested] [flat]
* Re: Add pg_get_acl() function get the ACL for a database object
@ 2024-06-19 13:26 Joel Jacobson <[email protected]>
2024-06-19 13:28 ` Re: Add pg_get_acl() function get the ACL for a database object Ranier Vilela <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Joel Jacobson @ 2024-06-19 13:26 UTC (permalink / raw)
To: Ranier Vilela <[email protected]>; +Cc: pgsql-hackers
Hi Ranier,
Thanks for looking at this.
I've double-checked the patch I sent, and it works fine.
I think I know the cause of your problem:
Since this is a catalog change, you need to run `make clean`, to ensure the catalog is rebuilt,
followed by the usual `make && make install`.
You also need to run `initdb` to create a new database cluster, with the new catalog version.
Let me know if you need more specific instructions.
Best,
Joel
On Wed, Jun 19, 2024, at 14:59, Ranier Vilela wrote:
> Em qua., 19 de jun. de 2024 às 08:35, Joel Jacobson <[email protected]>
> escreveu:
>> Hello hackers,
>>
>> Currently, obtaining the Access Control List (ACL) for a database object
>> requires querying specific pg_catalog tables directly, where the user
>> needs to know the name of the ACL column for the object.
>>
>> Consider:
>>
>> ```
>> CREATE USER test_user;
>> CREATE USER test_owner;
>> CREATE SCHEMA test_schema AUTHORIZATION test_owner;
>> SET ROLE TO test_owner;
>> CREATE TABLE test_schema.test_table ();
>> GRANT SELECT ON TABLE test_schema.test_table TO test_user;
>> ```
>>
>> To get the ACL we can do:
>>
>> ```
>> SELECT relacl FROM pg_class WHERE oid = 'test_schema.test_table'::regclass::oid;
>>
>> relacl
>> ---------------------------------------------------------
>> {test_owner=arwdDxtm/test_owner,test_user=r/test_owner}
>> ```
>>
>> Attached patch adds a new SQL-callable functoin `pg_get_acl()`, so we can do:
>>
>> ```
>> SELECT pg_get_acl('pg_class'::regclass, 'test_schema.test_table'::regclass::oid);
>> pg_get_acl
>> ---------------------------------------------------------
>> {test_owner=arwdDxtm/test_owner,test_user=r/test_owner}
>> ```
>>
>> The original idea for this function came from Alvaro Herrera,
>> in this related discussion:
>> https://postgr.es/m/[email protected]
>>
>> On Thu, Mar 25, 2021, at 16:16, Alvaro Herrera wrote:
>> > On 2021-Mar-25, Joel Jacobson wrote:
>> >
>> >> pg_shdepend doesn't contain the aclitem info though,
>> >> so it won't work for pg_permissions if we want to expose
>> >> privilege_type, is_grantable and grantor.
>> >
>> > Ah, of course -- the only way to obtain the acl columns is by going
>> > through the catalogs individually, so it won't be possible. I think
>> > this could be fixed with some very simple, quick function pg_get_acl()
>> > that takes a catalog OID and object OID and returns the ACL; then
>> > use aclexplode() to obtain all those details.
>>
>> The pg_get_acl() function has been implemented by following
>> the guidance from Alvaro in the related dicussion:
>>
>> On Fri, Mar 26, 2021, at 13:43, Alvaro Herrera wrote:
>> > AFAICS the way to do it is like AlterObjectOwner_internal obtains data
>> > -- first do get_catalog_object_by_oid (gives you the HeapTuple that
>> > represents the object), then
>> > heap_getattr( ..., get_object_attnum_acl(), ..), and there you have the
>> > ACL which you can "explode" (or maybe just return as-is).
>> >
>> > AFAICS if you do this, it's just one cache lookups per object, or
>> > one indexscan for the cases with no by-OID syscache. It should be much
>> > cheaper than the UNION ALL query. And you use pg_shdepend to guide
>> > this, so you only do it for the objects that you already know are
>> > interesting.
>>
>> Many thanks Alvaro for the very helpful instructions.
>>
>> This function would then allow users to e.g. create a view to show the privileges
>> for all database objects, like the pg_privileges system view suggested in the
>> related discussion.
>>
>> Tests and docs are added.
> Hi,
> For some reason, the function pg_get_acl, does not exist in generated fmgrtab.c
>
> So, when install postgres, the function does not work.
>
> postgres=# SELECT pg_get_acl('pg_class'::regclass,
> 'atest2'::regclass::oid);
> ERROR: function pg_get_acl(regclass, oid) does not exist
> LINE 1: SELECT pg_get_acl('pg_class'::regclass, 'atest2'::regclass::...
> ^
> HINT: No function matches the given name and argument types. You might
> need to add explicit type casts.
>
> best regards,
> Ranier Vilela
--
Kind regards,
Joel
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Add pg_get_acl() function get the ACL for a database object
2024-06-19 13:26 Re: Add pg_get_acl() function get the ACL for a database object Joel Jacobson <[email protected]>
@ 2024-06-19 13:28 ` Ranier Vilela <[email protected]>
2024-06-19 13:51 ` Re: Add pg_get_acl() function get the ACL for a database object Ranier Vilela <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Ranier Vilela @ 2024-06-19 13:28 UTC (permalink / raw)
To: Joel Jacobson <[email protected]>; +Cc: pgsql-hackers
Em qua., 19 de jun. de 2024 às 10:26, Joel Jacobson <[email protected]>
escreveu:
> Hi Ranier,
>
> Thanks for looking at this.
>
> I've double-checked the patch I sent, and it works fine.
>
> I think I know the cause of your problem:
>
> Since this is a catalog change, you need to run `make clean`, to ensure
> the catalog is rebuilt,
> followed by the usual `make && make install`.
>
> You also need to run `initdb` to create a new database cluster, with the
> new catalog version.
>
> Let me know if you need more specific instructions.
>
Sorry, sorry but I'm on Windows -> meson.
Double checked with:
ninja clean
ninja
ninja install
best regards,
Ranier Vilela
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Add pg_get_acl() function get the ACL for a database object
2024-06-19 13:26 Re: Add pg_get_acl() function get the ACL for a database object Joel Jacobson <[email protected]>
2024-06-19 13:28 ` Re: Add pg_get_acl() function get the ACL for a database object Ranier Vilela <[email protected]>
@ 2024-06-19 13:51 ` Ranier Vilela <[email protected]>
2024-06-19 14:21 ` Re: Add pg_get_acl() function get the ACL for a database object Joel Jacobson <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Ranier Vilela @ 2024-06-19 13:51 UTC (permalink / raw)
To: Joel Jacobson <[email protected]>; +Cc: pgsql-hackers
Em qua., 19 de jun. de 2024 às 10:28, Ranier Vilela <[email protected]>
escreveu:
> Em qua., 19 de jun. de 2024 às 10:26, Joel Jacobson <[email protected]>
> escreveu:
>
>> Hi Ranier,
>>
>> Thanks for looking at this.
>>
>> I've double-checked the patch I sent, and it works fine.
>>
>> I think I know the cause of your problem:
>>
>> Since this is a catalog change, you need to run `make clean`, to ensure
>> the catalog is rebuilt,
>> followed by the usual `make && make install`.
>>
>> You also need to run `initdb` to create a new database cluster, with the
>> new catalog version.
>>
>> Let me know if you need more specific instructions.
>>
> Sorry, sorry but I'm on Windows -> meson.
>
> Double checked with:
> ninja clean
> ninja
> ninja install
>
Sorry for the noise, now pg_get_acl is shown in the regress test.
Regarding the patch, could it be written in the following style?
Datum
pg_get_acl(PG_FUNCTION_ARGS)
{
Oid classId = PG_GETARG_OID(0);
Oid objectId = PG_GETARG_OID(1);
Oid catalogId;
AttrNumber Anum_oid;
AttrNumber Anum_acl;
/* for "pinned" items in pg_depend, return null */
if (!OidIsValid(classId) && !OidIsValid(objectId))
PG_RETURN_NULL();
catalogId = (classId == LargeObjectRelationId) ?
LargeObjectMetadataRelationId : classId;
Anum_oid = get_object_attnum_oid(catalogId);
Anum_acl = get_object_attnum_acl(catalogId);
if (Anum_acl != InvalidAttrNumber)
{
Relation rel;
HeapTuple tup;
Datum datum;
bool isnull;
rel = table_open(catalogId, AccessShareLock);
tup = get_catalog_object_by_oid(rel, Anum_oid, objectId);
if (!HeapTupleIsValid(tup))
elog(ERROR, "cache lookup failed for object %u of catalog \"%s\"",
objectId, RelationGetRelationName(rel));
datum = heap_getattr(tup, Anum_acl, RelationGetDescr(rel), &isnull);
table_close(rel, AccessShareLock);
if (!isnull)
PG_RETURN_DATUM(datum);
}
PG_RETURN_NULL();
}
best regards,
Ranier Vilela
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Add pg_get_acl() function get the ACL for a database object
2024-06-19 13:26 Re: Add pg_get_acl() function get the ACL for a database object Joel Jacobson <[email protected]>
2024-06-19 13:28 ` Re: Add pg_get_acl() function get the ACL for a database object Ranier Vilela <[email protected]>
2024-06-19 13:51 ` Re: Add pg_get_acl() function get the ACL for a database object Ranier Vilela <[email protected]>
@ 2024-06-19 14:21 ` Joel Jacobson <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Joel Jacobson @ 2024-06-19 14:21 UTC (permalink / raw)
To: Ranier Vilela <[email protected]>; +Cc: pgsql-hackers
On Wed, Jun 19, 2024, at 15:51, Ranier Vilela wrote:
> Regarding the patch, could it be written in the following style?
Thanks for nice improvement. New version attached.
Best,
Joel
Attachments:
[application/octet-stream] v2-0001-Add-pg_get_acl.patch (6.1K, ../../[email protected]/2-v2-0001-Add-pg_get_acl.patch)
download | inline diff:
From 2639b778e84169aab8f42dc63af125d66f08392c Mon Sep 17 00:00:00 2001
From: Joel Jakobsson <[email protected]>
Date: Wed, 19 Jun 2024 12:31:21 +0200
Subject: [PATCH] Add pg_get_acl() function to get the ACL for a database
object.
This SQL-callable function returns the Access Control List (ACL)
for a database object, specified by catalog OID and object OID.
Related Discussion: https://postgr.es/m/[email protected]
---
doc/src/sgml/func.sgml | 16 +++++++++
src/backend/catalog/objectaddress.c | 45 ++++++++++++++++++++++++
src/include/catalog/pg_proc.dat | 6 ++++
src/test/regress/expected/privileges.out | 7 ++++
src/test/regress/sql/privileges.sql | 2 ++
5 files changed, 76 insertions(+)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 2609269610..fa6fdce517 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -26686,6 +26686,22 @@ SELECT currval(pg_get_serial_sequence('sometable', 'id'));
Undefined objects are identified with <literal>NULL</literal> values.
</para></entry>
</row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_acl</primary>
+ </indexterm>
+ <function>pg_get_acl</function> ( <parameter>classid</parameter> <type>oid</type>, <parameter>objid</parameter> <type>oid</type> )
+ <returnvalue>aclitem[]</returnvalue>
+ </para>
+ <para>
+ Returns the Access Control List (ACL) for a database object,
+ specified by catalog OID and object OID.
+ This function is useful for retrieving and inspecting the privileges associated with database objects.
+ This function returns NULL values for undefined objects.
+ </para></entry>
+ </row>
</tbody>
</tgroup>
</table>
diff --git a/src/backend/catalog/objectaddress.c b/src/backend/catalog/objectaddress.c
index 7b536ac6fd..069e35fe9a 100644
--- a/src/backend/catalog/objectaddress.c
+++ b/src/backend/catalog/objectaddress.c
@@ -4362,6 +4362,51 @@ pg_identify_object_as_address(PG_FUNCTION_ARGS)
PG_RETURN_DATUM(HeapTupleGetDatum(htup));
}
+/*
+ * SQL-level callable function to obtain the Access Control List (ACL)
+ * of a specified object, given its catalog OID and object OID.
+ */
+Datum
+pg_get_acl(PG_FUNCTION_ARGS)
+{
+ Oid classId = PG_GETARG_OID(0);
+ Oid objectId = PG_GETARG_OID(1);
+ Oid catalogId;
+ AttrNumber Anum_oid;
+ AttrNumber Anum_acl;
+
+ /* for "pinned" items in pg_depend, return null */
+ if (!OidIsValid(classId) && !OidIsValid(objectId))
+ PG_RETURN_NULL();
+
+ catalogId = (classId == LargeObjectRelationId) ? LargeObjectMetadataRelationId : classId;
+ Anum_oid = get_object_attnum_oid(catalogId);
+ Anum_acl = get_object_attnum_acl(catalogId);
+
+ if (Anum_acl != InvalidAttrNumber)
+ {
+ Relation rel;
+ HeapTuple tup;
+ Datum datum;
+ bool isnull;
+
+ rel = table_open(catalogId, AccessShareLock);
+
+ tup = get_catalog_object_by_oid(rel, Anum_oid, objectId);
+ if (!HeapTupleIsValid(tup))
+ elog(ERROR, "cache lookup failed for object %u of catalog \"%s\"",
+ objectId, RelationGetRelationName(rel));
+
+ datum = heap_getattr(tup, Anum_acl, RelationGetDescr(rel), &isnull);
+ table_close(rel, AccessShareLock);
+
+ if (!isnull)
+ PG_RETURN_DATUM(datum);
+ }
+
+ PG_RETURN_NULL();
+}
+
/*
* Return a palloc'ed string that describes the type of object that the
* passed address is for.
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 6a5476d3c4..5ab9b11b47 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -6362,6 +6362,12 @@
proname => 'pg_describe_object', provolatile => 's', prorettype => 'text',
proargtypes => 'oid oid int4', prosrc => 'pg_describe_object' },
+{ oid => '6347', descr => 'get ACL for SQL object',
+ proname => 'pg_get_acl', provolatile => 's', prorettype => '_aclitem',
+ proargtypes => 'oid oid',
+ proargnames => '{classid,objid}',
+ prosrc => 'pg_get_acl' },
+
{ oid => '3839',
descr => 'get machine-parseable identification of SQL object',
proname => 'pg_identify_object', provolatile => 's', prorettype => 'record',
diff --git a/src/test/regress/expected/privileges.out b/src/test/regress/expected/privileges.out
index eb4b762ea1..7ada124265 100644
--- a/src/test/regress/expected/privileges.out
+++ b/src/test/regress/expected/privileges.out
@@ -219,6 +219,13 @@ GRANT INSERT ON atest2 TO regress_priv_user4 GRANTED BY CURRENT_USER;
GRANT TRUNCATE ON atest2 TO regress_priv_user5 GRANTED BY CURRENT_ROLE;
GRANT TRUNCATE ON atest2 TO regress_priv_user4 GRANTED BY regress_priv_user5; -- error
ERROR: grantor must be current user
+-- test pg_get_acl()
+SELECT pg_get_acl('pg_class'::regclass, 'atest2'::regclass::oid);
+ pg_get_acl
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+ {regress_priv_user1=arwdDxtm/regress_priv_user1,regress_priv_user2=r/regress_priv_user1,regress_priv_user3=w/regress_priv_user1,regress_priv_user4=a/regress_priv_user1,regress_priv_user5=D/regress_priv_user1}
+(1 row)
+
SET SESSION AUTHORIZATION regress_priv_user2;
SELECT session_user, current_user;
session_user | current_user
diff --git a/src/test/regress/sql/privileges.sql b/src/test/regress/sql/privileges.sql
index eeb4c00292..36f348051e 100644
--- a/src/test/regress/sql/privileges.sql
+++ b/src/test/regress/sql/privileges.sql
@@ -190,6 +190,8 @@ GRANT TRUNCATE ON atest2 TO regress_priv_user5 GRANTED BY CURRENT_ROLE;
GRANT TRUNCATE ON atest2 TO regress_priv_user4 GRANTED BY regress_priv_user5; -- error
+-- test pg_get_acl()
+SELECT pg_get_acl('pg_class'::regclass, 'atest2'::regclass::oid);
SET SESSION AUTHORIZATION regress_priv_user2;
SELECT session_user, current_user;
--
2.45.1
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Partitioned tables and [un]loggedness
@ 2025-06-04 09:55 Shinya Kato <[email protected]>
2025-06-04 10:05 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Shinya Kato @ 2025-06-04 09:55 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Nathan Bossart <[email protected]>; David G. Johnston <[email protected]>; Postgres hackers <[email protected]>
On Wed, Jun 4, 2025 at 6:42 PM Michael Paquier <[email protected]> wrote:
>
> On Thu, Sep 19, 2024 at 01:08:33PM +0900, Michael Paquier wrote:
> > I have applied 0001 for now to add ATT_PARTITIONED_TABLE. Attached is
> > the remaining piece.
>
> And the second piece is now applied as of e2bab2d79204.
> --
> Michael
Hi,
Should we consider preventing tab completion for PARTITION BY
immediately after CREATE TABLE name (...)? Or is it fine to leave it
as is, given that it's syntactically correct?
--
Best regards,
Shinya Kato
NTT OSS Center
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Partitioned tables and [un]loggedness
2025-06-04 09:55 Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
@ 2025-06-04 10:05 ` Shinya Kato <[email protected]>
2025-06-04 16:15 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Shinya Kato @ 2025-06-04 10:05 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Nathan Bossart <[email protected]>; David G. Johnston <[email protected]>; Postgres hackers <[email protected]>
On Wed, Jun 4, 2025 at 6:55 PM Shinya Kato <[email protected]> wrote:
>
> On Wed, Jun 4, 2025 at 6:42 PM Michael Paquier <[email protected]> wrote:
> >
> > On Thu, Sep 19, 2024 at 01:08:33PM +0900, Michael Paquier wrote:
> > > I have applied 0001 for now to add ATT_PARTITIONED_TABLE. Attached is
> > > the remaining piece.
> >
> > And the second piece is now applied as of e2bab2d79204.
> > --
> > Michael
>
> Hi,
>
> Should we consider preventing tab completion for PARTITION BY
> immediately after CREATE TABLE name (...)? Or is it fine to leave it
> as is, given that it's syntactically correct?
Sorry.
CREATE TABLE name (...) -> CREATE UNLOGGED TABLE name (...)
--
Best regards,
Shinya Kato
NTT OSS Center
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Partitioned tables and [un]loggedness
2025-06-04 09:55 Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 10:05 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
@ 2025-06-04 16:15 ` Nathan Bossart <[email protected]>
2025-06-05 00:23 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Nathan Bossart @ 2025-06-04 16:15 UTC (permalink / raw)
To: Shinya Kato <[email protected]>; +Cc: Michael Paquier <[email protected]>; David G. Johnston <[email protected]>; Postgres hackers <[email protected]>
On Wed, Jun 04, 2025 at 07:05:20PM +0900, Shinya Kato wrote:
> On Wed, Jun 4, 2025 at 6:55 PM Shinya Kato <[email protected]> wrote:
>> Should we consider preventing tab completion for PARTITION BY
>> immediately after CREATE TABLE name (...)? Or is it fine to leave it
>> as is, given that it's syntactically correct?
>
> Sorry.
> CREATE TABLE name (...) -> CREATE UNLOGGED TABLE name (...)
I see no benefit in recommending things that are guaranteed to error. In
commit 5c1ce1b, we removed tab completion for CREATE UNLOGGED MATERIALIZED
VIEW even though it is supported by the grammar. The partitioned table
case sounds like roughly the same situation.
--
nathan
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Partitioned tables and [un]loggedness
2025-06-04 09:55 Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 10:05 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 16:15 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
@ 2025-06-05 00:23 ` Michael Paquier <[email protected]>
2025-06-05 01:04 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Michael Paquier @ 2025-06-05 00:23 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Shinya Kato <[email protected]>; David G. Johnston <[email protected]>; Postgres hackers <[email protected]>
On Wed, Jun 04, 2025 at 11:15:29AM -0500, Nathan Bossart wrote:
> I see no benefit in recommending things that are guaranteed to error. In
> commit 5c1ce1b, we removed tab completion for CREATE UNLOGGED MATERIALIZED
> VIEW even though it is supported by the grammar. The partitioned table
> case sounds like roughly the same situation.
Agreed to not suggest the PARTITION BY clause in the tab completion as
it is not supported by the backend for unlogged tables.
tab-complete.in.c has some handling for CREATE UNLOGGED TABLE around
line 3667, so we could just have an extra case for it, like in the
attached patch. A split already exists for temporary tables to handle
the ON COMMIT clause after the attribute list.
Thoughts?
--
Michael
Attachments:
[text/x-diff] psql-tab-unlogged.patch (1.0K, ../../[email protected]/2-psql-tab-unlogged.patch)
download | inline diff:
diff --git a/src/bin/psql/tab-complete.in.c b/src/bin/psql/tab-complete.in.c
index ec65ab79fecb..620830feb9d7 100644
--- a/src/bin/psql/tab-complete.in.c
+++ b/src/bin/psql/tab-complete.in.c
@@ -3664,9 +3664,10 @@ match_previous_words(int pattern_id,
TailMatches("CREATE", "TEMP|TEMPORARY|UNLOGGED", "TABLE", MatchAny, "(*)", "AS"))
COMPLETE_WITH("EXECUTE", "SELECT", "TABLE", "VALUES", "WITH");
/* Complete CREATE TABLE name (...) with supported options */
- else if (TailMatches("CREATE", "TABLE", MatchAny, "(*)") ||
- TailMatches("CREATE", "UNLOGGED", "TABLE", MatchAny, "(*)"))
+ else if (TailMatches("CREATE", "TABLE", MatchAny, "(*)"))
COMPLETE_WITH("AS", "INHERITS (", "PARTITION BY", "USING", "TABLESPACE", "WITH (");
+ else if (TailMatches("CREATE", "UNLOGGED", "TABLE", MatchAny, "(*)"))
+ COMPLETE_WITH("AS", "INHERITS (", "USING", "TABLESPACE", "WITH (");
else if (TailMatches("CREATE", "TEMP|TEMPORARY", "TABLE", MatchAny, "(*)"))
COMPLETE_WITH("AS", "INHERITS (", "ON COMMIT", "PARTITION BY", "USING",
"TABLESPACE", "WITH (");
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Partitioned tables and [un]loggedness
2025-06-04 09:55 Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 10:05 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 16:15 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
2025-06-05 00:23 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
@ 2025-06-05 01:04 ` Shinya Kato <[email protected]>
2025-06-05 04:57 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Shinya Kato @ 2025-06-05 01:04 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Nathan Bossart <[email protected]>; David G. Johnston <[email protected]>; Postgres hackers <[email protected]>
On Thu, Jun 5, 2025 at 9:23 AM Michael Paquier <[email protected]> wrote:
> Agreed to not suggest the PARTITION BY clause in the tab completion as
> it is not supported by the backend for unlogged tables.
> tab-complete.in.c has some handling for CREATE UNLOGGED TABLE around
> line 3667, so we could just have an extra case for it, like in the
> attached patch. A split already exists for temporary tables to handle
> the ON COMMIT clause after the attribute list.
>
> Thoughts?
Thank you. It looks good to me.
--
Best regards,
Shinya Kato
NTT OSS Center
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Partitioned tables and [un]loggedness
2025-06-04 09:55 Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 10:05 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 16:15 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
2025-06-05 00:23 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
2025-06-05 01:04 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
@ 2025-06-05 04:57 ` Michael Paquier <[email protected]>
2025-06-05 20:04 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Michael Paquier @ 2025-06-05 04:57 UTC (permalink / raw)
To: Shinya Kato <[email protected]>; +Cc: Nathan Bossart <[email protected]>; David G. Johnston <[email protected]>; Postgres hackers <[email protected]>
On Thu, Jun 05, 2025 at 10:04:23AM +0900, Shinya Kato wrote:
> Thank you. It looks good to me.
How does the RMT feel about this change? Nathan, would you be OK with
that? It's not a big problem, as well, if the code is kept as-is, but
as it's a simple change..
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Partitioned tables and [un]loggedness
2025-06-04 09:55 Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 10:05 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 16:15 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
2025-06-05 00:23 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
2025-06-05 01:04 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-05 04:57 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
@ 2025-06-05 20:04 ` Nathan Bossart <[email protected]>
2025-06-06 01:55 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Nathan Bossart @ 2025-06-05 20:04 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Shinya Kato <[email protected]>; David G. Johnston <[email protected]>; Postgres hackers <[email protected]>; [email protected]
On Thu, Jun 05, 2025 at 01:57:30PM +0900, Michael Paquier wrote:
> How does the RMT feel about this change? Nathan, would you be OK with
> that? It's not a big problem, as well, if the code is kept as-is, but
> as it's a simple change..
IMHO a case can be reasonably made that this is an oversight in the related
commit. I've added the rest of the RMT here in case they see it
differently.
The patch LGTM, too.
--
nathan
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Partitioned tables and [un]loggedness
2025-06-04 09:55 Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 10:05 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 16:15 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
2025-06-05 00:23 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
2025-06-05 01:04 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-05 04:57 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
2025-06-05 20:04 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
@ 2025-06-06 01:55 ` Michael Paquier <[email protected]>
2025-06-11 00:28 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Michael Paquier @ 2025-06-06 01:55 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Shinya Kato <[email protected]>; David G. Johnston <[email protected]>; Postgres hackers <[email protected]>; [email protected]
On Thu, Jun 05, 2025 at 03:04:45PM -0500, Nathan Bossart wrote:
> IMHO a case can be reasonably made that this is an oversight in the related
> commit. I've added the rest of the RMT here in case they see it
> differently.
>
> The patch LGTM, too.
Okay, thanks. Let's wait for a couple of days in case there are more
opinions and/or comments. I propose to apply the patch around the
beginning of next week if there are no objections.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Partitioned tables and [un]loggedness
2025-06-04 09:55 Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 10:05 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 16:15 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
2025-06-05 00:23 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
2025-06-05 01:04 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-05 04:57 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
2025-06-05 20:04 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
2025-06-06 01:55 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
@ 2025-06-11 00:28 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Michael Paquier @ 2025-06-11 00:28 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Shinya Kato <[email protected]>; David G. Johnston <[email protected]>; Postgres hackers <[email protected]>; [email protected]
On Fri, Jun 06, 2025 at 10:55:32AM +0900, Michael Paquier wrote:
> Okay, thanks. Let's wait for a couple of days in case there are more
> opinions and/or comments. I propose to apply the patch around the
> beginning of next week if there are no objections.
It took a bit longer than wanted, but applied now.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 15+ messages in thread
* [PATCH v1 8/8] convert FastPathStrongRelationLocks to atomics
@ 2026-07-09 20:38 Nathan Bossart <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Nathan Bossart @ 2026-07-09 20:38 UTC (permalink / raw)
---
src/backend/storage/lmgr/lock.c | 57 ++++++++++-----------------------
1 file changed, 17 insertions(+), 40 deletions(-)
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 5ee80c7632e..035932197a4 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -40,11 +40,11 @@
#include "miscadmin.h"
#include "pg_trace.h"
#include "pgstat.h"
+#include "port/atomics.h"
#include "storage/lmgr.h"
#include "storage/proc.h"
#include "storage/procarray.h"
#include "storage/shmem.h"
-#include "storage/spin.h"
#include "storage/standby.h"
#include "storage/subsystems.h"
#include "utils/memutils.h"
@@ -306,13 +306,7 @@ static PROCLOCK *FastPathGetRelationLockEntry(LOCALLOCK *locallock);
#define FastPathStrongLockHashPartition(hashcode) \
((hashcode) % FAST_PATH_STRONG_LOCK_HASH_PARTITIONS)
-typedef struct
-{
- slock_t mutex;
- uint32 count[FAST_PATH_STRONG_LOCK_HASH_PARTITIONS];
-} FastPathStrongRelationLockData;
-
-static FastPathStrongRelationLockData *FastPathStrongRelationLocks;
+static pg_atomic_uint32 *FastPathStrongRelationLocks;
static void LockManagerShmemRequest(void *arg);
static void LockManagerShmemInit(void *arg);
@@ -484,7 +478,8 @@ LockManagerShmemRequest(void *arg)
);
ShmemRequestStruct(.name = "Fast Path Strong Relation Lock Data",
- .size = sizeof(FastPathStrongRelationLockData),
+ .size = mul_size(sizeof(pg_atomic_uint32),
+ FAST_PATH_STRONG_LOCK_HASH_PARTITIONS),
.ptr = (void **) (void *) &FastPathStrongRelationLocks,
);
}
@@ -492,7 +487,8 @@ LockManagerShmemRequest(void *arg)
static void
LockManagerShmemInit(void *arg)
{
- SpinLockInit(&FastPathStrongRelationLocks->mutex);
+ for (int i = 0; i < FAST_PATH_STRONG_LOCK_HASH_PARTITIONS; i++)
+ pg_atomic_init_u32(&FastPathStrongRelationLocks[i], 0);
}
/*
@@ -992,11 +988,11 @@ LockAcquireExtended(const LOCKTAG *locktag,
/*
* LWLockAcquire acts as a memory sequencing point, so it's safe
* to assume that any strong locker whose increment to
- * FastPathStrongRelationLocks->counts becomes visible after we
- * test it has yet to begin to transfer fast-path locks.
+ * FastPathStrongRelationLocks becomes visible after we test it
+ * has yet to begin to transfer fast-path locks.
*/
LWLockAcquire(&MyProc->fpInfoLock, LW_EXCLUSIVE);
- if (FastPathStrongRelationLocks->count[fasthashcode] != 0)
+ if (pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) != 0)
acquired = false;
else
acquired = FastPathGrantRelationLock(locktag->locktag_field2,
@@ -1501,11 +1497,9 @@ RemoveLocalLock(LOCALLOCK *locallock)
fasthashcode = FastPathStrongLockHashPartition(locallock->hashcode);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
- FastPathStrongRelationLocks->count[fasthashcode]--;
+ Assert(pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) > 0);
+ pg_atomic_fetch_sub_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
locallock->holdsStrongLockCount = false;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
}
if (!hash_search(LockMethodLocalHash,
@@ -1834,20 +1828,9 @@ BeginStrongLockAcquire(LOCALLOCK *locallock, uint32 fasthashcode)
Assert(StrongLockInProgress == NULL);
Assert(locallock->holdsStrongLockCount == false);
- /*
- * Adding to a memory location is not atomic, so we take a spinlock to
- * ensure we don't collide with someone else trying to bump the count at
- * the same time.
- *
- * XXX: It might be worth considering using an atomic fetch-and-add
- * instruction here, on architectures where that is supported.
- */
-
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- FastPathStrongRelationLocks->count[fasthashcode]++;
+ pg_atomic_fetch_add_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
locallock->holdsStrongLockCount = true;
StrongLockInProgress = locallock;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
}
/*
@@ -1875,12 +1858,10 @@ AbortStrongLockAcquire(void)
fasthashcode = FastPathStrongLockHashPartition(locallock->hashcode);
Assert(locallock->holdsStrongLockCount == true);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
- FastPathStrongRelationLocks->count[fasthashcode]--;
+ Assert(pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) > 0);
+ pg_atomic_fetch_sub_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
locallock->holdsStrongLockCount = false;
StrongLockInProgress = NULL;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
}
/*
@@ -3365,10 +3346,8 @@ LockRefindAndRelease(LockMethod lockMethodTable, PGPROC *proc,
{
uint32 fasthashcode = FastPathStrongLockHashPartition(hashcode);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
- FastPathStrongRelationLocks->count[fasthashcode]--;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
+ Assert(pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) > 0);
+ pg_atomic_fetch_sub_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
}
}
@@ -4504,9 +4483,7 @@ lock_twophase_recover(FullTransactionId fxid, uint16 info,
{
uint32 fasthashcode = FastPathStrongLockHashPartition(hashcode);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- FastPathStrongRelationLocks->count[fasthashcode]++;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
+ pg_atomic_fetch_add_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
}
LWLockRelease(partitionLock);
--
2.50.1 (Apple Git-155)
--Ot5x3ffkWEuxilWO--
^ permalink raw reply [nested|flat] 15+ messages in thread
* [PATCH v1 8/8] convert FastPathStrongRelationLocks to atomics
@ 2026-07-09 20:38 Nathan Bossart <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Nathan Bossart @ 2026-07-09 20:38 UTC (permalink / raw)
---
src/backend/storage/lmgr/lock.c | 57 ++++++++++-----------------------
1 file changed, 17 insertions(+), 40 deletions(-)
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 5ee80c7632e..035932197a4 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -40,11 +40,11 @@
#include "miscadmin.h"
#include "pg_trace.h"
#include "pgstat.h"
+#include "port/atomics.h"
#include "storage/lmgr.h"
#include "storage/proc.h"
#include "storage/procarray.h"
#include "storage/shmem.h"
-#include "storage/spin.h"
#include "storage/standby.h"
#include "storage/subsystems.h"
#include "utils/memutils.h"
@@ -306,13 +306,7 @@ static PROCLOCK *FastPathGetRelationLockEntry(LOCALLOCK *locallock);
#define FastPathStrongLockHashPartition(hashcode) \
((hashcode) % FAST_PATH_STRONG_LOCK_HASH_PARTITIONS)
-typedef struct
-{
- slock_t mutex;
- uint32 count[FAST_PATH_STRONG_LOCK_HASH_PARTITIONS];
-} FastPathStrongRelationLockData;
-
-static FastPathStrongRelationLockData *FastPathStrongRelationLocks;
+static pg_atomic_uint32 *FastPathStrongRelationLocks;
static void LockManagerShmemRequest(void *arg);
static void LockManagerShmemInit(void *arg);
@@ -484,7 +478,8 @@ LockManagerShmemRequest(void *arg)
);
ShmemRequestStruct(.name = "Fast Path Strong Relation Lock Data",
- .size = sizeof(FastPathStrongRelationLockData),
+ .size = mul_size(sizeof(pg_atomic_uint32),
+ FAST_PATH_STRONG_LOCK_HASH_PARTITIONS),
.ptr = (void **) (void *) &FastPathStrongRelationLocks,
);
}
@@ -492,7 +487,8 @@ LockManagerShmemRequest(void *arg)
static void
LockManagerShmemInit(void *arg)
{
- SpinLockInit(&FastPathStrongRelationLocks->mutex);
+ for (int i = 0; i < FAST_PATH_STRONG_LOCK_HASH_PARTITIONS; i++)
+ pg_atomic_init_u32(&FastPathStrongRelationLocks[i], 0);
}
/*
@@ -992,11 +988,11 @@ LockAcquireExtended(const LOCKTAG *locktag,
/*
* LWLockAcquire acts as a memory sequencing point, so it's safe
* to assume that any strong locker whose increment to
- * FastPathStrongRelationLocks->counts becomes visible after we
- * test it has yet to begin to transfer fast-path locks.
+ * FastPathStrongRelationLocks becomes visible after we test it
+ * has yet to begin to transfer fast-path locks.
*/
LWLockAcquire(&MyProc->fpInfoLock, LW_EXCLUSIVE);
- if (FastPathStrongRelationLocks->count[fasthashcode] != 0)
+ if (pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) != 0)
acquired = false;
else
acquired = FastPathGrantRelationLock(locktag->locktag_field2,
@@ -1501,11 +1497,9 @@ RemoveLocalLock(LOCALLOCK *locallock)
fasthashcode = FastPathStrongLockHashPartition(locallock->hashcode);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
- FastPathStrongRelationLocks->count[fasthashcode]--;
+ Assert(pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) > 0);
+ pg_atomic_fetch_sub_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
locallock->holdsStrongLockCount = false;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
}
if (!hash_search(LockMethodLocalHash,
@@ -1834,20 +1828,9 @@ BeginStrongLockAcquire(LOCALLOCK *locallock, uint32 fasthashcode)
Assert(StrongLockInProgress == NULL);
Assert(locallock->holdsStrongLockCount == false);
- /*
- * Adding to a memory location is not atomic, so we take a spinlock to
- * ensure we don't collide with someone else trying to bump the count at
- * the same time.
- *
- * XXX: It might be worth considering using an atomic fetch-and-add
- * instruction here, on architectures where that is supported.
- */
-
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- FastPathStrongRelationLocks->count[fasthashcode]++;
+ pg_atomic_fetch_add_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
locallock->holdsStrongLockCount = true;
StrongLockInProgress = locallock;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
}
/*
@@ -1875,12 +1858,10 @@ AbortStrongLockAcquire(void)
fasthashcode = FastPathStrongLockHashPartition(locallock->hashcode);
Assert(locallock->holdsStrongLockCount == true);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
- FastPathStrongRelationLocks->count[fasthashcode]--;
+ Assert(pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) > 0);
+ pg_atomic_fetch_sub_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
locallock->holdsStrongLockCount = false;
StrongLockInProgress = NULL;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
}
/*
@@ -3365,10 +3346,8 @@ LockRefindAndRelease(LockMethod lockMethodTable, PGPROC *proc,
{
uint32 fasthashcode = FastPathStrongLockHashPartition(hashcode);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
- FastPathStrongRelationLocks->count[fasthashcode]--;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
+ Assert(pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) > 0);
+ pg_atomic_fetch_sub_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
}
}
@@ -4504,9 +4483,7 @@ lock_twophase_recover(FullTransactionId fxid, uint16 info,
{
uint32 fasthashcode = FastPathStrongLockHashPartition(hashcode);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- FastPathStrongRelationLocks->count[fasthashcode]++;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
+ pg_atomic_fetch_add_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
}
LWLockRelease(partitionLock);
--
2.50.1 (Apple Git-155)
--Ot5x3ffkWEuxilWO--
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2026-07-09 20:38 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-06-19 13:26 Re: Add pg_get_acl() function get the ACL for a database object Joel Jacobson <[email protected]>
2024-06-19 13:28 ` Ranier Vilela <[email protected]>
2024-06-19 13:51 ` Ranier Vilela <[email protected]>
2024-06-19 14:21 ` Joel Jacobson <[email protected]>
2025-06-04 09:55 Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 10:05 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-04 16:15 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
2025-06-05 00:23 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
2025-06-05 01:04 ` Re: Partitioned tables and [un]loggedness Shinya Kato <[email protected]>
2025-06-05 04:57 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
2025-06-05 20:04 ` Re: Partitioned tables and [un]loggedness Nathan Bossart <[email protected]>
2025-06-06 01:55 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
2025-06-11 00:28 ` Re: Partitioned tables and [un]loggedness Michael Paquier <[email protected]>
2026-07-09 20:38 [PATCH v1 8/8] convert FastPathStrongRelationLocks to atomics Nathan Bossart <[email protected]>
2026-07-09 20:38 [PATCH v1 8/8] convert FastPathStrongRelationLocks to atomics Nathan Bossart <[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