Robert Haas escribió:
> 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.
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
