Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
От | Kevin Grittner |
---|---|
Тема | Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
Дата | |
Msg-id | CACjxUsMnqGZf+_QBhNTNq6PZ--27Tp4Q1RuZ0n+Cog2R3+zjqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Re: pgsql: Avoid extra locks in
GetSnapshotData if old_snapshot_threshold <
(Kevin Grittner <kgrittn@gmail.com>)
Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-committers |
On Tue, May 24, 2016 at 4:56 PM, Andres Freund <andres@anarazel.de> wrote: > The LSNs of the created index pages will be new, and we'll thus > not necessarily error out when requried. It is *old* LSNs that are *safe* -- *new* LSNs are what trigger the "snapshot too old" error. So your observation may be a reason that there is not, in fact, any bug here. That said, even if there is no chance that using the index could generate incorrect results, it may be worth looking at whether avoiding index use (as mentioned below) might avoid false positives, and have enough value as an optimization to add. Of course, if that is the case, there is the question of whether that is appropriate for 9.6 or material for the first version 10 CF. > At the very least we'd have to set indexInfo->ii_BrokenHotChain > in that case. If there is a bug, this is what I will look at first -- having queries avoid the index if they are using an old snapshot, rather than throwing an error. > As far as I can see normal index builds will allow concurrent hot > prunes and everything; since those only require page-level > exclusive locks. > > So for !concurrent builds we might end up with a corrupt index. ... by which you mean an index that omits certainly-dead heap tuples which have been the subject of early pruning or vacuum, even if there are still registered snapshots that include those tuples? Or do you see something else? Again, since both the heap pages involved and all the new index pages would have LSNs recent enough to trigger the old snapshot check, I'm not sure where the problem is, but will review closely to see what I might have missed. > I think many of the places relying on heap scans with !mvcc > snapshots are problematic in that way. Outdated reads will not be > detected by TestForOldSnapshot() (given the (snapshot)->satisfies > == HeapTupleSatisfiesMVCC condition therein), and rely on the > snapshot to be actually working. E.g. CLUSTER/ VACUUM FULL rely > on accurate HEAPTUPLE_RECENTLY_DEAD Don't the "RECENTLY" values imply that the transaction is still running which cause the tuple to be dead? Since tuples are not subject to early pruning or vacuum when that is the case, where do you see a problem? The snapshot itself has the usual xmin et al., so I'm not sure what you might mean by "the snapshot to be actually working" if not the override at the time of pruning/vacuuming. > If an old session with >= repeatable read accesses a clustered > table (after the cluster committed), they'll now not see any > errors, because all the LSNs look new. Again, it is new LSNs that trigger errors; if the page has not been written recently the LSN is old and there is no error. I think you may be seeing problems based on getting the basics of this backwards. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-committers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: pgsql: Be more predictable about reporting "lock timeout" vs "statement