Re: pg_dump's checkSeek() seems inadequate

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump's checkSeek() seems inadequate
Дата
Msg-id 2508.1277677142@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump's checkSeek() seems inadequate  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pg_dump's checkSeek() seems inadequate  (Robert Haas <robertmhaas@gmail.com>)
Re: pg_dump's checkSeek() seems inadequate  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jun 27, 2010 at 1:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If I change the test to be
>>        fseeko(fp, 0, SEEK_SET)
>> then it does the right thing.

> Well, I guess it depends on what you think the chances are that the
> revised test will fail on some other obscure platform.

To believe that, you'd have to believe that fseeko(fp, 0, SEEK_SET)
will fail but fseeko(fp, something-not-zero, SEEK_SET) will succeed.

A somewhat more plausible scenario is that somebody might hope that
they could do something like this:
echo 'some custom header' >pg.dumppg_dump -Fc >>pg.dump

I believe that (at least on most Unixen) doing fseeko(fp, 0, SEEK_SET)
would result in overwriting the custom header, where it would not have
been overwritten before.  However the usefulness of the above is at
best far-fetched; and I'm not very sure that it works today anyway,
since pg_dump/pg_restore seem to assume that manual byte counting should
match the results of ftell().
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_dump's checkSeek() seems inadequate
Следующее
От: Mike Fowler
Дата:
Сообщение: Re: [PATCH] Re: Adding XMLEXISTS to the grammar