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
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 |
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 |