ERROR: failed to re-find parent key in "sl_seqlog_idx" for deletion target

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 searching it might just as well be a good idea to go straight to 8.3 during the summer.

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=FALSE);
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 with which this sequence update is associated';
COMMENT ON COLUMN _replication.sl_seqlog.seql_last_value IS 'Last value published 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 were holding back some jobs that needed to finished. But in case the problem 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/index.

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

// John