On 15 April 2017 at 21:30, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Fri, Apr 14, 2017 at 9:33 PM, Pavan Deolasee <pavan.deola...@gmail.com>
> wrote:
>
>>
>> Since all those offsets fall on a page boundary, my guess is that we're
>> somehow failing to handle a new page correctly.
>>
>> Looking at the patch itself, my feeling is that the following code in
>> src/backend/access/transam/twophase.c might be causing the problem.
>>
>> 1841
>> 1842 /* update nextXid if needed */
>> 1843 if (TransactionIdFollowsOrEquals(maxsubxid,
>> ShmemVariableCache->nextXid))
>> 1844 {
>> 1845 LWLockAcquire(XidGenLock, LW_EXCLUSIVE);
>> 1846 ShmemVariableCache->nextXid = maxsubxid;
>> 1847 TransactionIdAdvance(ShmemVariableCache->nextXid);
>> 1848 LWLockRelease(XidGenLock);
>> 1849 }
>>
>> The function PrescanPreparedTransactions() gets called at the start of the
>> redo recovery and this specific block will get exercised irrespective of
>> whether there are any prepared transactions or not. What I find particularly
>> wrong here is that we are initialising maxsubxid to current value of
>> ShmemVariableCache->nextXid when the function enters, but this block would
>> then again increment ShmemVariableCache->nextXid, when there are no prepared
>> transactions in the system.
>>
>> I wonder if we should do as in attached patch.
>
>
> That solves it for me.
Thanks for patching and testing. I'll review and probably commit tomorrow.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
