From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Michael Paesold <mpaesold(at)gmx(dot)at> |
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-05 04:29:03 |
Message-ID: | 200210050429.g954T3A03697@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
OK, are we agreed to leave CURRENT_TIMESTAMP/now() alone and just add
now("string")? If no one replies, I will assume that is a yes and I
will add it to TODO.
---------------------------------------------------------------------------
Michael Paesold wrote:
> 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
>
>
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Curtis Faith | 2002-10-05 06:11:53 | Proposed LogWriter Scheme, WAS: Potential Large Performance Gain in WAL synching |
Previous Message | Bruce Momjian | 2002-10-05 04:17:00 | Re: Potential Large Performance Gain in WAL synching |