transaction_timestamp()

transaction_timestamp()

am 25.05.2010 06:25:44 von Samuel Stearns

--_000_68B59BEDCD36854AADBDF17E91B2937A01A57CCCB9EXCHMAILsta ff_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Howdy,

I have an archiving script running in an 8.3 environment using transaction_=
timestamp() for the INSERT and DELETE operations. I want to run the same t=
hing in an 8.1 environment but transaction_timestamp() does not exist in 8.=
1. now() will not work because of the time that elapses between the INSERT=
and DELETE operations (I will end up losing some data). Does anyone have =
any suggestions, please?

Thanks,

Sam


--_000_68B59BEDCD36854AADBDF17E91B2937A01A57CCCB9EXCHMAILsta ff_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40">












0.0pt;
font-family:Arial'>Howdy,



0.0pt;
font-family:Arial'> 



0.0pt;
font-family:Arial'>I have an archiving script running in an 8.3 environment
using transaction_timestamp() for the INSERT and DELETE operations.  I
want to run the same thing in an 8.1 environment but transaction_timestamp(=
)
does not exist in 8.1.  now() will not work because of the time that
elapses between the INSERT and DELETE operations (I will end up losing some
data).  Does anyone have any suggestions, please? ont>



0.0pt;
font-family:Arial'> 



0.0pt;
font-family:Arial'>Thanks,



0.0pt;
font-family:Arial'> 



0.0pt;
font-family:Arial'>Sam



0.0pt;
font-family:Arial'> 









--_000_68B59BEDCD36854AADBDF17E91B2937A01A57CCCB9EXCHMAILsta ff_--

Re: transaction_timestamp()

am 25.05.2010 06:31:42 von Tom Lane

Samuel Stearns writes:
> I have an archiving script running in an 8.3 environment using transaction_timestamp() for the INSERT and DELETE operations. I want to run the same thing in an 8.1 environment but transaction_timestamp() does not exist in 8.1. now() will not work because of the time that elapses between the INSERT and DELETE operations (I will end up losing some data). Does anyone have any suggestions, please?

Um ... transaction_timestamp() is exactly the same thing as now().

Perhaps you need to go re-read
http://www.postgresql.org/docs/8.3/static/functions-datetime .html#FUNCTIONS-DATETIME-CURRENT

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: transaction_timestamp()

am 25.05.2010 07:15:05 von Samuel Stearns

Thanks, Tom.

I read it again. I got into trouble using now() before. Transaction_times=
tamp() is really what I need, I think.

I have a table that is updated multiple times/second.

My archiving command operation:

BEGIN;
INSERT INTO blah_archive (id, user) SELECT id, user FROM blah where date < =
(now() - '30 days'::interval);
DELETE FROM blah where date < (now() - '30 days'::interval);
END;

The now() on the INSERT will be a different time than the now() on the DELE=
TE resulting in more rows deleted than were inserted.

Whereas transaction_timestamp() takes care of the problem because both INSE=
RT and DELETE operations work off of the one timestamp that the transaction=
started.

Sam


-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Sent: Tuesday, 25 May 2010 2:02 PM
To: Samuel Stearns
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] transaction_timestamp()=20

Samuel Stearns writes:
> I have an archiving script running in an 8.3 environment using transactio=
n_timestamp() for the INSERT and DELETE operations. I want to run the same=
thing in an 8.1 environment but transaction_timestamp() does not exist in =
8.1. now() will not work because of the time that elapses between the INSE=
RT and DELETE operations (I will end up losing some data). Does anyone hav=
e any suggestions, please?

Um ... transaction_timestamp() is exactly the same thing as now().

Perhaps you need to go re-read
http://www.postgresql.org/docs/8.3/static/functions-datetime .html#FUNCTIONS=
-DATETIME-CURRENT

regards, tom lane

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: transaction_timestamp()

am 25.05.2010 19:42:33 von Kevin Grittner

Samuel Stearns wrote:
> Tom Lane wrote:

>> transaction_timestamp() is exactly the same thing as now().

> I got into trouble using now() before.

Using what? What kind of trouble?

> Transaction_timestamp() is really what I need, I think.

