From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, Zeugswetter Andreas OSB sIT <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> |
Subject: | Re: statement timeout vs dump/restore |
Date: | 2008-05-06 21:56:53 |
Message-ID: | 4820D425.9080801@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
>
>> ISTR being unconvinced by the pg_restore arguments, but as I think about it
>> some more, for someone to set statement_timeout on a production system, and
>> then have that be blindly overridden by any random pg_dump user seems a bit
>> unfair. pg_dump is not only used as a backup tool, it is also used as a
>> general user tool (for example, pgadmin calls pg_dump if you want to see a
>> tables schema).
>>
>
> So? In those usages, it's not going to run long enough to have a
> statement_timeout problem anyway.
>
> When there is a data dump involved, you still have to defend the
> proposition that it's okay for pg_dump to deliver a bad dump if
> statement_timeout hits it. I can't accept that.
>
>
>
I agree.
What is more, the solution to the non-dump uses of pg_dump is to put
that functionality in a library where clients can call it directly
rather than using pg_dump.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-05-06 22:02:23 | Re: Patch to update libpqxx's homepage in README |
Previous Message | Tom Lane | 2008-05-06 21:44:44 | Re: [0/4] Proposal of SE-PostgreSQL patches |