| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, Zeugswetter Andreas OSB sIT <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> |
| Subject: | Re: statement timeout vs dump/restore |
| Date: | 2008-05-06 21:33:13 |
| Message-ID: | 25117.1210109593@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2008-05-06 21:34:49 | Re: [GENERAL] psql \pset pager |
| Previous Message | Robert Treat | 2008-05-06 20:51:13 | Re: statement timeout vs dump/restore |