Haribabu Kommi writes:
> On Tue, Jan 23, 2018 at 8:56 AM, Tom Lane wrote:
>> I'm thinking we'd still need to do what I said in the previous message,
>> and change pg_dump so that the restore session will absorb ALTER DATABASE
>> settings before proceeding. Otherwise, at minimum, we have a hazard
On Tue, Jan 23, 2018 at 8:56 AM, Tom Lane wrote:
> I wrote:
> > Specifically, I see failures like this on machines where the prevailing
> > locale isn't C or US:
>
> > pg_restore: [archiver (db)] Error while PROCESSING TOC:
> > pg_restore: [archiver (db)] Error from TOC entry 4871; 2618 34337 RUL
I wrote:
> Specifically, I see failures like this on machines where the prevailing
> locale isn't C or US:
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 4871; 2618 34337 RULE
> rtest_emp rtest_emp_del pgbf
> pg_restore: [archiver (db)
I wrote:
> Commit 4bd371f6f's hack to emit "SET default_transaction_read_only = off"
> is gone: we now dodge that problem by the expedient of not issuing ALTER
> DATABASE SET commands until after reconnecting to the target database.
> Therefore, such settings won't apply during the restore session.
Robert Haas writes:
> On Mon, Jan 22, 2018 at 2:09 PM, Tom Lane wrote:
>> pg_dumpall with --clean will now drop and recreate the "postgres" and
>> "template1" databases in the target cluster, allowing their locale and
>> encoding settings to be changed if necessary, and providing a cleaner
>> way
On Mon, Jan 22, 2018 at 2:09 PM, Tom Lane wrote:
> pg_dumpall with --clean will now drop and recreate the "postgres" and
> "template1" databases in the target cluster, allowing their locale and
> encoding settings to be changed if necessary, and providing a cleaner
> way to set nondefault tablespa
