On Fri, Nov 2, 2012 at 1:46 PM, Daniel Farina <daniel@heroku.com> wrote:
> On Fri, Nov 2, 2012 at 1:06 PM, Jeff Janes <jeff.janes@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
