Robert Haas escribió: > On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
