Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Date
Msg-id 3074140.1775074810@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE  (Alexander Lakhin <exclusion@gmail.com>)
Responses RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
List pgsql-hackers
Alexander Lakhin <exclusion@gmail.com> writes:
> I think this can explain slow CommitTransactionCommand() and why it
> happens not every time. Regarding other animals, I guess they can
> experience the same bumps but not exceeding 5 seconds (50 tries). Thus,
> from my understanding, for the failure to happen, we need to have slow
> storage and initialize_worker_spi() -> CommitTransactionCommand() reaching
> XLogFileClose().

So, it remains not very clear why only widowbird is showing this
failure, but I think we can safely take away the bottom-line
conclusion that hard-wiring a maximum wait of 5s in
CountOtherDBBackends() was not a great idea.

I don't think I want to propose a GUC for this, but could it make
sense to check for an environment variable, similarly to PGCTLTIMEOUT
and PG_TEST_TIMEOUT_DEFAULT?  Whichever way we do it, it could replace
the existing crude hack to change the max wait in injection-point
mode.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
Next
From: Zsolt Parragi
Date:
Subject: Re: [oauth] Split and extend PGOAUTHDEBUG