Re: timeout implementation issues - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: timeout implementation issues
Date
Msg-id Pine.LNX.4.30.0204091401330.685-100000@peter.localdomain
Whole thread Raw
In response to Re: timeout implementation issues  (Michael Loftis <mloftis@wgops.com>)
Responses Re: timeout implementation issues  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: timeout implementation issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Michael Loftis writes:

> I was under the impression that for a transaction either all commands
> succeed or all commands fail, atleast according to everything I've ever
> read.

That's an urban legend.

A transaction guarantees (among other things) that all modifications to
the database with the transaction are done atomicly (either all or done or
none).  This does not extend to the commands that supposedly initiate such
modifications.

Take out a database other than PostgreSQL and do

BEGIN; -- or whatever they use; might be implicit
INSERT INTO existing_table ('legal value');
barf;
COMMIT;

The INSERT will most likely succeed.  The reason is that "barf" does not
modify or access the data in the database, so it does not affect the
transactional integrity of the database.

We are trying to make the same argument for SET.  SET does not modify the
database, so it doesn't have to fall under transaction control.

-- 
Peter Eisentraut   peter_e@gmx.net



pgsql-hackers by date:

Previous
From: Mikhail Terekhov
Date:
Subject: Re: notification: pg_notify ?
Next
From: Bruce Momjian
Date:
Subject: Re: Strange problem when upgrading to 7.2 with pg_upgrade.