Re: Extension pg_trgm, permissions and pg_dump order - Mailing list pgsql-bugs

From Noah Misch
Subject Re: Extension pg_trgm, permissions and pg_dump order
Date
Msg-id 20220609051708.GA3615673@rfd.leadboat.com
Whole thread Raw
In response to Re: Extension pg_trgm, permissions and pg_dump order  (Noah Misch <noah@leadboat.com>)
Responses Re: Extension pg_trgm, permissions and pg_dump order  (Noah Misch <noah@leadboat.com>)
List pgsql-bugs
On Sun, Jun 05, 2022 at 11:30:56PM -0700, Noah Misch wrote:
> On Fri, Jun 03, 2022 at 11:17:24AM -0700, Nathan Bossart wrote:
> > On Tue, May 31, 2022 at 08:28:55AM -0700, Nathan Bossart wrote:
> > > 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.
> > 
> > Ah, I think I am missing something.  For example, the code that identifies
> > the exclusion operator (immediately following the call to ResolveOpClass())
> > is likely subject to a similar problem.
> 
> That would not surprise me.  Do you have what you need to continue?

I'll use that window on Sunday to review what you have.  If you have work in
progress, please get it to the mailing list by then.



pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #17513: recompressing already-compressed data via VACUUM FULL or CLUSTER does not work
Next
From: PG Bug reporting form
Date:
Subject: BUG #17514: Application with embedded SQL crashes when executing EXEC SQL PREPARE