BUG #4952: commit_delay ignored because CountActiveBackends always returns zero - Mailing list pgsql-bugs

From Jeff Janes
Subject BUG #4952: commit_delay ignored because CountActiveBackends always returns zero
Date
Msg-id 200907290323.n6T3NNCE056740@wwwmaster.postgresql.org
Whole thread Raw
Responses Re: BUG #4952: commit_delay ignored because CountActiveBackends always returns zero  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
The following bug has been logged online:

Bug reference:      4952
Logged by:          Jeff Janes
Email address:      jeff.janes@gmail.com
PostgreSQL version: 8.4.0
Operating system:   Linux 2.4.21-15.0.3.ELsmp
Description:        commit_delay ignored because CountActiveBackends always
returns zero
Details:

I've found that commit_delay never has an effect.

By instrumenting src/backend/access/transam/xact.c, I see that this is
because CountActiveBackends always returns zero.

This seems to be a bug introduced by:
http://archives.postgresql.org/pgsql-committers/2009-03/msg00259.php

into file src/backend/storage/ipc/procarray.c

I believe the source of the bug is the addition to that file of

+         if (proc != NULL)
+             continue;

The sense of this test should be inverted, as it is NULLs, not non-nulls
that need to be skipped.

Due to this test all truly active backends get skipped, so
CountActiveBackends() always returns zero.  Also, I believe without evidence
that the change fails to correct the (hard to reproduce) bug it was
originally introduced to correct, as a proc that is NULL does not get
skipped, and goes on to be dereferenced.

If I change this code to:

+         if (proc == NULL)
+             continue;

Then I find that commit_delay now does have an effect.

(The effect is to make "pgbench -c 15" slower when commit_delay is set to
the max value of 100000.  This is what I thought would happen, and was
surprised when it originally did not.)

thanks,

Jeff

pgsql-bugs by date:

Previous
From: Greg Stark
Date:
Subject: Re: BUG #4949: NOT IN is prohibitive slower than the rewrite for medium to large sets
Next
From: "Dan Boeriu"
Date:
Subject: Re: BUG #4945: Parallel update(s) gone wild