Re: Loosing files after backend crash

=?KOI8-R?Q?=F3=CF=CC=CF=C4=CF=D7=CE=C9=CB=CF=D7_=EB=CF=CE=D3=D4=C1?= =?KOI8-R?Q?=CE=D4=C9=CE?= <ks(at)tcnet(dot)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