Hi Daniel,
I've removed the LOCK statement, it was there to deal with a rare edge
case where the versioning.sql was loaded concurrently, which is bad as
the IF NOT EXISTS on the SCHEMA doesn't work without the lock, resulting
in a hard failure. AFAIK the rare case where we needed this was resolved
differently since then, so I guess it's fine to reduce the privilege
requirement.
As for using transactions instead: did you see the "BEGIN"? We are,
doesn't help if you have to concurrent transactions try to create the
same SCHEMA.
That said, it means loading versioning by two processes concurrently can
fail badly now. So don't parallelize your database setup ;-).
Happy hacking!
Christian
On 10/12/24 19:38, Daniel Golle wrote:
Hi!
I've been playing with recent GNUnet releases and noticed that GNUnet
now requirs PostgreSQL super user privileges.
This is problematic and GNUnet should be able to run with only a more
limited set of PostgreSQL permissions.
The reason for that new requirement is
LOCK TABLE pg_catalog.pg_namespace;
being done in src/lib/pq/versioning.sql
The stackoverflow link provided in the comment above suggests that
locking internal tables is generally not a good idea, and that
transactions should rather be used instead.
Did you consider using transactions? Or is there a good reason not to?
Cheers
Daniel
