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