Re: Testing the async-commit patch
От
Tom Lane
Тема
Re: Testing the async-commit patch
Дата
Msg-id
3409.1187107792@sss.pgh.pa.us
Ответ на
Re: Testing the async-commit patch (Gregory Stark)
Список
Дерево обсуждения
Testing the async-commit patch Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing the async-commit patch Andrew Dunstan <andrew@dunslane.net>
Re: Testing the async-commit patch Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing the async-commit patch Andrew Dunstan <andrew@dunslane.net>
Re: Testing the async-commit patch "Simon Riggs" <simon@2ndquadrant.com>
Re: Testing the async-commit patch Alvaro Herrera <alvherre@commandprompt.com>
Re: Testing the async-commit patch Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing the async-commit patch Andrew Dunstan <andrew@dunslane.net>
Re: Testing the async-commit patch Greg Smith <gsmith@gregsmith.com>
Re: Testing the async-commit patch Josh Berkus <josh@agliodbs.com>
Re: Testing the async-commit patch Gregory Stark <stark@enterprisedb.com>
Re: Testing the async-commit patch Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing the async-commit patch "Simon Riggs" <simon@2ndquadrant.com>
Re: Testing the async-commit patch Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing the async-commit patch "Simon Riggs" <simon@2ndquadrant.com>
Re: Testing the async-commit patch "Simon Riggs" <simon@2ndquadrant.com>
Re: Testing the async-commit patch Gregory Stark <stark@enterprisedb.com>
Re: Testing the async-commit patch Tom Lane <tgl@sss.pgh.pa.us>
Gregory Stark 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
В списке pgsql-hackers по дате отправления