Re: Race condition in HEAD, possibly due to PGPROC splitup

On Wed, Dec 14, 2011 at 4:15 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>
> Without the added assert, you'd only notice this if you were running a
> standby slave --- the zero xid results in an assert failure in WAL
> replay on the slave end, which is how I found out about this to start
> with.  But since we've not heard reports of such before, I suspect that
> this is a recently introduced bug; and personally I'd bet money that it
> was the PGXACT patch that broke it.
>

I can reproduce this and will look at it in detail.

BTW, on an unrelated note, I was looking at the way ShmemInitStruct()
is used. It internally uses ShmemAlloc to allocate from shared memory.
ShmemAlloc always MAXALIGN the requested size. But while calculating
the total shared memory requirement, we don't always MAXALIGN
individual structure sizes. One example is KnownAssignedXidsValid, but
I am sure there are other places where the originally computed and the
requested sizes could be different because of alignment.

I wonder if we are just lucky not to hit shared memory size mismatch,
may be because we round up to the block size at the end.

Thanks,
Pavan

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