Re: [ODBC] getting rid of SnapshotNow
От | Inoue, Hiroshi |
---|---|
Тема | Re: [ODBC] getting rid of SnapshotNow |
Дата | |
Msg-id | 51E880CD.6060304@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [ODBC] getting rid of SnapshotNow (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [ODBC] getting rid of SnapshotNow
|
Список | pgsql-hackers |
(2013/07/18 23:54), Robert Haas wrote: > On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: