Re: Loosing files after backend crash - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Loosing files after backend crash
Date
Msg-id 2686.986307901@sss.pgh.pa.us
Whole thread Raw
In response to RE: Loosing files after backend crash  (Солодовников Константин <ks@tcnet.ru>)
List pgsql-bugs
Солодовников Константин <ks@tcnet.ru> writes:
>> It seems to me that your kernel must have lost that file for you; Postgres
>> wouldn't have gone out and deleted it.
> How could kernel _loose_ the file, which was already created?
> I would agree with the possibility of loosing some data in the file during
> the backend crash.
> But loosing the whole file ...
> The sequence was previously created in an already committed transaction.
> Correct me if I am wrong, but after I said "commit" the file would be on my
> disk.

Sooner than that: a create call is issued to the kernel as soon as you
say CREATE SEQUENCE.

> If so, how can backend's crash "erase" the file from disk?

I'd like to know that too.

> BTW, I have some more facts to report.
> Just about half an hour ago the backend crashed one more time in the same
> situation.

Backtrace from core file, please?

> Now it has not only lost the file for my sequence (the same very sequence),
> but it also has TWO tuples in the pg_class table with the name of my
> sequence.
> All other attribites of the tuples also hold identical values.
> And PGSQL doesn't consider it to be a sequence.

Could we see the exact contents of pg_class for the sequence?  (both
tuples including OIDs)

> When I say 'DROP SEQUENCE ...' it says that it is not a sequence and advises
> me to use 'DROP TABLE'.
> When I say 'DROP TABLE ...' it says something like 'cannot drop system table
> pg_temp.XXXXX.X' (I changed the actial digits into 'X'-es. Not sure about
> exact words.)

Hm, that sounds like some sort of conflict with a temp table.  Is it
possible that you have been using a temp table name that matches the
sequence name?  Are there any pg_class entries whose names begin with
pg_temp, and if so could we see details on those too?
        regards, tom lane


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL 7.0.2 Date Miscalculation
Next
From: pgsql-bugs@postgresql.org
Date:
Subject: to_char miscalculation on April Fool's Day, the start of daylight savings