Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
От | Greg Sabino Mullane |
---|---|
Тема | Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout |
Дата | |
Msg-id | 3cf2505bb2509c34a3fd9672014c5c0e@biglumber.com обсуждение исходный текст |
Ответ на | Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: Patch for Prevent pg_dump/pg_restore from being
affected by statement_timeout
Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout |
Список | 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 по дате отправления: