Where to call SetQuerySnapshot

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Where to call SetQuerySnapshot
Date: 2002-10-08 00:39:04
Message-ID: 27633.1034037544@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I noticed that the new EXECUTE statement does not call SetQuerySnapshot,
which seems like a bad thing. The omission is masked by the defensive
code in CopyQuerySnaphot, which will automatically do SetQuerySnapshot
if it hasn't been done yet in the current transaction. However, this
doesn't provide the right behavior in read-committed mode: if we are
inside a transaction and not the first query, I'd think EXECUTE should
take a new snapshot; but it won't.

Comparable code can be found in COPY OUT, for which tcopy/utility.c
does SetQuerySnapshot() before calling the command-specific routine.

Questions for the list:

1. Where is the cleanest place to call SetQuerySnapshot() for utility
statements that need it? Should we follow the lead of the existing
COPY code, and add the call to the ExecuteStmt case in utility.c?
Or should we move the calls into the command-specific routines (DoCopy
and ExecuteQuery)? Or perhaps it should be done in postgres.c, which
has this responsibility for non-utility statements?

2. Would it be a good idea to change CopyQuerySnapshot to elog(ERROR)
instead of silently creating a snapshot when none has been made?
I think I was the one who put in its auto-create-snapshot behavior,
but I'm now feeling like that was a mistake. It hides omissions that
we should want to find.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2002-10-08 00:42:17 Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]
Previous Message Curtis Faith 2002-10-07 23:04:58 Re: Analysis of ganged WAL writes