On Fri, Nov 2, 2012 at 1:46 PM, Daniel Farina <dan...@heroku.com> wrote: > On Fri, Nov 2, 2012 at 1:06 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: >>> I see why it is implemented this way, but it's also still pretty >>> unsatisfying because it means that with cancellation requests clients >>> are in theory able to commit an unlimited number of transactions, >>> synchronous commit or no. >> >> What evil does this allow the client to perpetrate? > > The client can commit against my will by accident in an automated > system whose behavior is at least moderately complex and hard to > understand completely for all involved, and then the client's author > subsequently writes me a desperate or angry support request asking why > data was lost.
If people don't know when or if they are committing, then I would think you will get such issues no matter what! > This is not the best time for me to ask "did you setup > a scheduled task to cancel hanging queries automatically? Because > yeah...there's this...thing." OK, I see your point here. If an outside task cancels the commit, the process that issued the commit does get a success response with seemingly no indication that something may be amiss. In DBD::Pg under PrintError=>1, you do get the WARNING and DETAIL message on stderr, but seemingly no sane way for the program to intercept that warning. But I don't see any alternative, other than refusing to deliver any response at all to the client. The commit neither unambiguously failed, nor unambiguously succeeded. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers