Re: pg_dump needs SELECT privileges on irrelevant extension table
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jacob Champion <jchampion@timescale.com>
Cc: PostgreSQL Bugs <pgsql-bugs@lists.postgresql.org>
Date: 2023-03-20T17:43:26Z
Lists: pgsql-bugs, pgsql-hackers
Jacob Champion <jchampion@timescale.com> writes: > We have a situation where we need to revoke SELECT on a table that > belongs to our extension, and we also need to let less privileged users > dump the extension's external config tables. In general, we don't expect that random minimum-privilege users can do a database-wide pg_dump, so I'm not entirely sure that I buy that this is a case we should cater to. Why shouldn't your dump user have enough privilege to take this lock? I'd be more willing to consider the proposed patch if it weren't such a hack --- as you say, it doesn't fix the problem when the table has policies, so it's hardly a general-purpose solution. I fear that it's also fairly expensive: adding sub-selects to the query we must do before we can lock any tables is not appetizing, because making that window wider adds to the risk of deadlocks, dump failures, etc. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Don't try to dump RLS policies or security labels for extension objects.
- a70f2a57f233 17.0 landed
- 64d2467fc8d3 16.2 landed
- f15147df625f 15.6 landed
- 9e08789d4832 13.14 landed
- 891afa84c27e 12.18 landed
- 15439205d8ce 14.11 landed