Re: ALTER TABLE lock strength reduction patch is unsafe

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER TABLE lock strength reduction patch is unsafe
Дата
Msg-id 16596.1393973639@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ALTER TABLE lock strength reduction patch is unsafe  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe Reply-To:
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Changeset Extraction v7.9.1