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  (Kevin Grittner <kgrittn@ymail.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Incomplete freezing when truncating a relation during vacuum