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