Солодовников Константин <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
