Thread: ERROR: could not find tuple for trigger 37463634
Short and simple: I'm trying to do the following:
postgres@master-db01:~$ psql pnssi_profiles_bench
psql (9.0.3)
Type "help" for help.
pnssi_profiles_bench=# drop SCHEMA _pnssi_slony_bench_profiles_01_110 cascade;
ERROR: could not find tuple for trigger 37463634
As you can see, this is a slony setup, but I'm not sure that's relevant.
Other info:
pnssi_profiles_bench=# select * from pg_depend where objid=37463634;
classid | objid | objsubid | refclassid | refobjid | refobjsubid | deptype
---------+----------+----------+------------+----------+-------------+---------
2620 | 37463634 | 0 | 1255 | 37462497 | 0 | n
2620 | 37463634 | 0 | 1259 | 19914767 | 0 | a
(2 rows)
pnssi_profiles_bench=# select * from pg_class where oid=1255;
relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages | reltuples |
reltoastrelid| reltoastidxid | relhasindex | relisshared | relistemp | relkind | relnatts | relchecks | relhasoids |
relhaspkey| relhasexclusion | relhasrules | relhastriggers | relhassubclass | relfrozenxid | relacl | reloptions
---------+--------------+---------+-----------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+-----------+---------+----------+-----------+------------+------------+-----------------+-------------+----------------+----------------+--------------+---------------+------------
pg_proc | 11 | 81 | 0 | 10 | 0 | 0 | 0 | 304 | 3635 |
2836 | 0 | t | f | f | r | 25 | 0 | t | f
| f | f | f | f | 150006110 | {=r/postgres} |
(1 row)
pnssi_profiles_bench=# select * from pg_class where oid=2620;
relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages |
reltuples| reltoastrelid | reltoastidxid | relhasindex | relisshared | relistemp | relkind | relnatts | relchecks |
relhasoids| relhaspkey | relhasexclusion | relhasrules | relhastriggers | relhassubclass | relfrozenxid | relacl
|reloptions
------------+--------------+---------+-----------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+-----------+---------+----------+-----------+------------+------------+-----------------+-------------+----------------+----------------+--------------+---------------+----------
pg_trigger | 11 | 10732 | 0 | 10 | 0 | 11738 | 0 | 312 |
11814| 2336 | 0 | t | f | f | r | 15 | 0 | t
| f | f | f | f | f | 150006329 | {=r/postgres} |
(1 row)
I don't have the rest of the info (the entry in pg_class with OID 1259)
because right now I'm running a preventive VACUUM, which it's taking ages.
What I understand is that it seems that somehow I got some references to objects
that do not exist anymore, so I think I should run the equivalent of fsck I this
database. My speculations apart, how to proceed to unlock this situation?
--
Marcos Dione
SysAdmin
Astek Sud-Est
pour FT/TGPF/OPF/PORTAIL/DOP/HEBEX @ Marco Polo
04 97 12 62 45 - mdione.ext@orange.com
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or
falsified.
Thank you.
De : pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] De la part de mdione.ext@orange.com
> I don't have the rest of the info (the entry in pg_class with OID 1259)
> because right now I'm running a preventive VACUUM, which it's taking ages.
Ok, the vacuum finished, but I still get the same error. Here's the rest
of the info:
pnssi_profiles_bench=# select * from pg_class where oid=2620 or oid=1255 or oid=1259;
relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages |
reltuples| reltoastrelid | reltoastidxid | relhasindex | relisshared | relistemp | relkind | relnatts | relchecks |
relhasoids| relhaspkey | relhasexclusion | relhasrules | relhastriggers | relhassubclass | relfrozenxid | relacl
|reloptions
------------+--------------+---------+-----------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+-----------+---------+----------+-----------+------------+------------+-----------------+-------------+----------------+----------------+--------------+---------------+------------
pg_proc | 11 | 81 | 0 | 10 | 0 | 0 | 0 | 304 |
3635| 2836 | 0 | t | f | f | r | 25 | 0 | t
| f | f | f | f | f | 258153645 | {=r/postgres} |
pg_class | 11 | 83 | 0 | 10 | 0 | 0 | 0 | 490 |
17440| 0 | 0 | t | f | f | r | 27 | 0 | t
| f | f | f | f | f | 258153672 | {=r/postgres} |
pg_trigger | 11 | 10732 | 0 | 10 | 0 | 11738 | 0 | 312 |
11814| 2336 | 0 | t | f | f | r | 15 | 0 | t
| f | f | f | f | f | 258153674 | {=r/postgres} |
(3 rows)
--
Marcos Dione
SysAdmin
Astek Sud-Est
pour FT/TGPF/OPF/PORTAIL/DOP/HEBEX @ Marco Polo
04 97 12 62 45 - mdione.ext@orange.com
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or
falsified.
Thank you.
De : pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] De la part de mdione.ext@orange.com > What I understand is that it seems that somehow I got some references to objects > that do not exist anymore, so I think I should run the equivalent of fsck I this > database. My speculations apart, how to proceed to unlock this situation? Actually I'm quite tempted to do something like this: http://archives.postgresql.org/pgsql-admin/2006-05/msg00084.php Should that be enough or as the dangling question says, there should be something else to do? -- Marcos Dione SysAdmin Astek Sud-Est pour FT/TGPF/OPF/PORTAIL/DOP/HEBEX @ Marco Polo 04 97 12 62 45 - mdione.ext@orange.com _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.
<mdione.ext@orange.com> writes:
> Short and simple: I'm trying to do the following:
> postgres@master-db01:~$ psql pnssi_profiles_bench
> psql (9.0.3)
> Type "help" for help.
> pnssi_profiles_bench=# drop SCHEMA _pnssi_slony_bench_profiles_01_110 cascade;
> ERROR: could not find tuple for trigger 37463634
You might try reindexing pg_trigger before doing anything more invasive,
just in case the tuple is there but it's not being found because of a
messed-up index.
> As you can see, this is a slony setup, but I'm not sure that's relevant.
It could be --- Slony plays some not-very-nice games with the system
catalogs, or at least used to. If reindex doesn't fix things I'd
suggest asking about this on the Slony lists.
regards, tom lane
De : Tom Lane [mailto:tgl@sss.pgh.pa.us] > > pnssi_profiles_bench=# drop SCHEMA _pnssi_slony_bench_profiles_01_110 > cascade; > > ERROR: could not find tuple for trigger 37463634 > > You might try reindexing pg_trigger before doing anything more invasive, > just in case the tuple is there but it's not being found because of a > messed-up index. Well, at some point we tried "REINDEX DATABASE pnssi_profiles_bench;" and "REINDEX SYSTEM pnssi_profiles_bench;", would that be equivalent? > > > As you can see, this is a slony setup, but I'm not sure that's > > relevant. > > It could be --- Slony plays some not-very-nice games with the system > catalogs, or at least used to. If reindex doesn't fix things I'd > suggest asking about this on the Slony lists. I'm sorry to say that I ended up taking drastic measures (several "delete from pg_depend where refobjid=foo;") before trying something else (after some pressure from the-powers-that-are :-P). after that we managed to drop the schema. I have the details if you want. in any case, this is not the first time we drop a slony schema to rebuild everything, but it's the first time we have this kind of problems. I'm pretty sure after what I have done some objects might still be dangling in the db (even more, now that I remember, at some point we did "delete from pg_trigger where tgname like '%01_110%';"; yes, I know, it's a blunt approach). Is there any way to find those, if they exist? -- Marcos Dione SysAdmin Astek Sud-Est pour FT/TGPF/OPF/PORTAIL/DOP/HEBEX @ Marco Polo 04 97 12 62 45 - mdione.ext@orange.com _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you.
<mdione.ext@orange.com> writes:
> De�: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>> You might try reindexing pg_trigger before doing anything more invasive,
>> just in case the tuple is there but it's not being found because of a
>> messed-up index.
> Well, at some point we tried "REINDEX DATABASE pnssi_profiles_bench;"
> and "REINDEX SYSTEM pnssi_profiles_bench;", would that be equivalent?
Yeah, that would have covered it.
> I'm pretty sure after what I have done some objects might still be
> dangling in the db (even more, now that I remember, at some point we did
> "delete from pg_trigger where tgname like '%01_110%';"; yes, I know,
> it's a blunt approach). Is there any way to find those, if they exist?
You could try the queries in the "oidjoins" regression test, which would
verify all the implied foreign key relationships in the system catalogs.
I don't think that covers pg_depend though; you'd need to gin up more
complicated queries if you wanted to look for dangling pg_depend
entries.
regards, tom lane