Re: Hot Standby (commit fest version - v5)

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot Standby (commit fest version - v5)
Date: 2008-11-20 06:33:22
Message-ID: 2e78013d0811192233g4eb81531mfb8bd21c797317a6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 1, 2008 at 10:02 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> Hot Standby patch, including all major planned features.
>
>
While experimenting with the patch, I noticed that sometimes the archiver
process indefinitely waits for WALInsertLock. I haven't spent much time
debugging that, but the following chunk clearly seems to be buggy. The
WALInsertLock is not released if (leavingArchiveRecovery == true).

--- 6565,6592 ----
}
}

! if (leavingArchiveRecovery)
! checkPoint.redo = GetRedoLocationForArchiveCheckpoint();
! else
{
! /*
! * Compute new REDO record ptr = location of next XLOG record.
! *
! * NB: this is NOT necessarily where the checkpoint record itself
will be,
! * since other backends may insert more XLOG records while we're off
doing
! * the buffer flush work. Those XLOG records are logically after
the
! * checkpoint, even though physically before it. Got that?
! */
! checkPoint.redo = GetRedoLocationForCheckpoint();

! /*
! * Now we can release WAL insert lock, allowing other xacts to
proceed
! * while we are flushing disk buffers.
! */
! LWLockRelease(WALInsertLock);
}

/*
* If enabled, log checkpoint start. We postpone this until now so as
not
* to log anything if we decided to skip the checkpoint.
*/

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-11-20 07:25:15 Re: pg_upgrade: How to deal with toast
Previous Message Pavan Deolasee 2008-11-20 06:21:37 Re: Hot Standby (commit fest version - v5)