pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedpg_dumpall and owner of the extension
10+ messages / 3 participants
[nested] [flat]
* pg_dumpall and owner of the extension
@ 2024-01-23 14:31 kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 15:30 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-23 16:13 ` Re: pg_dumpall and owner of the extension Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 10+ messages in thread
From: kaido vaikla @ 2024-01-23 14:31 UTC (permalink / raw)
To: pgsql-admin
Hi,
pg_pumpall (13.4) changes owner of the extension.
Source instance 13.4:
function boolop is part of extension intarray
diam=# \dx intarray
List of installed extensions
Name | Version | Schema | Description
----------+---------+--------+--------------------------------------------------------------------
intarray | 1.3 | iamapp | functions, operators, and index support for
1-D arrays of integers
(1 row)
diam=# \dn iamapp
List of schemas
Name | Owner
--------+-------------
iamapp | iamappadmin
(1 row)
diam=# \df+ iamapp.boolop
List of functions
-[ RECORD 1 ]-------+-----------------------------
Schema | iamapp
Name | boolop
Result data type | boolean
Argument data types | integer[], iamapp.query_int
Type | func
Volatility | immutable
Parallel | safe
Owner | iamappadmin
Security | invoker
Access privileges |
Language | c
Source code | boolop
Description | boolean operation with array
Export is done using pg_dumpall.
Dest instance 15.4:
After import (psql -a -f )
diam=# \dx intarray
List of installed extensions
Name | Version | Schema | Description
----------+---------+--------+--------------------------------------------------------------------
intarray | 1.5 | iamapp | functions, operators, and index support for
1-D arrays of integers
(1 row)
diam=# \dn iamapp
List of schemas
Name | Owner
--------+-------------
iamapp | iamappadmin
(1 row)
diam=# \df+ iamapp.boolop
List of functions
-[ RECORD 1 ]-------+-----------------------------
Schema | iamapp
Name | boolop
Result data type | boolean
Argument data types | integer[], iamapp.query_int
Type | func
Volatility | immutable
Parallel | safe
Owner | postgres
Security | invoker
Access privileges |
Language | c
Source code | boolop
Description | boolean operation with array
Manual says "The user who runs CREATE EXTENSION becomes the owner of the
extension".
So pg_dumpall is not aware who ran "CREATE EXTENSION"?
br
Kaido
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: pg_dumpall and owner of the extension
2024-01-23 14:31 pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
@ 2024-01-23 15:30 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-23 16:01 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
1 sibling, 1 reply; 10+ messages in thread
From: Laurenz Albe @ 2024-01-23 15:30 UTC (permalink / raw)
To: kaido vaikla <kaido.vaikla@gmail.com>; pgsql-admin
On Tue, 2024-01-23 at 16:31 +0200, kaido vaikla wrote:
> pg_pumpall (13.4) changes owner of the extension.
>
> [Extension created by user A, dump restored by user B -> Extension objects belong to B]
>
> Manual says "The user who runs CREATE EXTENSION becomes the owner of the extension".
> So pg_dumpall is not aware who ran "CREATE EXTENSION"?
The user who runs CREATE EXTENSION is the user who restores the dump, hence the
changed ownership of the extension objects.
There is no ALTER EXTENSION ... OWNER TO to change the owner to the original user,
which is probably what would be needed in this case.
This is arguably a bug.
Trawling the archives, I found this pertinent thread:
https://www.postgresql.org/message-id/flat/4E1F1072.3010300%40enterprisedb.com
I looked for the referenced discussion, and all I found was this:
https://www.postgresql.org/message-id/flat/21857.1297101968%40sss.pgh.pa.us#e2697a586e2aecbe175d3ce1...
That sounds to me like ALTER EXTENSION ... OWNER TO was originally planned,
but never implemented:
"BTW, on trying this I notice that pg_dump's default approach to
ownership doesn't work because of the lack of an ALTER EXTENSION
OWNER TO command. I'm going to go ahead and add extowner to the catalog
anyway, because it's easy and I'm convinced we're going to want it
later. But I don't feel like writing ALTER EXTENSION OWNER TO right
now, so pg_dump will continue its current behavior of creating the
extension as the user running the script."
Obviously nobody has felt like implementing ALTER EXTENSION ... OWNER TO
in the dozen years that followed that statement...
This was probably not a real problem for anybody, because traditionally
you needed a superuser to run CREATE EXTENSION, and functions are executable
by everybody by default, so you normally don't notice a difference.
Now that we have trusted extensions that don't require a superuser to
create, things might have changed. It would be interesting to know if you
have a real problem with the current behavior, which would be an argument
in favor of fixing the omission.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: pg_dumpall and owner of the extension
2024-01-23 14:31 pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 15:30 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
@ 2024-01-23 16:01 ` kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 16:30 ` Re: pg_dumpall and owner of the extension Tom Lane <tgl@sss.pgh.pa.us>
2024-01-24 14:13 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 2 replies; 10+ messages in thread
From: kaido vaikla @ 2024-01-23 16:01 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: pgsql-admin
Yes, i have a real problem. To keep things clear in database, my design is:
- every application has own schema
- every schema has owner who is not a user postgres
- only schema owner can do DDL's on schema
So if some application needs some extensions, then i give temporary
suppersuser privilege to schema owner,
if "create extension" needs it, extensions are installed "with schema"
And revoke suppersuser privilege after extension inatall.
I'm not sure, is it my design against postgres concept or not :(.
But in same time, i expect that pg_dumpall will not change ownership or at
least gives some error or something.
br
Kaido
On Tue, 23 Jan 2024 at 17:30, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> On Tue, 2024-01-23 at 16:31 +0200, kaido vaikla wrote:
> > pg_pumpall (13.4) changes owner of the extension.
> >
> > [Extension created by user A, dump restored by user B -> Extension
> objects belong to B]
> >
> > Manual says "The user who runs CREATE EXTENSION becomes the owner of the
> extension".
> > So pg_dumpall is not aware who ran "CREATE EXTENSION"?
>
> The user who runs CREATE EXTENSION is the user who restores the dump,
> hence the
> changed ownership of the extension objects.
>
> There is no ALTER EXTENSION ... OWNER TO to change the owner to the
> original user,
> which is probably what would be needed in this case.
>
> This is arguably a bug.
>
> Trawling the archives, I found this pertinent thread:
>
> https://www.postgresql.org/message-id/flat/4E1F1072.3010300%40enterprisedb.com
>
> I looked for the referenced discussion, and all I found was this:
>
> https://www.postgresql.org/message-id/flat/21857.1297101968%40sss.pgh.pa.us#e2697a586e2aecbe175d3ce1...
>
> That sounds to me like ALTER EXTENSION ... OWNER TO was originally planned,
> but never implemented:
>
> "BTW, on trying this I notice that pg_dump's default approach to
> ownership doesn't work because of the lack of an ALTER EXTENSION
> OWNER TO command. I'm going to go ahead and add extowner to the catalog
> anyway, because it's easy and I'm convinced we're going to want it
> later. But I don't feel like writing ALTER EXTENSION OWNER TO right
> now, so pg_dump will continue its current behavior of creating the
> extension as the user running the script."
>
> Obviously nobody has felt like implementing ALTER EXTENSION ... OWNER TO
> in the dozen years that followed that statement...
>
> This was probably not a real problem for anybody, because traditionally
> you needed a superuser to run CREATE EXTENSION, and functions are
> executable
> by everybody by default, so you normally don't notice a difference.
>
> Now that we have trusted extensions that don't require a superuser to
> create, things might have changed. It would be interesting to know if you
> have a real problem with the current behavior, which would be an argument
> in favor of fixing the omission.
>
> Yours,
> Laurenz Albe
>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: pg_dumpall and owner of the extension
2024-01-23 14:31 pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 15:30 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-23 16:01 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
@ 2024-01-23 16:30 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-01-23 16:40 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
1 sibling, 1 reply; 10+ messages in thread
From: Tom Lane @ 2024-01-23 16:30 UTC (permalink / raw)
To: kaido vaikla <kaido.vaikla@gmail.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-admin
kaido vaikla <kaido.vaikla@gmail.com> writes:
> Yes, i have a real problem. To keep things clear in database, my design is:
> - every application has own schema
> - every schema has owner who is not a user postgres
> - only schema owner can do DDL's on schema
> So if some application needs some extensions, then i give temporary
> suppersuser privilege to schema owner,
> if "create extension" needs it, extensions are installed "with schema"
> And revoke suppersuser privilege after extension inatall.
> I'm not sure, is it my design against postgres concept or not :(.
Well, it's certainly creating a problem for pg_dump: the alleged owner
of the extension doesn't have enough privilege to install it. The
easiest way to make pg_dump support this would be to have it issue
something like
SET ROLE extension_owner;
CREATE EXTENSION foo;
RESET ROLE;
but that would fail for you.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: pg_dumpall and owner of the extension
2024-01-23 14:31 pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 15:30 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-23 16:01 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 16:30 ` Re: pg_dumpall and owner of the extension Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-01-23 16:40 ` kaido vaikla <kaido.vaikla@gmail.com>
0 siblings, 0 replies; 10+ messages in thread
From: kaido vaikla @ 2024-01-23 16:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-admin
Tom,
Before export i gave superuser privilege to extension owner.
Problem is not does user have privileges enough, but like you said
"Yeah, pg_dump makes no effort to restore extensions with the same
owner"
br
Kido
On Tue, 23 Jan 2024 at 18:30, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> kaido vaikla <kaido.vaikla@gmail.com> writes:
> > Yes, i have a real problem. To keep things clear in database, my design
> is:
> > - every application has own schema
> > - every schema has owner who is not a user postgres
> > - only schema owner can do DDL's on schema
>
> > So if some application needs some extensions, then i give temporary
> > suppersuser privilege to schema owner,
> > if "create extension" needs it, extensions are installed "with schema"
> > And revoke suppersuser privilege after extension inatall.
> > I'm not sure, is it my design against postgres concept or not :(.
>
> Well, it's certainly creating a problem for pg_dump: the alleged owner
> of the extension doesn't have enough privilege to install it. The
> easiest way to make pg_dump support this would be to have it issue
> something like
>
> SET ROLE extension_owner;
> CREATE EXTENSION foo;
> RESET ROLE;
>
> but that would fail for you.
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: pg_dumpall and owner of the extension
2024-01-23 14:31 pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 15:30 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-23 16:01 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
@ 2024-01-24 14:13 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-24 17:04 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
1 sibling, 1 reply; 10+ messages in thread
From: Laurenz Albe @ 2024-01-24 14:13 UTC (permalink / raw)
To: kaido vaikla <kaido.vaikla@gmail.com>; +Cc: pgsql-admin
On Tue, 2024-01-23 at 18:01 +0200, kaido vaikla wrote:
> Yes, i have a real problem. To keep things clear in database, my design is:
> - every application has own schema
> - every schema has owner who is not a user postgres
> - only schema owner can do DDL's on schema
>
> So if some application needs some extensions, then i give temporary suppersuser privilege to schema owner,
> if "create extension" needs it, extensions are installed "with schema" And revoke suppersuser privilege after extension inatall.
> I'm not sure, is it my design against postgres concept or not :(.
>
> But in same time, i expect that pg_dumpall will not change ownership or at least gives some error or something.
I think your expectation is founded, and the current behavior is surprising.
At first, I thought that would be a security problem in combination with
trusted extensions, but then the objects from a trusted extension always
belong to the bootstrap superuser.
So, all extension objects always belong to a superuser, and a change in
ownership to a different after a restore won't be a privilege escalation.
In practice, it doesn't matter much to which superuser extension objects
belong.
Your usage pattern sort of breaks that. I think that your practice of
temporarily elevating the prospective extension owner to superuser is
a questionable one. You end up having extension objects owned by a
non-superuser. That probably won't make much difference in most cases,
but it could matter for SECURITY DEFINER functions or views that use
restricted objects. And if the extension object owner changes after a
restore, the behavior could change.
I don't really see what you are expecting to gain from your design.
Instead of temporarily elevating the schema owner's privileges, why
don't you create the extension as superuser right away?
(As an aside: you need a superuser to turn sumebody into a superuser.
Don't tell me that your application is connecting as superuser...)
So while I think that the current behavior is less than ideal, I don't
see it as a massive problem that needs to be fixed. What is it that
stops working for you after the restore?
Perhaps some documentation for the surprising behavior might be in place.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: pg_dumpall and owner of the extension
2024-01-23 14:31 pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 15:30 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-23 16:01 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-24 14:13 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
@ 2024-01-24 17:04 ` kaido vaikla <kaido.vaikla@gmail.com>
2024-01-29 07:57 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 10+ messages in thread
From: kaido vaikla @ 2024-01-24 17:04 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: pgsql-admin
My main point is, if object in database (table, function etc) should not be
owned by bootstrap superuser, then avoid it: owner postgres
On Wed, 24 Jan 2024 at 16:13, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> I don't really see what you are expecting to gain from your design.
> Instead of temporarily elevating the schema owner's privileges, why
> don't you create the extension as superuser right away?
>
It's quite common that initialization needs more privilege than usage
(for example, as root user #yum install postgresql-server)
> (As an aside: you need a superuser to turn sumebody into a superuser.
> Don't tell me that your application is connecting as superuser...)
>
No,no. vice versa, seems my problem is that i try push out everything from
superuser
> So while I think that the current behavior is less than ideal, I don't
> see it as a massive problem that needs to be fixed. What is it that
> stops working for you after the restore?
Currently nothing, but i have tens of pg instances waiting for
export-import. And design is same:
schema owner is extension owner and extension is intalled into this
application schema.
Why I use it, is because if i have lot of different apps (schemas) with
different extensions then overview is better.
"Default way": public schema and owner postgres for all extension is a big
mess.
If this design is against concept of extensions or postgres i will change
it in future. Would be nice, if you can point some doc.
But pg_dumpall can't change ownership without any notification i think.
CREATE EXTENSION doc should be change like:
"The user who runs CREATE EXTENSION becomes the owner of the extension
until first export-import" ;)
br
Kaido
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: pg_dumpall and owner of the extension
2024-01-23 14:31 pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 15:30 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-23 16:01 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-24 14:13 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-24 17:04 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
@ 2024-01-29 07:57 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-29 09:03 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Laurenz Albe @ 2024-01-29 07:57 UTC (permalink / raw)
To: kaido vaikla <kaido.vaikla@gmail.com>; +Cc: pgsql-admin
On Wed, 2024-01-24 at 19:04 +0200, kaido vaikla wrote:
> CREATE EXTENSION doc should be change like:
> "The user who runs CREATE EXTENSION becomes the owner of the extension until first export-import" ;)
Here is a patch that implements something like that.
Yours,
Laurenz Albe
Attachments:
[text/x-patch] v1-0001-Document-that-pg_dump-changes-extension-ownership.patch (1.7K, ../../89497a7a56d5db84084d9eac3ca062176bc311e7.camel@cybertec.at/2-v1-0001-Document-that-pg_dump-changes-extension-ownership.patch)
download | inline diff:
From c09aca36b0f15728861c321c9d15be1e8195cf55 Mon Sep 17 00:00:00 2001
From: Laurenz Albe <laurenz.albe@cybertec.at>
Date: Mon, 29 Jan 2024 08:55:24 +0100
Subject: [PATCH v1] Document that pg_dump changes extension ownership
After restoring a dunp, extensions will belong to the restoring
user. This is no security problem, since the members of an
extension will belong to a superuser no matter what. But it can
be annoying for a non-superuser who installs a trusted extension
and finds that she cannot drop the extension after a restore.
Arguably that's a bug, and there should be a command ALTER
EXTENSION ... OWNER TO that gets added to the dump, but until
somebody gets to implement such a command, we had better document
the current behavior.
Author: Laurenz Albe
Discussion: https://postgr.es/m/CA%2B427g-YecPcvrHLJjoP92gDQy199qvvKCj_OvXhR3qmeu0zRQ%40mail.gmail.com
---
doc/src/sgml/ref/create_extension.sgml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/ref/create_extension.sgml b/doc/src/sgml/ref/create_extension.sgml
index ca2b80d669..4ec34f31e2 100644
--- a/doc/src/sgml/ref/create_extension.sgml
+++ b/doc/src/sgml/ref/create_extension.sgml
@@ -49,7 +49,9 @@ CREATE EXTENSION [ IF NOT EXISTS ] <replaceable class="parameter">extension_name
The user who runs <command>CREATE EXTENSION</command> becomes the
owner of the extension for purposes of later privilege checks, and
normally also becomes the owner of any objects created by the
- extension's script.
+ extension's script. Note that the ownership of extensions is not preserved
+ by <command>pg_dump</command>: after restoring a dump, extensions will
+ belong to the user who performed the restore.
</para>
<para>
--
2.43.0
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: pg_dumpall and owner of the extension
2024-01-23 14:31 pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 15:30 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-23 16:01 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-24 14:13 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-24 17:04 ` Re: pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-29 07:57 ` Re: pg_dumpall and owner of the extension Laurenz Albe <laurenz.albe@cybertec.at>
@ 2024-01-29 09:03 ` kaido vaikla <kaido.vaikla@gmail.com>
0 siblings, 0 replies; 10+ messages in thread
From: kaido vaikla @ 2024-01-29 09:03 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: pgsql-admin
Thnx, at least something.
Especially for them, whose use pg_dumpall as a backup tool.
br
Kaido
On Mon, 29 Jan 2024 at 09:57, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> On Wed, 2024-01-24 at 19:04 +0200, kaido vaikla wrote:
> > CREATE EXTENSION doc should be change like:
> > "The user who runs CREATE EXTENSION becomes the owner of the extension
> until first export-import" ;)
>
> Here is a patch that implements something like that.
>
> Yours,
> Laurenz Albe
>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: pg_dumpall and owner of the extension
2024-01-23 14:31 pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
@ 2024-01-23 16:13 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 10+ messages in thread
From: Tom Lane @ 2024-01-23 16:13 UTC (permalink / raw)
To: kaido vaikla <kaido.vaikla@gmail.com>; +Cc: pgsql-admin
kaido vaikla <kaido.vaikla@gmail.com> writes:
> So pg_dumpall is not aware who ran "CREATE EXTENSION"?
Yeah, pg_dump makes no effort to restore extensions with the same
owner. This didn't matter back when the feature was designed,
because you had to be superuser to install most interesting
extensions. I suppose we should revisit the choice sometime.
There's no ALTER EXTENSION OWNER command, though, so it would
need to be done in a different way from other object types.
Not sure offhand what the downsides of that would be.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2024-01-29 09:03 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-01-23 14:31 pg_dumpall and owner of the extension kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 15:30 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-23 16:01 ` kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 16:30 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-01-23 16:40 ` kaido vaikla <kaido.vaikla@gmail.com>
2024-01-24 14:13 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-24 17:04 ` kaido vaikla <kaido.vaikla@gmail.com>
2024-01-29 07:57 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-01-29 09:03 ` kaido vaikla <kaido.vaikla@gmail.com>
2024-01-23 16:13 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox