pg_dump's checkSeek() seems inadequate

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pg_dump's checkSeek() seems inadequate
Дата
Msg-id 28254.1277660531@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: pg_dump's checkSeek() seems inadequate  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pg_dump's checkSeek() seems inadequate  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
While testing a fix for the pg_restore issues mentioned a few days ago,
I noticed that checkSeek() returns true on my old HPUX box even when the
input is in fact not seekable, for instance a pipe.  This leads to
pg_restore failing completely in cases where it ought to work, like this:

$ cat vector.dump | pg_restore -d vector
pg_restore: [custom archiver] WARNING: ftell mismatch with expected position -- ftell used
pg_restore: [custom archiver] error during file seek: Illegal seek
$ 

The test that checkSeek() is using is to see whether this works:
fseeko(fp, 0, SEEK_CUR)

and apparently on this platform that's a no-op even on an otherwise
unseekable file.  I don't know how common this behavior is; I don't
recall having seen complaints about pg_restore failing for other people.

If I change the test to be
fseeko(fp, 0, SEEK_SET)

then it does the right thing.  Since checkSeek() is applied immediately
after opening the input file this should be OK, but it does limit the
scope of usefulness of that function.

Any thoughts about whether or not to apply such a patch?  If it should
be changed, should we back-patch it?
        regards, tom lane


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

Предыдущее
От: Mike Fowler
Дата:
Сообщение: [PATCH] Re: Adding xpath_exists function
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump's checkSeek() seems inadequate