Re: Testing the async-commit patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Testing the async-commit patch
Date: 2007-08-14 16:09:52
Message-ID: 3409.1187107792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> The problem testing this patch is that the window for a committed transaction
> to not be synced is quite narrow, especially for the regression tests. For
> testing purposes I wonder if there are ways we can widen this window. Some
> ideas, some wackier than others, are:

> . Raise the default wal_writer_delay to 5s or so -- also temporary until
> release

I ran 100+ cycles of the parallel regression tests with this setting,
and didn't see any failures.

> . Add an ifdef USE_ASSERT_CHECKING which randomly omits setting hint
> bits even when it could.

I think this is better done by code inspection, ie, look for places that
assume HEAP_XMIN/XMAX_COMMITTED is or can be set.

I made a pass over CVS HEAD and found some apparent trouble spots:
heapam.c lines 1843-1852 presume previous xmax can be hinted
immediately, ditto lines 2167-2176, ditto lines 2716-2725.
I think probably we should just remove those lines --- they are only
trying to save work for future tqual.c calls.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-08-14 16:22:52 Re: Testing the async-commit patch
Previous Message Bruce Momjian 2007-08-14 15:51:59 Re: change name of redirect_stderr?