Re: BUG #5856: pg_attribute.attinhcount is not correct. - Mailing list pgsql-hackers

From Noah Misch
Subject Re: BUG #5856: pg_attribute.attinhcount is not correct.
Date
Msg-id 20110410122347.GE10697@tornado.leadboat.com
Whole thread Raw
In response to Re: BUG #5856: pg_attribute.attinhcount is not correct.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: BUG #5856: pg_attribute.attinhcount is not correct.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sun, Apr 10, 2011 at 07:35:53AM -0400, Robert Haas wrote:
> On Sun, Apr 10, 2011 at 6:36 AM, Noah Misch <noah@leadboat.com> wrote:
> > 3. Make AlterTableCreateToastTable acquire only ShareUpdateExclusiveLock and
> > remove the pass-usage heuristic from ATRewriteCatalogs.  For this to be valid,
> > toast_insert_or_update() must behave reasonably in the face of a relation
> > concurrently acquiring a TOAST table.  Since it takes reltoastrelid from the
> > relcache, toast_insert_or_update() will not act on the change in the middle of a
> > single call.  Even if it did, I don't see any risks.
> >
> > I'd lean toward #3 if someone else is also confident in its correctness.
> > Otherwise, #1 seems like the way to go.  Preferences?  Other ideas?
>
> I haven't scrutinized the code but I would prefer #3 if it's viable
> without too much of a code footprint.

It's certainly compact; patch attached.

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: BUG #5856: pg_attribute.attinhcount is not correct.
Next
From: Jesper Krogh
Date:
Subject: Re: k-neighbourhood search in databases