subtransaction cancellation in HS

From: Andres Freund <andres(at)anarazel(dot)de>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: subtransaction cancellation in HS
Date: 2010-02-14 23:09:23
Message-ID: 201002150009.24815.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Simon, Hi all,

I am not sure this is 9.0 material - even if I would like it to get
included... If HS wouldnt be new I wouldnt even consider suggesting it, but as
its stands its a pretty small change...

It simply allows queries involving subtransaction not to get FATALed but
canceled. This works by doing the recursive abort you erlier did in
ProcessInterrupts in the PostgresMain where there cannot be any references
higher up in the chain.

It would likely be sensible to check that errorcode in some PLs. I have code
for that but I dont think its sensible to continue on those before the
approach is agreed uppon.

I would like to get the part about a seperate error code for HS cancellations
to get commited independently. Its kinda sensible for a client to accept
specifically about such a cancellation and requiring them to play around with
the message...
Currently its called ERRCODE_QUERY_CANCELED_HS but perhaps
ERRCODE_QUERY_CANCELED_STANDBY_CONFLICT or such would be better. I dont really
know how errorcodes gets assigned, so I picked one which is likely wrong...

Additionally there is a very small cleanup removing the errno saving from
RecoveryConflictInterrupt - its somewhat incomplete (I think harmlessly
though) and more importantly the only caller in procsignal.c already does
that...

Andres

Attachment Content-Type Size
0001-Dont-try-to-save-the-errno-in-RecoveryConflictInterr.patch text/x-patch 1.5 KB
0001-Add-a-new-error-code-ERRCODE_QUERY_CANCELED_HS-for-u.patch text/x-patch 2.4 KB
0002-Allow-HS-conflict-cancellations-to-abort-subtransact.patch text/x-patch 6.1 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-02-14 23:33:54 Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Previous Message Simon Riggs 2010-02-14 22:44:42 Re: Listen / Notify - what to do when the queue is full