Обсуждение: ERROR: failed to re-find parent key in "sl_seqlog_idx" for deletion target

Hi!

Hope anyone can shed some light on this. I was struck by the following erro=
r in the slony log but I believe it's not a slony error, rather that slony =
triggers an error in PostgreSQL. The error message is:

cleanupThread: vacuum  analyze sl_seqlog; - ERROR:  failed to re-find paren=
t key in "sl_seqlog_idx" for deletion target

I've tried to find some posts about it and I could only find one post where=
 Tom states that reindexing should do the trick, but there is no answer tha=
t reindexing did solve the case. The post is here:
http://archives.postgresql.org/pgsql-bugs/2007-08/msg00035.php

Well, it is supposed to have been fixed to version 8.2, but it's a PostgreS=
QL 8.2.4 x86_64 server running on Debian that triggers the error.

Thank in advance!
// John

John Parnefjord wrote:
> Hi!
>
> Hope anyone can shed some light on this. I was struck by the
> following error in the slony log but I believe it's not a slony
> error, rather that slony triggers an error in PostgreSQL. The error
> message is:

Correct, that's not a backend error.


> cleanupThread: vacuum  analyze sl_seqlog; - ERROR:  failed to re-find
> parent key in "sl_seqlog_idx" for deletion target
>
> I've tried to find some posts about it and I could only find one post
> where Tom states that reindexing should do the trick, but there is no
> answer that reindexing did solve the case. The post is here:
> http://archives.postgresql.org/pgsql-bugs/2007-08/msg00035.php
>
> Well, it is supposed to have been fixed to version 8.2, but it's a
> PostgreSQL 8.2.4 x86_64 server running on Debian that triggers the
> error.

Hi!

Please copy out the files as requested in that email - I'm sure Tom is
still interested in debugging it to find the issue. After that, try a
REINDEX to see if it solves your problem.

And while you're at it, you guys should be at 8.2.7, not 8.2.4.. :-P
There are some index fixes between those versions (specifically in
8.2.5), but I don't know the details of them enough to say if this
could be the problem you're hitting.

//Magnus

> Please copy out the files as requested in that email - I'm sure Tom is
> still interested in debugging it to find the issue. After that, try a
> REINDEX to see if it solves your problem.

Ok, see the snippets below. I just cut them from the PgAdminIII interface. =
Drop me a mail if you need more info.


> And while you're at it, you guys should be at 8.2.7, not 8.2.4.. :-P

Yes, you're right. But as we are trying out tsearch2 for full text searchin=
g it might just as well be a good idea to go straight to 8.3 during the sum=
mer.


> There are some index fixes between those versions (specifically in
> 8.2.5), but I don't know the details of them enough to say if this
> could be the problem you're hitting.


Thanks Magnus!

// John




-- Table: _replication.sl_seqlog
CREATE TABLE _replication.sl_seqlog
(
  seql_seqid integer, -- Sequence ID
  seql_origin integer, -- Publisher node at which the sequence originates
  seql_ev_seqno bigint, -- Slony-I Event with which this sequence update is=
 associated
  seql_last_value bigint -- Last value published for this sequence
)
WITH (OIDS=3DFALSE);
ALTER TABLE _replication.sl_seqlog OWNER TO slony;
COMMENT ON TABLE _replication.sl_seqlog IS 'Log of Sequence updates';
COMMENT ON COLUMN _replication.sl_seqlog.seql_seqid IS 'Sequence ID';
COMMENT ON COLUMN _replication.sl_seqlog.seql_origin IS 'Publisher node at =
which the sequence originates';
COMMENT ON COLUMN _replication.sl_seqlog.seql_ev_seqno IS 'Slony-I Event wi=
th which this sequence update is associated';
COMMENT ON COLUMN _replication.sl_seqlog.seql_last_value IS 'Last value pub=
lished for this sequence';


-- Index: _replication.sl_seqlog_idx
CREATE INDEX sl_seqlog_idx
  ON _replication.sl_seqlog
  USING btree
  (seql_origin, seql_ev_seqno, seql_seqid);

John Parnefjord wrote:
> > Please copy out the files as requested in that email - I'm sure Tom
> > is still interested in debugging it to find the issue. After that,
> > try a REINDEX to see if it solves your problem.
>
> Ok, see the snippets below. I just cut them from the PgAdminIII
> interface. Drop me a mail if you need more info.

Ok, misunderstandment. What's needed are the actual data files, not the
definition of the tables. That is, the files under $PGDATA that
contains the table and it's indexes.

Can't send those on-list, they're too large, but if you can put
together a .tar.gz for someone to look at. Before you send it, we'll
want to check with Tom that he's still interested in looking at it :-)


> > And while you're at it, you guys should be at 8.2.7, not 8.2.4.. :-P
>
> Yes, you're right. But as we are trying out tsearch2 for full text
> searching it might just as well be a good idea to go straight to 8.3
> during the summer.

Probably, yes.


//Magnus

Yikes! I already done a reindexing of the table as there where locks that w=
ere holding back some jobs that needed to finished.  But in case the proble=
m should appear again we will take a copy of the actual data file.

Anyway, the case must regarded as solved. Put shortly, reindex the table/in=
dex.


By the way thanks for all the effort you put into making PostgreSQL such a =
marvelous database manager!

// John


> -----Original Message-----
> From: pgsql-bugs-owner@postgresql.org [mailto:pgsql-bugs-
> owner@postgresql.org] On Behalf Of Magnus Hagander
> Sent: den 22 april 2008 13:58
> To: John Parnefjord
> Cc: pgsql-bugs@postgresql.org; Tom Lane
> Subject: Re: [BUGS] ERROR: failed to re-find parent key in
> "sl_seqlog_idx" for deletion target
>
> John Parnefjord wrote:
> > > Please copy out the files as requested in that email - I'm sure Tom
> > > is still interested in debugging it to find the issue. After that,
> > > try a REINDEX to see if it solves your problem.
> >
> > Ok, see the snippets below. I just cut them from the PgAdminIII
> > interface. Drop me a mail if you need more info.
>
> Ok, misunderstandment. What's needed are the actual data files, not the
> definition of the tables. That is, the files under $PGDATA that
> contains the table and it's indexes.
>
> Can't send those on-list, they're too large, but if you can put
> together a .tar.gz for someone to look at. Before you send it, we'll
> want to check with Tom that he's still interested in looking at it :-)
>
>
> > > And while you're at it, you guys should be at 8.2.7, not 8.2.4.. :-
> P
> >
> > Yes, you're right. But as we are trying out tsearch2 for full text
> > searching it might just as well be a good idea to go straight to 8.3
> > during the summer.
>
> Probably, yes.
>
>
> //Magnus
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs