Re: Extension pg_trgm, permissions and pg_dump order

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Färber, Franz-Josef (StMUK) <Franz-Josef(dot)Faerber(at)stmuk(dot)bayern(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Extension pg_trgm, permissions and pg_dump order
Date: 2022-05-31 15:28:55
Message-ID: 20220531152855.GA2236210@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general

On Tue, May 31, 2022 at 01:30:11PM +0900, Michael Paquier wrote:
> On Sat, May 28, 2022 at 09:34:03PM -0700, Noah Misch wrote:
>> On Sat, May 28, 2022 at 08:30:33PM -0700, Nathan Bossart wrote:
>>> I started looking at the problem and hacked together a
>>> proof-of-concept based on your first candidate that seems to fix the
>>> reported issue. However, from the upthread discussion, it is not clear
>>> whether there is agreement on the approach. IIUC there are still many
>>> other code paths that would require a similar treatment, so perhaps
>>> identifying all of those would be a good next step.
>>
>> Agreed. To identify them, perhaps put an ereport(..., errbacktrace()) in
>> aclmask(), then write some index-creating DDL that refers to the
>> largest-possible number of objects.
>
> While we've reached an agreement on the thread related to the
> corruption caused by the incorrect snapshots for concurrent index
> builds, this thread seems to be stalling a bit and we should try to
> move on before getting a release out. Is somebody looking at what we
> have here?

I've spent some time looking at all the code impacted by a117ceb and
0abc1a0, and I've yet to identify any additional problems besides the one
with ResolveOpClass(). However, I'm far from confident in this analysis,
and I still need to try out the ereport() approach that Noah suggested. I
would welcome any assistance identifying other problem areas.

For now, I've attached a slightly polished patch to fix the reported issue.
It's still rather hacky, and it does nothing to reduce the complexity of
the current approach of weaving between user IDs, but perhaps it can serve
as a stopgap solution.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v2-0001-Ensure-privilege-checks-in-CREATE-INDEX-run-as-ca.patch text/x-diff 5.6 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2022-05-31 15:30:51 Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Previous Message Peter Geoghegan 2022-05-31 14:54:48 Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Ross 2022-05-31 17:46:52 Logically replicated table has no visible rows
Previous Message Tom Lane 2022-05-31 15:19:42 Re: Build Postgres On AIX