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 по дате отправления: