Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I assume write() is not our checkpoint performance problem, but the
> transfer to disk via fsync(). Perhaps a simple solution is to do the
> write()'s of all dirty buffers as we do now at checkpoint time, but
> delay 30 seconds and then do fsync() on al
Hi all,
I'm new to the forums, so bear with me on my questions. I've set up an
auto-archive and auto-recover pair of databases using pg_standby, which
I'm prototyping various products for high availability. I've noticed
that when I attempt to fail from the primary archiver to the secondary
recovery
I looked into the bug reported by Jean-Pierre Pelletier here:
http://archives.postgresql.org/pgsql-bugs/2006-12/msg00163.php
The cause of the crash is a reference to an already-deallocated
TupleDesc. The problem query has the structure of
SELECT sum(x) FROM (complicated-subselect) GROUP B
win32.h says
/*
* Signal stuff
* WIN32 doesn't have wait(), so the return value for children
* is simply the return value specified by the child, without
* any additional information on whether the child terminated
* on its own or via a signal. These macros are also
Several of the buildfarm machines are exhibiting repeatable signal 11
crashes in what seem perfectly ordinary queries. This started about
four days ago so I suppose it's got something to do with my
operator-families patch :-( ... but I dunno what, and none of my own
machines show the failure. Can
http://www.postgresql.org/docs/8.2/interactive/ddl-system-columns.html
has the following statement about ctid:
"The physical location of the row version within its table. Note that
although the ctid can be used to locate the row version very quickly, a
row's ctid will change each time it is update
On Tue, Dec 26, 2006 at 12:04:40PM -0500, D'Arcy J.M. Cain wrote:
> I have been testing this statement and find that it seems not quite
> true. Although ctid changes on update, VACUUM FULL does not change it.
> What it does do is make lower areas available again so an update after a
> VACUUM FULL c
On Tue, Dec 26, 2006 at 06:12:45PM +0100, Martijn van Oosterhout wrote:
> On Tue, Dec 26, 2006 at 12:04:40PM -0500, D'Arcy J.M. Cain wrote:
> > Now it certainly seems to me that it should behave as described given
> > the definition of VACUUM FULL so I am a little confused by my tests.
> > My test
On Tue, 26 Dec 2006 18:12:45 +0100
Martijn van Oosterhout wrote:
> On Tue, Dec 26, 2006 at 12:04:40PM -0500, D'Arcy J.M. Cain wrote:
> > Now it certainly seems to me that it should behave as described given
> > the definition of VACUUM FULL so I am a little confused by my tests.
> > My test table
On Tue, Dec 26, 2006 at 12:49:55PM -0500, D'Arcy J.M. Cain wrote:
> On Tue, 26 Dec 2006 18:12:45 +0100
> Martijn van Oosterhout wrote:
> > On Tue, Dec 26, 2006 at 12:04:40PM -0500, D'Arcy J.M. Cain wrote:
> > > Now it certainly seems to me that it should behave as described given
> > > the definit
Tom Lane wrote:
> win32.h says
>
> /*
> *Signal stuff
> *WIN32 doesn't have wait(), so the return value for children
> *is simply the return value specified by the child, without
> *any additional information on whether the child terminated
> *on its own or via a signal. T
I've been skimming through the bitmap index patch...
A scan needs to access at least five pages:
1. B-tree index (root+others, depending on depth)
2. The auxiliary heap page
3. bitmap index meta page
4. LOV page
5. bitmap page
That seems like a lot of indirection. A high startup cost is probabl
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Anyone want to run down what we should really
>> be using instead of the above macros?
> The exit code is apparently what is reported from GetExitCodeProcess().
> For info on that see
> http://msdn.microsoft.com/library/default.asp?
Tom Lane wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Anyone want to run down what we should really
>>> be using instead of the above macros?
>
>> The exit code is apparently what is reported from GetExitCodeProcess().
>> For info on that see
>> http://msdn.microsoft
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Does the mentioned OID actually correspond to the OID of the table it's
>> supposed to be opening, or is it wrong? Is anything being done to
>> the table schema in parallel?
> Yes, it is the correct OID. No, nothing done to th
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> On Tue, 2006-12-26 at 13:59 -0800, Glen Parker wrote:
>> I'd love to see this back patched into 8.2.1 if possible.
> Probably not. We typically do not introduce new features into back
> releases.
And since this one would require an initdb, there is
On Tue, 2006-12-19 at 22:06 -0800, Steve Atkins wrote:
> On Dec 19, 2006, at 9:50 PM, Jonah H. Harris wrote:
>
> > On 12/19/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> I think we should just accept the strings case-insensitively, too.
> >
> > While acknowledging Peter's pedantically-correct point
Couldnt find a replication system that worked and did what I wanted, so I made
one.
If you would like to give my humble creation a try...
http://spar.orgfree.com/index.html
Its working for me oh yes... its free... naturally :)
Regards
Johnny
Couldnt find a replication system that worked and did what I wanted, so I made
one.
If you would like to give my humble creation a try...
http://spar.orgfree.com/index.html
Regards
Johnny
Tom Lane <[EMAIL PROTECTED]> wrote:
> server process exited with exit code -1073741819
> from what I suspect is really the equivalent of a SIGSEGV trap,
> ie, attempted access to already-deallocated memory. My calculator
> says the above is equivalent to hex C005, and I say that this
>
Hey Heikki,
On Tue, 26 Dec 2006, Heikki Linnakangas wrote:
> I've been skimming through the bitmap index patch...
>
> A scan needs to access at least five pages:
>
> 1. B-tree index (root+others, depending on depth)
> 2. The auxiliary heap page
> 3. bitmap index meta page
> 4. LOV page
> 5. bitma
ITAGAKI Takahiro wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > I assume write() is not our checkpoint performance problem, but the
> > transfer to disk via fsync(). Perhaps a simple solution is to do the
> > write()'s of all dirty buffers as we do now at checkpoint time, but
> > dela
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> On 12/19/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> I think we should just accept the strings case-insensitively, too.
> Where we at on this?
Anyone against making it case-insensitive, speak now or hold your peace.
regards,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> I'm not really convinced that Bruce's proposed names seem any better to
>> me. What's wrong with "dead" and "live"?
> In my mind, visible really means "visible to anyone", and expired means
> visible to no one.
Um ... surely, v
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> I'm not really convinced that Bruce's proposed names seem any better to
> >> me. What's wrong with "dead" and "live"?
>
> > In my mind, visible really means "visible to anyone", and expired means
> > visibl
On Tuesday 26 December 2006 23:12, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Alvaro Herrera wrote:
> > >> I'm not really convinced that Bruce's proposed names seem any better
> > >> to me. What's wrong with "dead" and "live"?
> > >
> > > In my mind,
> The current terminology of live and dead is already used in many places in
> the
> documentation and in userspace; mostly around the need for maintainance of
> dead tuples within tables, reindex cleaning up dead pages, and even in the
> vacuum commands output (n dead tuples cannot be removed
27 matches
Mail list logo
