Re: [GENERAL] pg_upgrade ?deficiency
| От | Bruce Momjian |
|---|---|
| Тема | Re: [GENERAL] pg_upgrade ?deficiency |
| Дата | |
| Msg-id | 20131127213845.GB3785@momjian.us обсуждение исходный текст |
| Ответ на | Re: [GENERAL] pg_upgrade ?deficiency (Kevin Grittner <kgrittn@ymail.com>) |
| Ответы |
Re: [GENERAL] pg_upgrade ?deficiency
|
| Список | pgsql-hackers |
On Wed, Nov 27, 2013 at 06:05:13AM -0800, Kevin Grittner wrote: > Bruce Momjian <bruce@momjian.us> wrote: > > On Tue, Nov 26, 2013 at 03:25:44PM -0800, Kevin Grittner wrote: > >> Bruce Momjian <bruce@momjian.us> wrote: > >> > >>> How are we handling breakage of pg_dump, not pg_dumpall? > >> > >> That was discussed. Do you have something to add? > > > > I am confused what we are patching. Are we patching pg_dump, > > pg_dumpall, or both? > > Just pg_dumpall.c. OK, there was a pg_dump patch earlier which we are not using now. > > Are we propagating other settings from pg_dump to pg_dumpall, > > like statement_timeout? > > pg_dumpall output sets up the global objects (including their > properties) and then does a \connect to each database, followed by > the same output that pg_dump would generate for that database. > That includes the SET statements for statement_timeout, etc. The > patch does nothing to change what objects or properties the > pg_dumpall output tries to set up, it just sets a property *on the > current connection* to allow those statements to run without error. What is the logic that has us setting statement_timeout in pg_dump but default_transaction_read_only in pg_dumpall? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: