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 probab
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 libra
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 probab
"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
>> try
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
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 t
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 @
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
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.
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 '[' is a config set name for
> > the lines that follow. So we might have:
> >
> > [asynch_commit]
> >
"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 re
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 '[' is a config set name for
> the lines that follow. So we might have:
>
> [asynch_commit]
> synchronous_commit = off
>
>
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 . The
client would connect to the server if it could
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
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 . The
> client would connect to the server if it could and get the set
"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 synchrono
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 s
So I was testing my fix for the problem noted here:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00196.php
and promptly found *another* bug. To wit, that repair_frag calls
HeapTupleSatisfiesVacuum without bothering to acquire any buffer
content lock. This results in an Assert failure i
18 matches
Mail list logo
