From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>, Hiroyuki Yamada <yamada(at)kokolink(dot)net> |
Subject: | Re: An example of bugs for Hot Standby |
Date: | 2010-01-20 09:45:00 |
Message-ID: | 201001201045.00640.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wednesday 20 January 2010 06:30:28 Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2010-01-20 09:49:58 | Re: An example of bugs for Hot Standby |
Previous Message | Simon Riggs | 2010-01-20 09:40:10 | Re: An example of bugs for Hot Standby |