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

Re: Pg_upgrade speed for many tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-06 00:22:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> That could generate a lot of WAL files if used regularly.  :-(  Does
> SELECT txid_current() generate WAL?  I think it does.

Well, it assigns a XID.  I'm not sure it'd be a good idea to assume that
the mere act of doing that, without actually writing anything to tables,
would result in a synchronous commit.  (For example, if the transaction
were to abort not commit, I'm pretty sure we'd not bother to fsync its
abort record.  There might be, today or in the future, a similar
optimization for successful xacts that created no WAL records.)

I thought the idea of creating a temp table was the most robust one.
A regular table would be even more certain to generate an fsync, but
it has the disadvantages that you can't easily guarantee no name
collision against a user table, nor guarantee that the table wouldn't
be left behind after a crash at the wrong instant.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Josh BerkusDate: 2012-11-06 01:39:40
Subject: Re: Pg_upgrade speed for many tables
Previous:From: Tom LaneDate: 2012-11-06 00:12:42
Subject: Re: alter table tablename add column - breaks pl/pgsql function returns tablename

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