Prev: [HACKERS] pg_dump's checkSeek() seems inadequate
Next: [HACKERS] suppress automatic recovery after back crash
From: Andrew Dunstan on 27 Jun 2010 21:25


Tom Lane wrote:
> A somewhat more plausible scenario is that somebody might hope that
> they could do something like this:
>
> echo 'some custom header' >pg.dump
> pg_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().
>
>
>

What would anyone hope to achieve by such a manoeuvre, even if it
worked, which I am close the dead sure it would not?

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 27 Jun 2010 22:24
Andrew Dunstan <andrew(a)dunslane.net> writes:
> Tom Lane wrote:
>> A somewhat more plausible scenario is that somebody might hope that
>> they could do something like this:
>>
>> echo 'some custom header' >pg.dump
>> pg_dump -Fc >>pg.dump

> What would anyone hope to achieve by such a manoeuvre, even if it
> worked, which I am close the dead sure it would not?

It looks to me like it probably would actually work, so far as pg_dump
is concerned, but _discoverArchiveFormat() would break it because that
tries to do an unconditional fseeko(fp, 0, SEEK_SET) (and the position
counting is screwed up even if the fseeko fails). That could probably
be fixed if anyone thought this scenario was interesting enough to
justify work directed specifically at it. I did the ftello/fseeko dance
in checkSeek() just now because it seems sensible to me to have
checkSeek() actually verify functionality of both of those calls,
not because I think it's real likely that the position won't be 0.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andrew Dunstan on 28 Jun 2010 07:32


Tom Lane wrote:
> Andrew Dunstan <andrew(a)dunslane.net> writes:
>
>> Tom Lane wrote:
>>
>>> A somewhat more plausible scenario is that somebody might hope that
>>> they could do something like this:
>>>
>>> echo 'some custom header' >pg.dump
>>> pg_dump -Fc >>pg.dump
>>>
>
>
>> What would anyone hope to achieve by such a manoeuvre, even if it
>> worked, which I am close the dead sure it would not?
>>
>
> It looks to me like it probably would actually work, so far as pg_dump
> is concerned, but _discoverArchiveFormat() would break it because that
> tries to do an unconditional fseeko(fp, 0, SEEK_SET) (and the position
> counting is screwed up even if the fseeko fails). That could probably
> be fixed if anyone thought this scenario was interesting enough to
> justify work directed specifically at it.
>

IIRC pg_restore expects the archive to begin with the header and TOC
produced by pg_dump. Maybe I'm being dense, but I'm not able to see how
prefixing that with something else could possibly do something useful or
workable.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 28 Jun 2010 10:08
Andrew Dunstan <andrew(a)dunslane.net> writes:
> Tom Lane wrote:
>>>> echo 'some custom header' >pg.dump
>>>> pg_dump -Fc >>pg.dump

> IIRC pg_restore expects the archive to begin with the header and TOC
> produced by pg_dump. Maybe I'm being dense, but I'm not able to see how
> prefixing that with something else could possibly do something useful or
> workable.

You'd have to do something like

(1) open the file as stdin
(2) read the custom header
(3) exec pg_restore, telling it to read stdin

A possible application for this would be for the header to contain
information needed to prepare pg_restore's arguments, like where to
contact the server. I still think it's a bit too klugy to justify
the effort though.

In a more abstract sense, what this would be is basically a custom
label for a dump file. I could see that being useful, but if we
wanted to support it then it ought to be an actual Feature and not
a kluge like this. Something like

pg_dump --label 'any string' ... other args ...

pg_restore --print-label dump.file

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andrew Dunstan on 28 Jun 2010 11:19


Tom Lane wrote:
> In a more abstract sense, what this would be is basically a custom
> label for a dump file. I could see that being useful, but if we
> wanted to support it then it ought to be an actual Feature and not
> a kluge like this. Something like
>
> pg_dump --label 'any string' ... other args ...
>
> pg_restore --print-label dump.file
>
>
>

Right, or possibly a file that would be added. I don't think we should
waste any effort at all on the kluge, or worrying about whether or not
it would work.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2
Prev: [HACKERS] pg_dump's checkSeek() seems inadequate
Next: [HACKERS] suppress automatic recovery after back crash