Am Dienstag, 22. März 2005 15:54 schrieb Tom Lane:
> Any chance of going in with a debugger, or capturing a
> tarball image of the database for someone else to look at?
Unfortunately, this database is restricted and I don't have access myself. I
will tell the customer that they should provide a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think it takes a lot of concurrency for
> the situation to arise.
Maybe. Since Peter can reproduce the error, there's not any concurrency
misbehavior involved in VACUUM itself; what we are dealing with is
probably corruption in the on-disk state of t
On Tue, Mar 22, 2005 at 12:31:55PM +0100, Peter Eisentraut wrote:
> What does the error message
>
> failed to re-find parent key in "tablename_pkey"
>
> mean? This happens reproducibly during VACUUM on a certain table.
This has been reported before, but no one has been able to reproduce it
(not
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> What does the error message
> failed to re-find parent key in "tablename_pkey"
> mean? This happens reproducibly during VACUUM on a certain table.
If it happens during vacuum (not vacuum full) then it must be coming
from _bt_pagedel, and it means tha
What does the error message
failed to re-find parent key in "tablename_pkey"
mean? This happens reproducibly during VACUUM on a certain table.
Would REINDEX fix it? Anything else we should check?
This is PostgreSQL 7.4.2. Are there relevant fixes later in the 7.4 series?
--
Peter Eisentrau
Dave Cramer <[EMAIL PROTECTED]> writes:
> Ok, that seems to have fixed it, so my next question is how did it get
> corrupt?
The nearest culprit seems to be whatever you did in analyze.c ;-). It's
not obvious to me how analyze.c would manage to mess up an index, since
it's nowhere near the index-h
Ok, that seems to have fixed it, so my next question is how did it get
corrupt?
Dave
On Tue, 2004-01-13 at 23:07, Tom Lane wrote:
> Dave Cramer <[EMAIL PROTECTED]> writes:
> > Actually the hack checks for oids, and doesn't make the index, if there
> > isn't an oid in the table, so I tried it with
Dave Cramer <[EMAIL PROTECTED]> writes:
> Actually the hack checks for oids, and doesn't make the index, if there
> isn't an oid in the table, so I tried it with a table without oids, and
> it still occurs.
My thought was that at this point the indexes on pg_attribute are very
possibly corrupt, an
On Tue, 2004-01-13 at 21:16, Tom Lane wrote:
> Dave Cramer <[EMAIL PROTECTED]> writes:
> > I can't recreate it either, it is only happening on my customers
> > machines, which are using an older version of redhat (7.2) and gcc 2.96
>
> > Is it possible these versions are relevant to the issue?
>
Tom Lane <[EMAIL PROTECTED]> writes:
> Hmm. Compiler bug maybe? I can't recall if gcc 2.96 had a good
> reputation or not.
2.96's reputation is of being *THE* canonical bad version of gcc.
mplayer for example has a configure check that specifically makes it difficult
to compile with 2.96 wi
Dave Cramer <[EMAIL PROTECTED]> writes:
> I can't recreate it either, it is only happening on my customers
> machines, which are using an older version of redhat (7.2) and gcc 2.96
> Is it possible these versions are relevant to the issue?
Hmm. Compiler bug maybe? I can't recall if gcc 2.96 had
I can't recreate it either, it is only happening on my customers
machines, which are using an older version of redhat (7.2) and gcc 2.96
Is it possible these versions are relevant to the issue?
Dave
On Tue, 2004-01-13 at 19:05, Tom Lane wrote:
> Dave Cramer <[EMAIL PROTECTED]> writes:
> > Sorry
Dave Cramer <[EMAIL PROTECTED]> writes:
> Sorry folks, this is a red-herring, my hack didn't have anything to do
> with it.
In that case you could provide a self-contained example? I tried this
a few times in the regression database:
select * into temp a from tenk1; drop table a;
and saw no pro
Sorry folks, this is a red-herring, my hack didn't have anything to do
with it. It occurs with or without the index. Question is was there a
bug between 7.4 and 7.4.1 which may have caused this?
Dave
On Tue, 2004-01-13 at 16:30, Dave Cramer wrote:
> I have hacked analyze.c to automatically create
I have hacked analyze.c to automatically create a unique index on the
oid when a table is created and I am getting the failed to re-find
parent key in pg_attribute_relid_attnam_index every 8 attempts to do the
following
select * from foo into temp a;
drop table a;
Currently analyze does not creat
15 matches
Mail list logo
