From: | "Michael Paesold" <mpaesold(at)gmx(dot)at> |
---|---|
To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andrew Sullivan" <andrew(at)libertyrms(dot)info>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [SQL] [GENERAL] CURRENT_TIMESTAMP |
Date: | 2002-10-04 17:34:01 |
Message-ID: | 022d01c26bcc$3afc0310$4201a8c0@beeblebrox |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> > That is a very good point. At least with serializable transactions it
seems
> > perfectly reasonable to return a frozen CURRENT_TIMESTAMP. What do you
think
> > about read-commited level? Can time be commited? ;-)
> > It would be even more surprising to new users if the implementation of
> > CURRENT_TIMESTAMP would depend on trx serialization level.
>
> Yes, CURRENT_TIMESTAMP changing based on transaction serializable/read
> commited would be quite confusing. Also, because our default is read
> committed, we would end up with CURRENT_TIMESTAMP being statement level,
> which actually does give us a logical place to allow CURRENT_TIMESTAMP
> to change, but I thought people voted against that.
>
> However, imagine a query that used CURRENT_TIMESTAMP in the WHERE clause
> to find items that were not in the future. Would a CURRENT_TIMESTAMP
> test in a multi-statement transaction want to check based on transaction
> start, or on the tuples visible at the time the statement started?
Well, in a serializable transaction there would be no difference at all, at
least if CURRENT_TIMESTAMP is consistent within the transaction. Any changes
outside the transaction after SetQuerySnapshot would not be seen by the
transaction anyway.
In read-commited, I think it's different. If CURRENT_TIMESTAMP is frozen,
than the behavior would be the same as in serializable level, if
CURRENT_TIMESTAMP advances with each statement, the result would also
change. That is an inherent problem with read-commited though and has not so
much to do with the timestamp behavior.
Regards,
Michael Paesold
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Clift | 2002-10-04 17:35:19 | Re: Threaded Sorting |
Previous Message | Bruce Momjian | 2002-10-04 17:28:47 | Re: Threaded Sorting |