Skip site navigation (1) Skip section navigation (2)

Re: Synchronous commit not... synchronous?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Peter van Hardenberg <pvh(at)pvh(dot)ca>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synchronous commit not... synchronous?
Date: 2012-11-03 22:26:18
Message-ID: CAMkU=1x6LaUG0S9d1Ut3c1MvJBxkLWE31mN52dm8kZSkpuCd3A@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Cheers,

Jeff


In response to

pgsql-hackers by date

Next:From: David FetterDate: 2012-11-04 00:44:50
Subject: MDCC
Previous:From: Alexander KorotkovDate: 2012-11-03 21:53:19
Subject: Re: Incorrect behaviour when using a GiST index on points

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group