Re: [HACKERS] getting rid of SnapshotNow

From: "Inoue, Hiroshi" <inoue(at)tpf(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org
Subject: Re: [HACKERS] getting rid of SnapshotNow
Date: 2013-07-18 23:57:01
Message-ID: 51E880CD.6060304@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-odbc

(2013/07/18 23:54), Robert Haas wrote:
> On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> 1. snapshot-error-v1.patch introduces a new special snapshot, called
>>> SnapshotError. In the cases where we set SnapshotNow as a sort of
>>> default snapshot, this patch changes the code to use SnapshotError
>>> instead. This affects scan->xs_snapshot in genam.c and
>>> estate->es_snapshot in execUtils.c. This passes make check-world, so
>>> apparently there is no code in the core distribution that does this.
>>> However, this is safer for third-party code, which will ERROR instead
>>> of seg faulting. The alternative approach would be to use
>>> InvalidSnapshot, which I think would be OK too if people dislike this
>>> approach.
>>
>> FWIW, I think using InvalidSnapshot would be preferable to introducing
>> a new concept for what's pretty much the same thing.
>
> Andres voted the other way on the previous thread. I'll wait and see
> if there are any other opinions. The SnapshotError concept seemed
> attractive to me initially, but I'm not as excited about it after
> seeing how it turned out, so maybe it's best to do it as you suggest.
>
>>> With that done, the only remaining uses of SnapshotNow in our code
>>> base will be in currtid_byreloid() and currtid_byrelname(). So far no
>>> one on this list has been able to understand clearly what the purpose
>>> of those functions is, so I'm copying this email to pgsql-odbc in case
>>> someone there can provide more insight.
>>
>> I had the idea they were used for a client-side implementation of WHERE
>> CURRENT OF. Perhaps that's dead code and could be removed entirely?
>
> It's been reported that ODBC still uses them.

Though PostgreSQL's TID is similar to Orale's ROWID, it is transient
and changed after update operations unfortunately. I implemented
the currtid_xx functions to supplement the difference. For example

currtid(relname, original tid)

(hopefully) returns the current tid of the original row when it is
updated.

regards,
Hiroshi Inoue

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karol Trzcionka 2013-07-18 23:57:03 Re: [v9.4] row level security
Previous Message Indrajit Roychoudhury 2013-07-18 23:46:03 Re: [HACKERS] Fatal error after starting postgres : sys identifiers must be different

Browse pgsql-odbc by date

  From Date Subject
Next Message Noah Misch 2013-07-19 04:31:56 Re: getting rid of SnapshotNow
Previous Message Robert Haas 2013-07-18 16:45:08 Re: [ODBC] getting rid of SnapshotNow