From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
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: [ODBC] getting rid of SnapshotNow |
Date: | 2013-07-18 15:54:06 |
Message-ID: | 20130718155406.GM4165@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-odbc |
Robert Haas escribió:
> 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.
Yeah ... SnapshotError is a way to ensure the server doesn't crash if an
extension hasn't been fixed in order not to cause a crash if it doesn't
use the APIs correctly. However, there's many other ways for a
C-language extension to cause crashes, so I don't think this is buying
us much.
> >> 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.
They don't show up in a quick grep of psqlodbc's source code, FWIW.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-07-18 15:55:12 | Re: Improvement of checkpoint IO scheduler for stable transaction responses |
Previous Message | Greg Smith | 2013-07-18 15:41:48 | Re: Improvement of checkpoint IO scheduler for stable transaction responses |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-07-18 16:01:39 | Re: [ODBC] getting rid of SnapshotNow |
Previous Message | Robert Haas | 2013-07-18 14:54:15 | Re: getting rid of SnapshotNow |