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

Re: making an unlogged table logged

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: making an unlogged table logged
Date: 2011-01-05 19:36:22
Message-ID: 1294256182.19612.14450.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 2011-01-04 at 21:41 -0500, Robert Haas wrote:

> 6. If wal_level != minimal, XLOG every page of every fork except the
> init fork, for both the table and the associated indexes. (Note that
> this step also requires an AccessExclusiveLock rather than some weaker
> lock, because of the arbitrary rule that only AccessExclusiveLocks are
> sent to standbys.  If we held only ShareRowExclusiveLock on the
> master, for example, a Hot Standby backend might read the table while
> it's only been half-copied.) 

That rule is not arbitrary, there is simply no need to send other lock
types since they would not conflict with queries. It's an optimisation.

The lock strength selected on the master doesn't need to be the same as
the lock strength on the standby. You could quite easily generate AEL
lock records to send to standby, without actually taking that lock level
on the master.

Question: what does an unlogged table look like on the standby? Are they
visible at all, does it throw an error, or do they just look empty. We
probably need some docs in the HS section to explain that. I hope the
answer isn't "look empty" since that is effectively data loss for people
spreading queries across multiple nodes.

-- 
 Simon Riggs           http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2011-01-05 19:36:24
Subject: Re: Upgrading Extension, version numbers
Previous:From: Josh BerkusDate: 2011-01-05 19:27:10
Subject: Re: We need to log aborted autovacuums

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