On Thu, Jul 24, 2014 at 12:14 AM, Robert Haas <[email protected]> wrote: > On Mon, Jul 21, 2014 at 4:16 AM, Amit Kapila <[email protected]> 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
fix_checkpointer_crash_on_slave_v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
