> 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
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,
"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,
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
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
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
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
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
>
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
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
"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
"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
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
"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?
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
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
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
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 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, 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
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
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
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
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
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
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
27 matches
Mail list logo
