Re: [HACKERS] 6.5.1, error in pg_dump

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] 6.5.1, error in pg_dump
Дата
Msg-id 10786.933979696@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] 6.5.1, error in pg_dump  (Don Baccus <dhogaza@pacifier.com>)
Ответы Re: [HACKERS] 6.5.1, error in pg_dump  (Don Baccus <dhogaza@pacifier.com>)
Список pgsql-hackers
Don Baccus <dhogaza@pacifier.com> writes:
> Can not create pgdump_oid table.  Explanation from backend: 'ERROR:  cannot
> create pgdump_oid
> '.

AFAICT, the only way that you'd get that precise wording out of the
backend is if its attempt to create the physical file for the table
fails --- that is, open(filename, O_RDWR | O_CREAT | O_EXCL, 0600)
fails.  The only error message I can find with that wording is in
smgrcreate(), and it looks like all the other potential causes of
failure below that point (such as running out of memory) would yield
different messages.

So, it would seem that the initial cause of the problem is that there
was already a file by that name --- perhaps because some earlier
instance of postgres failed to unlink it.

I'm not sure about the bizarrenesses you report later on --- they
sound like the system tables may have gotten corrupted, or perhaps
just the relation cache inside the backend.  (Did killing the backend
and starting a new one help?)  But I am thinking the error messages
must have been different at that point...

We saw vaguely similar behaviors with temp tables when we were still
flushing the bugs out of temp tables.  I wonder if there are still
some temp-table-related bugs?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Lamar Owen
Дата:
Сообщение: Release 2 testing RPMS -- includes ALPHA patches.
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] plpgsql requires bison