Re: Freezing localtimestamp and other time function on some value

From: Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru>
To: George Neuner <gneuner2(at)comcast(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Freezing localtimestamp and other time function on some value
Date: 2016-04-12 14:36:57
Message-ID: 570D0809.8040107@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 12.04.2016 16:57, George Neuner wrote:
> On Tue, 12 Apr 2016 13:50:11 +0300, Alex Ignatov
> <a(dot)ignatov(at)postgrespro(dot)ru> wrote:
>
>> Is there any method to freeze localtimestamp and other time function value.
>> Say after freezing on some value sequential calls to these functions
>> give you the same value over and over again.
>> This is useful primarily for testing.
>>
>> In oracle there is alter system set fixed_date command. Have Postgres
>> this functionality?
> I'm missing how this is useful. Even having such a feature there is
> not any way to duplicate a test trace: execution time of a request is
> not guaranteed even if it's issue time is repeatable wrt some epoch.
> And if there are concurrent requests, their completion order is not
> guaranteed.
>
> It is also true in Oracle, and in every general purpose DBMS that I
> know of. So what exactly do you "test" using a fixed date/time?
>
> George
>
>
>

This is useful if your application written say on stored function on PG
and it works differently on working days and on vacations or weekends.
How can you test your application without this ability? Changing system
time and affect all application on server or write your own
localtimestamp implementation keep in mind of test functionality?
Also yesterday we have issue while comparing Pg function output
converted from Oracle and its Oracle equivalent on the same data. You
now what - we cant do it, because function depends on
localtimestamp(Pg) and sysdate (Ora) =/

--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2016-04-12 14:46:20 Re: Fastest way to duplicate a quite large database
Previous Message Edson Richter 2016-04-12 14:25:04 Fastest way to duplicate a quite large database