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

Re: New XLOG record indicating WAL-skipping

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New XLOG record indicating WAL-skipping
Date: 2010-01-15 16:01:25
Message-ID: 407d949e1001150801v4bcb088bu8d8c2f863ee13036@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Jan 15, 2010 at 11:28 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> I can see that it
> was required to avoid the flooding from heap_insert(), but we can move
> the XLogSkipLogging() call from heap_insert() to heap_sync().
>
> Attached is an updated patch, doing the above. Am I missing anything?

Hm, perhaps the timing is actually important? What if someone takes a
hot backup while an unlogged operation is in progress. The checkpoint
can occur and finish and the backup finish all while the unlogged
operation is happening. Then the replica can start restoring archived
logs from that point forward. In the original coding it sounds like
the replica would never notice the unlogged operation which might not
have been synced before the start of the initial hot backup.  If the
record occurs when the sync begins then the replica would be in
trouble if the checkpoint begins before the operation completed but
finished after the sync began and the record was emitted.

It seems like it's important that the record occur only after the sync
*completes* to be sure that if the replica doesn't see the record then
it knows the sync was done before its initial backup image was taken.

-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-15 16:03:36
Subject: Re: Streaming replication, loose ends
Previous:From: Leonardo FDate: 2010-01-15 15:48:29
Subject: Re: About "Our CLUSTER implementation is pessimal" patch

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