Re: Changing behavior of BEGIN...sleep...do something...COMMIT - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Changing behavior of BEGIN...sleep...do something...COMMIT
Date
Msg-id 24175.1049134862@sss.pgh.pa.us
Whole thread Raw
In response to Re: Changing behavior of BEGIN...sleep...do something...COMMIT  ("scott.marlowe" <scott.marlowe@ihs.com>)
List pgsql-hackers
"scott.marlowe" <scott.marlowe@ihs.com> writes:
> On Fri, 28 Mar 2003, Tom Lane wrote:
>> It seems to me that it'd be fairly easy to make BEGIN cause only
>> a local state change in the backend; the actual transaction need not
>> start until the first subsequent command is received.  It's already
>> true that the transaction snapshot is not frozen at BEGIN time, but
>> only when the first DML or DDL command is received; so this would
>> have no impact on the client-visible semantics.  But a BEGIN-then-
>> sleep-for-awhile client wouldn't interfere with VACUUM anymore.

> What about serializable mode?  Wouldn't that break it?

No.  Even in serializable mode, we don't set the snapshot until the
first DML/DDL command.  (This *has* to be true because if you want to
take any locks via explicit LOCK commands, you need to be able to issue
those before the snapshot is frozen.  Doesn't do you much good to lock
a table if your view of the table will date from before the lock.)

AFAICT the only part of this proposal that would result in any change in
user-visible behavior is the proposal to alter the point where now() is
frozen.  But that's really an independent question.
        regards, tom lane



pgsql-hackers by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: Changing behavior of BEGIN...sleep...do something...COMMIT
Next
From: Tom Lane
Date:
Subject: Re: What's wrong