Re: Bugs in TOAST handling, OID assignment and redo recovery
От | Pavan Deolasee |
---|---|
Тема | Re: Bugs in TOAST handling, OID assignment and redo recovery |
Дата | |
Msg-id | CABOikdOja5qt65Lj0Om3GQATO78aXphtrsQG7fRHFvRjbMZy6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bugs in TOAST handling, OID assignment and redo recovery (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Ответы |
Re: Bugs in TOAST handling, OID assignment and redo recovery
|
Список | pgsql-hackers |
On Tue, Apr 10, 2018 at 7:24 PM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
-- Hi Heikki,On Tue, Apr 10, 2018 at 7:07 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
It would seem more straightforward to add a snapshot parameter to GetNewOidWithIndex(), so that the this one caller could pass SnapshotToast, while others pass SnapshotDirty. With your patch, you check the index twice: first with SnapshotDirty, in GetNewOidWithIndex(), and then with SnapshotToast, in the caller.Hmm. I actually wrote my first patch exactly like that. I am trying to remember why I discarded that approach. Was that to do with the fact that SnapshotToast can't see all toast tuples either? Yeah, I think so. For example, it won't see tuples with uncommitted-xmin, leading to different issues. Now it's unlikely that we will have a OID conflict where the old tuple has uncommitted-xmin, but not sure if we can completely rule that out.
Or may be we simply err on the side of caution and scan the toast table with SnapshotAny while looking for a duplicate? That might prevent us from reusing an OID for a known-dead tuple, but should save us a second index scan and still work.
Thanks,
Pavan
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: