Re: timeout implementation issues

Peter Eisentraut wrote:
> 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.

Ewe, we do fail that test.

> 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.

OK, we have three possibilities:
o  All SETs are honored in an aborted transactiono  No SETs are honored in an aborted transactiono  Some SETs are
honoredin an aborted transaction (current)
 

I think the problem is our current behavior.  I don't think anyone can
say our it is correct (only honor SET before the transaction reaches
abort state).  Whether we want the first or second is the issue, I think.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026