test=# \x
Expanded display is on.
test=# begin;
BEGIN
test=# select now(), current_timestamp, transaction_timestamp();
-[ RECORD 1 ]---------+------------------------------
now | 2010-05-25 12:41:34.365224-05
now | 2010-05-25 12:41:34.365224-05
transaction_timestamp | 2010-05-25 12:41:34.365224-05

[wait ten seconds or so...]

test=# select now(), current_timestamp, transaction_timestamp();
-[ RECORD 1 ]---------+------------------------------
now | 2010-05-25 12:41:34.365224-05
now | 2010-05-25 12:41:34.365224-05
transaction_timestamp | 2010-05-25 12:41:34.365224-05

test=# commit;
COMMIT
test=# select now(), current_timestamp, transaction_timestamp();
-[ RECORD 1 ]---------+------------------------------
now | 2010-05-25 12:41:50.765224-05
now | 2010-05-25 12:41:50.765224-05
transaction_timestamp | 2010-05-25 12:41:50.765224-05

> BEGIN;
> INSERT INTO blah_archive (id, user) SELECT id, user FROM blah
> where date < (now() - '30 days'::interval);
> DELETE FROM blah where date < (now() - '30 days'::interval);
> END;
>
> The now() on the INSERT will be a different time than the now() on
> the DELETE

What makes you think that?

-Kevin

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: transaction_timestamp()

am 26.05.2010 01:09:41 von Samuel Stearns

Hi Tom and Kevin,

I stand corrected. It was awhile ago that I last played around with this. =
I must have had the DELETE operation outside the transaction block back th=
en possibly.

Thanks for setting me straight. Sorry about the waste of time.

Sam

-----Original Message-----
From: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov]=20
Sent: Wednesday, 26 May 2010 3:13 AM
To: Samuel Stearns
Cc: pgsql-admin@postgresql.org; Tom Lane
Subject: Re: [ADMIN] transaction_timestamp()

Samuel Stearns wrote:
> Tom Lane wrote:
=20
>> transaction_timestamp() is exactly the same thing as now().
=20
> I got into trouble using now() before.
=20
Using what? What kind of trouble?
=20
> Transaction_timestamp() is really what I need, I think.
=20
test=3D# \x
Expanded display is on.
test=3D# begin;
BEGIN
test=3D# select now(), current_timestamp, transaction_timestamp();
-[ RECORD 1 ]---------+------------------------------
now | 2010-05-25 12:41:34.365224-05
now | 2010-05-25 12:41:34.365224-05
transaction_timestamp | 2010-05-25 12:41:34.365224-05
=20
[wait ten seconds or so...]
=20
test=3D# select now(), current_timestamp, transaction_timestamp();
-[ RECORD 1 ]---------+------------------------------
now | 2010-05-25 12:41:34.365224-05
now | 2010-05-25 12:41:34.365224-05
transaction_timestamp | 2010-05-25 12:41:34.365224-05
=20
test=3D# commit;
COMMIT
test=3D# select now(), current_timestamp, transaction_timestamp();
-[ RECORD 1 ]---------+------------------------------
now | 2010-05-25 12:41:50.765224-05
now | 2010-05-25 12:41:50.765224-05
transaction_timestamp | 2010-05-25 12:41:50.765224-05
=20
> BEGIN;
> INSERT INTO blah_archive (id, user) SELECT id, user FROM blah
> where date < (now() - '30 days'::interval);
> DELETE FROM blah where date < (now() - '30 days'::interval);
> END;
>=20
> The now() on the INSERT will be a different time than the now() on
> the DELETE
=20
What makes you think that?
=20
-Kevin

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: transaction_timestamp()

am 26.05.2010 17:40:59 von Kevin Grittner

Samuel Stearns wrote:

> Sorry about the waste of time.

It happens. One tip which might be useful with future issues is to
try to put together a simple case demonstrating the issue (similar
to what I posted on this thread). Sometimes the process of
preparing that will make the answer obvious; when it doesn't,
posting it will make it much easier for people to give useful
advice.

I'm glad you've got a solution that works for you now.

-Kevin

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin