Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Date
Msg-id 3cf2505bb2509c34a3fd9672014c5c0e@biglumber.com
Whole thread Raw
In response to Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


> I agree that we should do that, but the thread on -hackers ("Autovacuum
> vs statement_timeout") wasn't totally conclusive. Greg Sabine Mullane
> and Peter Eisentraut argued that we shouldn't, but neither provided a
> plausible use case where a statement_timeout on restoring a dump would
> be useful. I'm thinking we should apply the patch unless someone comes
> up with one.

I don't think it's fair to simply discard the use cases provided as
"implausible" and demand one more to your liking. I strongly dislike
having a giant dump file written that has non-vital configuration
variables embedded in the top of it, precluding any user choice
whatsoever[1]. As before, where are the reports of all the people
having their manual restorations interrupted by a statement_timeout?

[1] Short of editing a potentially GB-size file, or using
some sed/shell shenanigans to strip out the suspect setting.

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200804161814
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkgGetEACgkQvJuQZxSWSsg+4ACghvlBkIth1aBiGpFPFPj+HWgf
iyEAnj+WK9MQL+ZQqKoTcLOe/lvoNkkV
=Nlyg
-----END PGP SIGNATURE-----



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Lessons from commit fest
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Timely reporting of COPY errors