Re: ERROR after writing PREPARE WAL record

Поиск
Список
Период
Сортировка
От Asim R P
Тема Re: ERROR after writing PREPARE WAL record
Дата
Msg-id CANXE4Tc2XnBWHn_3ndFoDGSr3yYMBcEE-EKfgBbV9JE5qS7Tgw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ERROR after writing PREPARE WAL record  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Jul 17, 2019 at 7:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Asim R P <apraveen@pivotal.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: [proposal] de-TOAST'ing using a iterator
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Add client connection check during the execution of the query