On Sun, Apr 10, 2011 at 5:23 AM, Noah Misch <n...@leadboat.com> wrote: > On Sun, Apr 10, 2011 at 07:35:53AM -0400, Robert Haas wrote: >> On Sun, Apr 10, 2011 at 6:36 AM, Noah Misch <n...@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.
Thanks. Committed. It occurred to me to worry that it would be quite unsafe if a TOAST table got *removed* while holding less than AccessExclusiveLock, but it appears we're safe enough from that; I believe it can only happen on a table rewrite, and there's not much chance of that ever requiring a lesser lock strength. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
