Horton
Menu

Re: Fix pg_upgrade to preserve datdba

Jan Wieck <jan@wi3ck.info>

View thread
From: Jan Wieck <jan@wi3ck.info>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Magnus Hagander <magnus@hagander.net>, Robins Tharakan <tharakan@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-03-21T19:36:51Z
Lists: pgsql-hackers 
On 3/21/21 2:34 PM, Tom Lane wrote:
> and I see
> 
> --
> -- Name: joe; Type: DATABASE; Schema: -; Owner: joe
> --
> 
> CREATE DATABASE joe WITH TEMPLATE = template0 ENCODING = 'SQL_ASCII' LOCALE = 'C';
> 
> 
> ALTER DATABASE joe OWNER TO joe;
> 
> so at least in this case it's doing the right thing.  We need a bit
> more detail about the context in which it's doing the wrong thing
> for you.

After moving all of this to a pristine postgresql.org based repo I see 
the same. My best guess at this point is that the permission hoops, that 
RDS and Aurora PostgreSQL are jumping through, was messing with this. 
But that has nothing to do with the actual topic.

So let's focus on the actual problem of running out of XIDs and memory 
while doing the upgrade involving millions of small large objects.


Regards, Jan


-- 
Jan Wieck
Principle Database Engineer
Amazon Web Services

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Count individual SQL commands in pg_restore's --transaction-size mode.

  2. Reduce number of commands dumpTableSchema emits for binary upgrade.

  3. Invent --transaction-size option for pg_restore.

  4. Rearrange pg_dump's handling of large objects for better efficiency.

  5. Add temporal PRIMARY KEY and UNIQUE constraints

  6. Fix typo and case in messages