Re: Pg_upgrade speed for many tables

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pg_upgrade speed for many tables
Date: 2012-11-05 22:14:16
Message-ID: CAMkU=1z59rfjuXPUfUnLBGarbs7U3AfmtOayf4MV6A9bREuY7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 5, 2012 at 1:39 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2012-11-05 22:15:41 Re: Deprecations in authentication
Previous Message Andres Freund 2012-11-05 22:03:45 Re: Pg_upgrade speed for many tables