Re: row-attribute in EXPLAIN-output doesn't match count(*)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-sql(at)postgresql(dot)org
Subject: Re: row-attribute in EXPLAIN-output doesn't match count(*)
Date: 2005-04-14 23:26:09
Message-ID: 27509.1113521169@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Greg Stark <gsstark(at)mit(dot)edu> writes:
> This is presumably because of the long-standing issue that Postgres takes the
> snapshot as soon as the BEGIN is issued.

No, we don't set the snapshot until the first DML query is issued. This
is critical for serializable transactions: you have to be able to take
locks before the snapshot is frozen.

There are at least three interesting events involved:
1 BEGIN command issued
2 First lock taken (presumably as a consequence of another command)
3 Transaction snapshot taken (ditto; might be a different command)

We have to start the transaction no later than event #2 since there has
to be something to hold the lock. But it'd be easy enough to decouple
this from BEGIN, and it'd be good enough to solve the "COMMIT;BEGIN"
problem.

Which of these three times do you think now() ought to correspond to?
I recall having argued that it should be event #3 since that corresponds
to the database snapshot you see. 100% backwards compatibility would
require setting now() at event #1, but will anyone weep if we change that?

regards, tom lane

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message shaun 2005-04-15 03:30:02 CREATE USER in side a TRIGGER FUNCTION
Previous Message Tom Lane 2005-04-14 23:20:10 Re: row-attribute in EXPLAIN-output doesn't match count(*)