Re: New XLOG record indicating WAL-skipping - Mailing list pgsql-hackers

From Greg Stark
Subject Re: New XLOG record indicating WAL-skipping
Date
Msg-id 407d949e1001150801v4bcb088bu8d8c2f863ee13036@mail.gmail.com
Whole thread Raw
In response to Re: New XLOG record indicating WAL-skipping  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: New XLOG record indicating WAL-skipping  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Fri, Jan 15, 2010 at 11:28 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.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


pgsql-hackers by date:

Previous
From: Leonardo F
Date:
Subject: Re: About "Our CLUSTER implementation is pessimal" patch
Next
From: Tom Lane
Date:
Subject: Re: Streaming replication, loose ends