start of transaction (was: Re: [PERFORM] Help with count(*)) - Mailing list pgsql-hackers

From Neil Conway
Subject start of transaction (was: Re: [PERFORM] Help with count(*))
Date
Msg-id 87n0avaonp.fsf@mailbox.samurai.com
Whole thread Raw
Responses Re: start of transaction (was: Re: [PERFORM] Help with count(*))  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> That's defensible when the user issued the BEGIN himself.  When the
> BEGIN is coming from some interface library's autocommit logic, it's
> a lot less defensible.  If you consult the archives, you will find
> actual user complaints about "why is now() returning a very old time?"
> that we traced to use of interface layers that handle "commit()" by
> issuing "COMMIT; BEGIN;".

Hmmm... I agree this behavior isn't ideal, although I can see the case
for viewing this as a mistake by the application developer: they are
assuming that they know exactly when transactions begin, which is not
a feature provided by their language interface. They should be using
current_timestamp, and/or changing their language interface's
configuration.

That said, I think this is a minor irritation at best. The dual
drawbacks of breaking backward compatibility and making the BEGIN
semantics more confusing is enough to leave me satisfies with the
status quo.

If we do change this, I think Dennis' idea of making now() always
return the same value within a given transaction is interesting: that
might be a way to fix this problem without confusing the semantics of
BEGIN.

-Neil



pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: start of transaction (was: Re: [PERFORM] Help with count(*))
Next
From: Tom Lane
Date:
Subject: Re: start of transaction (was: Re: [PERFORM] Help with count(*))