From: | Asim R P <apraveen(at)pivotal(dot)io> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ERROR after writing PREPARE WAL record |
Date: | 2019-07-18 04:08:13 |
Message-ID: | CANXE4Tc2XnBWHn_3ndFoDGSr3yYMBcEE-EKfgBbV9JE5qS7Tgw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 17, 2019 at 7:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Asim R P <apraveen(at)pivotal(dot)io> writes:
> > Cancel/terminate requests are held off during "PREPARE TRANSACTION"
> > processing in function PrepareTransaction(). However, a subroutine
invoked
> > by PrepareTransaction() may perform elog(ERROR) or elog(FATAL).
>
> The correct response, if you notice code doing that, is to fix it so
> it doesn't do that. Typically the right answer is to move the
> failure-prone operation to pre-commit processing.
Thank you for the response. There is nothing particularly alarming. There
is one case in LWLockAcquire that may error out if (num_held_lwlocks >=
MAX_SIMUL_LWLOCKS). This problem also exists in CommitTransaction() and
AbortTransaction() code paths. Then there is arbitrary add-on code
registered as Xact_callbacks.
SyncRepWaitForLSN() directly checks ProcDiePending and QueryCancelPending
without going through CHECK_FOR_INTERRUPTS and that is for good reason.
Moreover, it only emits a WARNING, so no problem there.
Asim
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-07-18 04:28:14 | Re: Add client connection check during the execution of the query |
Previous Message | John Naylor | 2019-07-18 03:39:48 | Re: [proposal] de-TOAST'ing using a iterator |