Re: statement timeout vs dump/restore

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

In response to

Browse pgsql-hackers by date

  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