Horton
Menu

Re: conchuela timeouts since 2021-10-09 system upgrade

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Michael Paquier <michael@paquier.xyz>, Peter Geoghegan <pg@bowt.ie>, Andres Freund <andres@anarazel.de>
Date: 2021-10-26T01:51:57Z
Lists: pgsql-bugs 
On Mon, Oct 25, 2021 at 04:59:42PM -0400, Tom Lane wrote:
> Andrey Borodin <x4mmm@yandex-team.ru> writes:
> > FWIW it's easy to make the issue reproduce faster with following diff
> > -       '--no-vacuum --client=1 --transactions=100',
> > +       '--no-vacuum --client=1 --transactions=1',
> 
> Hmm, didn't help here.  It seems that even though prairiedog managed to
> fail on its first attempt, it's not terribly reproducible there; I've
> seen only one failure in about 30 manual attempts.  In the one failure,
> the non-background pgbench completed fine (as determined by counting
> statements in the postmaster's log); but the background one had only
> finished about 90 transactions before seemingly getting stuck.  No new
> SQL commands had been issued after about 10 seconds.

Interesting.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2021-10-24%2016%3A05%3A58
also shows a short command count, just 131/200 completed.  However,
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2021-10-25%2000%3A35%3A27
shows the full 200/200.  I'm starting to think the prairiedog failures have
only superficial similarity to the conchuela failures.

> Nonetheless, I have a theory and a proposal.  This coding pattern
> seems pretty silly:
> 
> 	$pgbench_h->pump_nb;
> 	$pgbench_h->finish();
> 
> ISTM that if you need to call pump at all, you need a loop not just
> one call.  So I'm guessing that when it fails, it's for lack of
> pumping.

The pump_nb() is just unnecessary.  We've not added anything destined for
stdin, and finish() takes care of pumping outputs.

> The other thing I noticed is that at least on prairiedog's host, the
> number of invocations of the DROP/CREATE/bt_index_check transaction
> is ridiculously out of proportion to the number of invocations of the
> other transactions.  It can only get through seven or eight iterations
> of the index transaction before the other transactions are all done,
> which means the last 190 iterations of that transaction are a complete
> waste of cycles.

That makes sense.

> What I think we should do in these two tests is nuke the use of
> background_pgbench entirely; that looks like a solution in search
> of a problem, and it seems unnecessary here.  Why not run
> the DROP/CREATE/bt_index_check transaction as one of three script
> options in the main pgbench run?

The author tried that and got deadlocks:
https://postgr.es/m/5E041A70-4946-489C-9B6D-764DF627A92D@yandex-team.ru


On prairiedog, the proximate trouble is pgbench getting stuck.  IPC::Run is
behaving normally given a stuck pgbench.  When pgbench stops sending queries,
does pg_stat_activity show anything at all running?  If so, are those backends
waiting on locks?  If not, what's the pgbench stack trace at that time?

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve contrib/amcheck's tests for CREATE INDEX CONCURRENTLY.

  2. Fix minor memory leaks in pg_dump.

  3. Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.

  4. Fix CREATE INDEX CONCURRENTLY for the newest prepared transactions.

  5. Add -w back to the flags for pg_ctl (re)start in PostgresNode

  6. Fix CREATE INDEX CONCURRENTLY for simultaneous prepared transactions.