postgres-xc-developers

[Postgres-xc-developers] statement_timestamp

[Mason S. <mas...@en...>]

Michael,

Can you remind me regarding statement_timestamp()? From the commit log:

     This commit supports global timestamp values for now(), 
statement_timestamp,
     transaction_timestamp,current_date, current_time, current_timestamp,
     localtime, local_timestamp and now().

     clock_timestamp and timeofday make their calculation based
     on the local server clock so they get their results from the local 
node where it is run.
     Their use could lead to inconsistencies if used in a transaction 
involving several Datanodes.


For statement_timestamp() do we perform a separate operation through 
GTM, or do we do a delta similar to clock_timestamp()?

Thanks,

Mason

-- 
Mason Sharp
EnterpriseDB Corporation
The Enterprise Postgres Company


This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Re: [Postgres-xc-developers] statement_timestamp

[Michael P. <mic...@gm...>]

>
> Can you remind me regarding statement_timestamp()? From the commit log:
>
>     This commit supports global timestamp values for now(),
> statement_timestamp,
>     transaction_timestamp,current_date, current_time, current_timestamp,
>     localtime, local_timestamp and now().
>
>     clock_timestamp and timeofday make their calculation based
>     on the local server clock so they get their results from the local
> node where it is run.
>     Their use could lead to inconsistencies if used in a transaction
> involving several Datanodes.
>
>
> For statement_timestamp() do we perform a separate operation through
> GTM, or do we do a delta similar to clock_timestamp()?
>
statement_timestamo and transaction timestamp base their calculations based
on delta calculated with GTM.
clock_timestamp does not do anything with GTM, it just uses the local node
timestamp.

-- 
Michael Paquier
http://michaelpq.users.sourceforge.net

Re: [Postgres-xc-developers] statement_timestamp

[Mason S. <mas...@en...>]

>
>     For statement_timestamp() do we perform a separate operation through
>     GTM, or do we do a delta similar to clock_timestamp()?
>
> statement_timestamo and transaction timestamp base their calculations 
> based on delta calculated with GTM.
> clock_timestamp does not do anything with GTM, it just uses the local 
> node timestamp.
>
Transaction_timestamp should just use the value piggybacked from GTM 
with XID and not a delta though. The same value should be used on all 
nodes involved in the transaction, right?

Thanks,

Mason


> -- 
> Michael Paquier
> http://michaelpq.users.sourceforge.net
>


-- 
Mason Sharp
EnterpriseDB Corporation
The Enterprise Postgres Company


This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Re: [Postgres-xc-developers] statement_timestamp

[Michael P. <mic...@gm...>]

Sorry for my late reply.

On Wed, Dec 1, 2010 at 7:34 AM, Mason Sharp <mas...@en...>wrote:

>
>
>> For statement_timestamp() do we perform a separate operation through
>> GTM, or do we do a delta similar to clock_timestamp()?
>>
> statement_timestamo and transaction timestamp base their calculations based
> on delta calculated with GTM.
> clock_timestamp does not do anything with GTM, it just uses the local node
> timestamp.
>
>  Transaction_timestamp should just use the value piggybacked from GTM with
> XID and not a delta though. The same value should be used on all nodes
> involved in the transaction, right?
>

When a transaction is begun on a node, the transaction timestamp is sent
along with snapshot and gxid.
The value sent is of course the one calculated at Coordinator.

You are right that we should send directly the timestamp value got at GTM...
But if you have a look at the code, in xact.c
when a call of statement_timestamp is made, we calculate it based on the
local start timestamp and the delta value:
stmtStartTimestamp + GTMdeltaTimestamp

Delta is itself calculated when received with this:
GTMdeltaTimestamp = GTMxactStartTimestamp - stmtStartTimestamp

So we basically we give the timestamp value received from GTM.

The important point is linked to stmtStartTimestamp.
This variable is constant inside a transaction, but it is changed when
running statements out of a transaction block.

I think it is important to keep algorithm the way it is done now.
OK it complicates a little bit transaction timestamp calculation by using
the delta twice.
But the result is the same, and it permits to take into account both
transaction timestamp and statement timestamp cases when calling
statement_timestamp in xact.c.

-- 
Michael Paquier
http://michaelpq.users.sourceforge.net

Re: [Postgres-xc-developers] statement_timestamp

[Mason S. <mas...@en...>]

On 12/1/10 11:40 PM, Michael Paquier wrote:
> Sorry for my late reply.
>
> On Wed, Dec 1, 2010 at 7:34 AM, Mason Sharp 
> <mas...@en... <mailto:mas...@en...>> 
> wrote:
>
>
>>
>>         For statement_timestamp() do we perform a separate operation
>>         through
>>         GTM, or do we do a delta similar to clock_timestamp()?
>>
>>     statement_timestamo and transaction timestamp base their
>>     calculations based on delta calculated with GTM.
>>     clock_timestamp does not do anything with GTM, it just uses the
>>     local node timestamp.
>>
>     Transaction_timestamp should just use the value piggybacked from
>     GTM with XID and not a delta though. The same value should be used
>     on all nodes involved in the transaction, right?
>
>
> When a transaction is begun on a node, the transaction timestamp is 
> sent along with snapshot and gxid.
> The value sent is of course the one calculated at Coordinator.
>
> You are right that we should send directly the timestamp value got at 
> GTM...
> But if you have a look at the code, in xact.c
> when a call of statement_timestamp is made, we calculate it based on 
> the local start timestamp and the delta value:
> stmtStartTimestamp + GTMdeltaTimestamp
>
> Delta is itself calculated when received with this:
> GTMdeltaTimestamp = GTMxactStartTimestamp - stmtStartTimestamp
>
> So we basically we give the timestamp value received from GTM.
>
> The important point is linked to stmtStartTimestamp.
> This variable is constant inside a transaction, but it is changed when 
> running statements out of a transaction block.
>
> I think it is important to keep algorithm the way it is done now.
> OK it complicates a little bit transaction timestamp calculation by 
> using the delta twice.
> But the result is the same, and it permits to take into account both 
> transaction timestamp and statement timestamp cases when calling 
> statement_timestamp in xact.c.
That seems a bit confusing. I think it would be cleaner to simply use 
the passed over from GTM timestamp for statement_timestamp. Is this same 
double calculation also being used for now()?

Thanks,

Mason

>
> -- 
> Michael Paquier
> http://michaelpq.users.sourceforge.net
>


-- 
Mason Sharp
EnterpriseDB Corporation
The Enterprise Postgres Company


This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.