On Fri, Nov 2, 2012 at 1:46 PM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> On Fri, Nov 2, 2012 at 1:06 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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.
In response to
pgsql-hackers by date
|Next:||From: David Fetter||Date: 2012-11-04 00:44:50|
|Previous:||From: Alexander Korotkov||Date: 2012-11-03 21:53:19|
|Subject: Re: Incorrect behaviour when using a GiST index on points|