Re: Pg_upgrade speed for many tables - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Pg_upgrade speed for many tables
Date
Msg-id CAMkU=1z59rfjuXPUfUnLBGarbs7U3AfmtOayf4MV6A9bREuY7Q@mail.gmail.com
Whole thread Raw
In response to Re: Pg_upgrade speed for many tables  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Nov 5, 2012 at 1:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>> AFAIR any transaction that modifies catalogs gets sync commit forcibly,
>> regardless of the setting.  And sync commit means you get to wait for
>> all previous transactions to be flushed as well.  So simply creating a
>> temp table ought to do the trick ...
>
> I don't think there's a carve-out for system tables ... but creating a
> temp table with synchronous_commit=on will certainly do the trick.

But that seems like something that might be optimized away in the
future (for example, so that temp tables can be used on hot standbys)
resulting in action-at-a-distance breakage.

Is txid_current() more fundamental, i.e. less likely to change?

Cheers,

Jeff



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Pg_upgrade speed for many tables
Next
From: Andrew Dunstan
Date:
Subject: Re: Deprecations in authentication