Re: Extension pg_trgm, permissions and pg_dump order
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Noah Misch <noah@leadboat.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, pgsql-bugs@lists.postgresql.org, Färber, Franz-Josef (StMUK) <Franz-Josef.Faerber@stmuk.bayern.de>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2022-05-31T04:30:11Z
Lists: pgsql-bugs, pgsql-general
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? -- Michael
Commits
-
CREATE INDEX: use the original userid for more ACL checks.
- 88b39e61486a 10.22 landed
- 6d49cc28613b 11.17 landed
- 93731d549e15 12.12 landed
- 8782ce49e4d0 13.8 landed
- ace9973867c2 14.5 landed
- 00377b9a02b8 15.0 landed