Re: ALTER TABLE lock strength reduction patch is unsafe - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER TABLE lock strength reduction patch is unsafe
Date
Msg-id 16596.1393973639@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER TABLE lock strength reduction patch is unsafe  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-03-04 16:37:48 -0500, Tom Lane wrote:
>> However, it seems possible that we could have a mode in which a read-only
>> session did all its catalog fetches according to the transaction snapshot.
>> That would get us to a situation where the backend-internal lookups that
>> ruleutils relies on would give the same answers as queries done by
>> pg_dump.  Robert's work on getting rid of SnapshotNow has probably moved
>> that much closer than it was before, but it's still not exactly a trivial
>> patch.

> The most interesting bit seems to be the cache invalidation handling. It
> would need to be something like PushCatalogSnapshot() which disables
> applying invals, including catchup interrupts and all. If the sinval
> queue hasn't overflown while that snapshot was up, everything is fine we
> just need to apply all pending invalidations, if it has, we need to do a
> InvalidateSystemCaches().

Yeah, at least within the transaction we would simply ignore invals.
To avoid causing sinval queue overrun (which would hurt everyone
system-wide), my inclination would be to just drop invals on the floor all
the time when in this mode, and forcibly do InvalidateSystemCaches at
transaction end.  For pg_dump, at least, there is no value in working any
harder than that, since it's going to quit at transaction end anyhow.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe Reply-To:
Next
From: Andres Freund
Date:
Subject: Re: Changeset Extraction v7.9.1