Re: PostgreSQL 8.1.0 catalog corruption
От | Bob Ippolito |
---|---|
Тема | Re: PostgreSQL 8.1.0 catalog corruption |
Дата | |
Msg-id | 54B01BB8-B0C2-4AB5-BA97-4A5DE26CD939@redivi.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL 8.1.0 catalog corruption (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PostgreSQL 8.1.0 catalog corruption
|
Список | pgsql-hackers |
On Nov 21, 2005, at 5:50 PM, Tom Lane wrote: > 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. Yes, they do. The constraints are there for constraint exclusion. > 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. If it matters, I have had the same code running on Bizgres 0.7.4 for quite some time with no issues at all. I may just have to migrate the test server to Bizgres 0.8 if we can't figure out why PostgreSQL 8.1.0 choked here. -bob
В списке pgsql-hackers по дате отправления: