[go: up one dir, main page]

Re: [ODBC] getting rid of SnapshotNow

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org
Subject: Re: [ODBC] getting rid of SnapshotNow
Date: 2013-07-19 16:11:23
Message-ID: 25211.1374250283@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-odbc

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-07-20 00:49:11 +0900, Hiroshi Inoue wrote:
>> Using SnapshotSelf instead of SnapshotNow for currtid_ () wouldn't
>> matter.

> I think it actually might. You could get into dicey situations if you
> use currtid_ in a query performing updates or inserts because it would
> see the to-be-inserted tuple...

I'm pretty sure Hiroshi-san was only opining about whether it would
matter for ODBC's usage. IIUC, ODBC is using this function to re-fetch
rows that it inserted, updated, or at least selected-for-update in a
previous command of the current transaction, so actually any snapshot
would do fine.

In any case, since I moved the goalposts by suggesting that SnapshotSelf
is just as dangerous as SnapshotNow, what we need to know is whether
it'd be all right to change this code to use a fresh MVCC snapshot;
and if not, why not. It's pretty hard to see a reason why client-side
code would want to make use of the results of a non-MVCC snapshot.

regards, tom lane

In response to Responses Browse pgsql-hackers by date
  From Date Subject
Next Message Josh Berkus 2013-07-19 16:23:56 Re: Using ini file to setup replication
Previous Message Stephen Frost 2013-07-19 16:09:24 LOCK TABLE Permissions
Browse pgsql-odbc by date
  From Date Subject
Next Message Alvaro Herrera 2013-07-19 16:29:33 Re: getting rid of SnapshotNow
Previous Message Andres Freund 2013-07-19 16:02:30 Re: [HACKERS] getting rid of SnapshotNow