Re: Checkpointer crashes on slave in 9.4 on windows

On Thu, Jul 24, 2014 at 12:14 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Jul 21, 2014 at 4:16 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
>
> So, this problem was introduced by Heikki's commit,
> 68a2e52bbaf98f136a96b3a0d734ca52ca440a95, to replace XLogInsert slots
> with regular LWLocks. I think the problem here is that the
> initialization code here really doesn't belong in InitXLOGAccess at
> all:
>
> 1. I think WALInsertLocks is just another global variable that needs
> to be saved and restored in EXEC_BACKEND mode and that it therefore
> ought to participate in the save_backend_variables() mechanism instead
> of having its own special-purpose mechanism to save and restore the
> value.

It seems to me that we don't need to save/restore variables that points
to shared memory which we initialize during startup of process. We
do initliaze shared memory during each process start in below call:
SubPostmasterMain()
{
..
..
CreateSharedMemoryAndSemaphores(false, 0);
}

Few another examples of some similar variables are as below:

MultiXactShmemInit()
{
..
OldestMemberMXactId = MultiXactState->perBackendXactIds;
OldestVisibleMXactId = OldestMemberMXactId + MaxOldestSlot;
}

CreateSharedProcArray()
{
..
allProcs = ProcGlobal->allProcs;
allProcs = ProcGlobal->allProcs;
}

However, I think it is better to initialize WALInsertLocks in
XLOGShmemInit()
as we do for other cases and suggested by you in point number-2.

> 2. And I think that the LWLockRegisterTranche call belongs in
> XLOGShmeInit(), so that it's parallel to the other call in
> CreateLWLocks.

Agreed.

Revised patch initialize the WALInsertLocks and call
LWLockRegisterTranche() in XLOGShmemInit() which makes their
initialization similar to what we do at other places.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com