Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Дата
Msg-id CACjxUsNERjp3BBBWfgs4mg3CyA+O0ATN1=O4NM3MWC3_LHP-dg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner <kgrittn@gmail.com> wrote:
>> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund <andres@anarazel.de> wrote:
>>
>>> I'm a bit confused, why aren't we simply adding LSN interlock
>>> checks for toast? Doesn't look that hard? Seems like a much more
>>> natural course of fixing this issue?
>>
>> I took some time trying to see what you have in mind, and I'm
>> really not "getting it".
>
> Isn't it possible if we initialize lsn and whenTaken in SnapshotToast
> when old_snapshot_threshold > 0 and add a check for
> HeapTupleSatisfiesToast in TestForOldSnapshot()?

With that approach, how will we know *not* to generate an error
when reading the chain of tuples for a value we are deleting.  Or
positioning to modify an index on toast data.  Etc., etc. etc.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Documentation fix for CREATE FUNCTION
Следующее
От: Mike Blackwell
Дата:
Сообщение: application_name in process name?