[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Changing behavior of BEGIN...sleep...do something...COMMIT
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2003-03-31 18:21:02
[Download RAW message or body]

"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


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org
[prev in list] [next in list] [prev in thread] [next in thread]