Re: An example of bugs for Hot Standby - Mailing list pgsql-hackers

From Andres Freund
Subject Re: An example of bugs for Hot Standby
Date
Msg-id 201001201045.00640.andres@anarazel.de
Whole thread Raw
In response to Re: An example of bugs for Hot Standby  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: An example of bugs for Hot Standby  (Simon Riggs <simon@2ndQuadrant.com>)
Re: An example of bugs for Hot Standby  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wednesday 20 January 2010 06:30:28 Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Is there any supported platform with sizeof(sig_atomic_t) <4 - I would
> > doubt so?
> 
> Er ... what?  I believe there are live platforms with sig_atomic_t = char.
> If we're assuming more that's a must-fix.
The reason I have asked is that the code is doing things like:
/** Used by backends when they receive a request to check for buffer pin waits.*/
int
GetStartupBufferPinWaitBufId(void)
{int bufid;
/* use volatile pointer to prevent code rearrangement */volatile PROC_HDR *procglobal = ProcGlobal;
SpinLockAcquire(ProcStructLock);
bufid = procglobal->startupBufferPinWaitBufId;
SpinLockRelease(ProcStructLock);
return bufid;
}

or similar things with LWLockAcquire in a signal handler which strikes me as a 
not that good idea. As at least on x86 reading an integer is atomic the above 
spinlock is pointless. My cross arch experience is barely existing, so...

Andres


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: An example of bugs for Hot Standby
Next
From: Andres Freund
Date:
Subject: Re: An example of bugs for Hot Standby