> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Tuesday, April 03, 2001 3:35 AM
> To: ks@tcnet.ru; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] Loosing files after backend crash
>
>
> pgsql-bugs@postgresql.org writes:
> > During execution of some sql code backend crashed (the
> reason for it's
> > crashing is not the actual topic of this report).
> > And tried to delete the sequence, which i created in the
> previous session.
> > That's what pgsql told me:
> > ---8<---
> > Netflow_Test=# drop SEQUENCE seq_i___data_buffer ;
> > ERROR: cannot open seq_i___data_buffer: No such file or directory
>
> Was that a system-wide crash, or just a backend crash?
It was just a backend crash.
> 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.
If so, how can backend's crash "erase" the file from disk?
BTW, I have some more facts to report.
Just about half an hour ago the backend crashed one more time in the same
situation.
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.
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.)
The "relkind" attribute of the corresponding two tuples in the pg_class
table hold letter 'S' (The uppercase 's').
Regards,
Konstantin Solodovnikov.