Re: PostgreSQL 8.1.0 catalog corruption
От | Tom Lane |
---|---|
Тема | Re: PostgreSQL 8.1.0 catalog corruption |
Дата | |
Msg-id | 6860.1132624258@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PostgreSQL 8.1.0 catalog corruption (Bob Ippolito <bob@redivi.com>) |
Ответы |
Re: PostgreSQL 8.1.0 catalog corruption
|
Список | pgsql-hackers |
Bob Ippolito <bob@redivi.com> writes: > I don't touch pg_class at all... this is what I'm doing (over and > over again). > -- clone_table is almost always a no-op, but once a day it creates a > new table > SELECT clone_table('ping', 'ping_%s', '') > SELECT drop_ping_constraints('ping_%s') > -- stuff that doesn't effect DDL > SELECT add_ping_constraints('ping_%s') Hm, do the drop/add constraint functions get executed even when clone_table decides not to make a new table? If so, that would probably explain the pattern I'm seeing in the dump of many updates of the pg_class row. This still doesn't give us a hint why the row disappeared, but maybe we can try running these functions for awhile and see if anyone can reproduce a failure. regards, tom lane
В списке pgsql-hackers по дате отправления: