Re: timeout implementation issues

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

In response to

Responses

Browse pgsql-hackers by date

  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 ?