Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
От | Alvaro Herrera |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
Дата | |
Msg-id | 20160615184537.GA20738@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Avoid extra locks in
GetSnapshotData if old_snapshot_threshold <
Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
Список | pgsql-hackers |
Robert Haas wrote: > On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner <kgrittn@gmail.com> > wrote: > > The test I showed creates a situation which (to ANALYZE) is > > identical to what you describe -- ANALYZE sees a page with an LSN > > recent enough that it could have been (and actually has been) > > pruned. Why would it be better for the ANALYZE to fail than to > > complete? > > As I understand it, the reason we need to sometimes give "ERROR: > snapshot too old" after early pruning is because we might otherwise > give the wrong answer. So what constitutes "the wrong answer"? A regular transaction reading a page and not finding a tuple that should have been there but was removed, is a serious problem and should be aborted. For ANALYZE it may not matter a great deal. Some very old tuple that might have been chosen for the sample is not there; a different tuple is chosen instead, so the stats might be slightly difference. No big deal. Maybe it is possible to get into trouble if you're taking a sample for an expression index. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: