On Sun, Apr 10, 2011 at 5:23 AM, Noah Misch <noah@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 <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.
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
