On Tue, 2007-08-14 at 12:29 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2007-08-14 at 12:09 -0400, Tom Lane wrote:
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
On Mon, 2007-08-13 at 16:27 -0400, Andrew Dunstan wrote:
Let's say that this file looks just like a postgresql.conf file, except
that any line beginning with '[identifier]' is a config set name for
the lines that follow. So we might have:
[asynch_commit]
synchronous_commit = off
Tom Lane [EMAIL PROTECTED] writes:
But to get to the point: the urgency of testing the patch more
extensively has just moved up a full order of magnitude,
The problem testing this patch is that the window for a committed transaction
to not be synced is quite narrow, especially for the
Simon Riggs wrote:
On Mon, 2007-08-13 at 16:27 -0400, Andrew Dunstan wrote:
Let's say that this file looks just like a postgresql.conf file, except
that any line beginning with '[identifier]' is a config set name for
the lines that follow. So we might have:
[asynch_commit]
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Sounds fine, though I'd prefer this in XML to allow further
extensibility in the future.
YAML?
That would seem to require making pg_regress depend on some XML library
or other, which is a dependency I'd rather not add.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Sounds fine, though I'd prefer this in XML to allow further
extensibility in the future.
YAML?
That would seem to require making pg_regress depend on some XML library
or other, which is a
Tom,
We're getting some additional test infrastructre at Sun; I'll throw this on
the pile of stuff to test.
However, the current tests we're doing are regression tests and benchmark
runs. If there's some other kind of testing we need to do, I'll need
specifics.
--
Josh Berkus
PostgreSQL @
Gregory Stark [EMAIL PROTECTED] 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
On Tue, 2007-08-14 at 12:09 -0400, Tom Lane wrote:
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
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2007-08-14 at 12:09 -0400, Tom Lane wrote:
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
On Mon, 2007-08-13 at 16:27 -0400, Andrew Dunstan wrote:
[asynch_commit]
synchronous_commit = off
[no_fsync]
fsync = off
This is the Windows INI file format. As such, it's easy to find code
samples in almost any language that parse this format for you. For
example, Python has a core
Tom Lane wrote:
But to get to the point: the urgency of testing the patch more
extensively has just moved up a full order of magnitude, IMHO anyway.
I muttered something in the other thread about providing a buildfarm
option to run the regression tests with synchronous_commit off. That
would
Tom Lane [EMAIL PROTECTED] writes:
But to get to the point: the urgency of testing the patch more
extensively has just moved up a full order of magnitude, IMHO anyway.
I muttered something in the other thread about providing a buildfarm
option to run the regression tests with
Andrew Dunstan [EMAIL PROTECTED] writes:
I have some ideas about testing configuration items. Doing all our tests
with the default config is not ideal, I think. Essentially we'd put up a
server that would have sets of branch, list-of-config-lines. The
client would connect to the server if
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I propose that we actually set synchronous_commit
off by default for the next little while --- at least up to 8.3beta1,
maybe until we approach the RC point. That will ensure that every
buildfarm machine is exercising
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have some ideas about testing configuration items. Doing all our tests
with the default config is not ideal, I think. Essentially we'd put up a
server that would have sets of branch, list-of-config-lines. The
client would connect
16 matches
Mail list logo
