On Jun 23, 2010, at 5:36 PM, Mark Wong wrote: > On Jun 22, 2010, at 1:34 AM, Simon Riggs wrote: > >> On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote: >>> On Mon, Jun 21, 2010 at 7:51 PM, gabrielle <gor...@gmail.com> wrote: >>>> On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked: >>>>> How does it play with ON_ERROR_STOP/ROLLBACK? >>>> >>>> With ON_ERROR_STOP=ON, psql issues an error when it encounters one, >>>> stops processing the file that contains the error, and then continues >>>> to process any remaining files. >> >> That would be undesirable. >> >>>> I'm still investigating ON_ERROR_ROLLBACK. I need to tinker with it >>>> some more before I say anything concrete. >>>> >>>> On Fri, Jun 18, 2010 at 1:48 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>>>> Also, how does it play with --single-transaction. >>>> That was buried in our original report :) "BEGIN-COMMIT statements >>>> within the files cause warnings when the command is wrapped in a >>>> transaction with the -1 switch (as specified in the patch submission)" >>>> >>>> To expand upon that a bit: when psql encounters a file that contains >>>> a BEGIN statement, you get the expected "WARNING: there is already a >>>> transaction in progress" message. The COMMIT at the end of that file >>>> (assuming the user doesn't forget it) generates a COMMIT. Commands >>>> after that commit, or in any remaining files to be processed, are >>>> dealt with according to the user's autocommit settings: >>>> - if autocommit is ON, statements in the remaining files are processed >>>> & committed; the implicit COMMIT at the end of the whole thing then >>>> generates a "WARNING: there is no transaction in progress" message >>>> - if autocommit is OFF, statements in the remaining files generate >>>> "ERROR: current transaction is aborted, commands ignored until end of >>>> transaction block" messages. >> >> This is the existing behaviour. >> >>> So none of the above sounds like desired behavior to me... is that just me? >> >> Single transaction needs some help, but that's not the fault of this >> patch. > > I took a closer look at what was going on and what it would take to meet some > of these expectations. In main() the patch adds BEGIN and COMMIT statements > outside the call to process_file() in src/bin/psql/command.c. Here lies the > previous logic for handling single transaction. Since it remains, it appears > that BEGIN can be issued twice before any statements are executed if the > single transaction switch is used. Plus there are other a couple of places > that call this particular process_file() function, but I think those are > straightforward cases to deal with.
Heh, not close enough. I was wrong about that scenario. I can see now that the single transaction flag is always set to false in process_file(). I think that turns the single transaction handling in process_file() into dead code with the patch like this. Regards, Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
