Re: pg_upgrade ?deficiency

From: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
To: pgsql-general <pgsql-general(at)postgresql(dot)org>
Cc: "Hilbert, Sebastian" <Sebastian(dot)Hilbert(at)gmx(dot)net>
Subject: Re: pg_upgrade ?deficiency
Date: 2013-11-21 14:39:18
Message-ID: 20131121143918.GA25318@hermes.hilbert.loc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Nov 21, 2013 at 06:22:50AM -0800, Kevin Grittner wrote:

> I would be happy to supply a patch to treat
> default_transaction_read_only the same as statement_timeout or
> standard_conforming_strings in pg_dump and related utilities.
> Since it causes backup/restore failure

... (and pg_upgrade failures -- which may internally
just be dump/restore cycles ?) ...

> on perfectly valid databases I even think this is
> a bug which merits back-patching.

Thanks so much, Kevin, for offering to work
on that part. Maybe it's a small thing but
it'll make PostgreSQL once again feel
professionally consistent.

I would have needed to become proficient in C
and get acqainted with the PG source in order
to produce a patch myself.

Thanks,
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mike Broers 2013-11-21 20:10:56 corruption issue after server crash - ERROR: unexpected chunk number 0
Previous Message Kevin Grittner 2013-11-21 14:22:50 Re: pg_upgrade ?deficiency

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-11-21 14:44:58 Re: Proof of concept: standalone backend with full FE/BE protocol
Previous Message Heikki Linnakangas 2013-11-21 14:25:02 Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.