Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
От | Andres Freund |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
Дата | |
Msg-id | 20160720181213.f4io7gc6lyc377sw@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 2016-07-20 13:59:32 -0400, Robert Haas wrote: > It's hard to believe that it's equally good to use the newest > registered snapshot (which is, I think, what you will often get from > GetActiveSnapshot()) and the oldest registered snapshot (which is what > you will get from pairingheap_first()). It seems to me that we need > to analyze what happens if we choose a snapshot that is older than the > one used to find the datum which contained the toast pointer, and > conversely what happens if we use a snapshot that is newer than the > one we used to find the toast pointer. Yea, the oldest seems better. > Here's an attempt: > > 1. If we pick a snapshot that is older than the one that found the > scan tuple, we might get a "snapshot too old" error that is not > strictly necessary. Right. Which still seems a lot better than essentially pessimizing vacuuming for toast tables considerably. > 2. If we pick a snapshot that is newer than the one that found the > scan tuple, then haven't we failed to fix the problem? I'm not so > sure about this direction, but if it's OK to test an arbitrarily new > snapshot, then I can't see why we need the test at all. I think some argument could be construed why it'd possibly be safe, but I feel a lot better with the other option. Andres
В списке pgsql-hackers по дате отправления: