Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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?



In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group