From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Michael Loftis <mloftis(at)wgops(dot)com> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: timeout implementation issues |
Date: | 2002-04-09 18:07:14 |
Message-ID: | Pine.LNX.4.30.0204091401330.685-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-04-09 18:13:19 | Re: unknownin/out patch (was [HACKERS] PQescapeBytea is |
Previous Message | Mikhail Terekhov | 2002-04-09 17:09:29 | Re: notification: pg_notify ? |