Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

2017-04-18 Thread Michael Paquier
On Tue, Apr 18, 2017 at 7:05 PM, Simon Riggs wrote: > I've added a recheck in ProcessTwoPhaseBuffer() after we acquire the lock. > > If its worth acquiring the lock its worth checking we don't have a race. I see. No objections to that. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

2017-04-18 Thread Simon Riggs
On 18 April 2017 at 09:51, Simon Riggs wrote: > On 17 April 2017 at 16:33, Jeff Janes wrote: >> On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier >> wrote: >>> >>> >>> >>> Jeff, does this patch make the situation better? The fix is rather >>> simple as it just makes sure that the next XID never g

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

2017-04-18 Thread Simon Riggs
On 17 April 2017 at 16:33, Jeff Janes wrote: > On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier > wrote: >> >> >> >> Jeff, does this patch make the situation better? The fix is rather >> simple as it just makes sure that the next XID never gets updated if >> there are no 2PC files. > > > Yes, tha

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

2017-04-17 Thread Michael Paquier
On Tue, Apr 18, 2017 at 12:33 AM, Jeff Janes wrote: > On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier > wrote: >> >> >> >> Jeff, does this patch make the situation better? The fix is rather >> simple as it just makes sure that the next XID never gets updated if >> there are no 2PC files. > > > Y

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

2017-04-17 Thread Jeff Janes
On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier wrote: > > > Jeff, does this patch make the situation better? The fix is rather > simple as it just makes sure that the next XID never gets updated if > there are no 2PC files. > Yes, that fixes the reported case when 2PC are not being used. Than

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

2017-04-16 Thread Michael Paquier
On Sun, Apr 16, 2017 at 6:02 PM, Simon Riggs wrote: > On 15 April 2017 at 21:30, Jeff Janes wrote: >> On Fri, Apr 14, 2017 at 9:33 PM, Pavan Deolasee >> wrote: >> >>> >>> Since all those offsets fall on a page boundary, my guess is that we're >>> somehow failing to handle a new page correctly. >

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

2017-04-16 Thread Simon Riggs
On 15 April 2017 at 21:30, Jeff Janes wrote: > On Fri, Apr 14, 2017 at 9:33 PM, Pavan Deolasee > 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 foll

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

2017-04-15 Thread Jeff Janes
On Fri, Apr 14, 2017 at 9:33 PM, Pavan Deolasee 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 mig

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

2017-04-14 Thread Pavan Deolasee
On Sat, Apr 15, 2017 at 12:53 AM, Jeff Janes wrote: > > In the first statement executed after crash recovery, I sometimes get this > error: > > PANIC: XX000: could not access status of transaction 207580505 > DETAIL: Could not read from file "pg_commit_ts/1EF0" at offset 131072: > Success. > LO

[HACKERS] PANIC in pg_commit_ts slru after crashes

2017-04-14 Thread Jeff Janes
In the first statement executed after crash recovery, I sometimes get this error: PANIC: XX000: could not access status of transaction 207580505 DETAIL: Could not read from file "pg_commit_ts/1EF0" at offset 131072: Success. LOCATION: SlruReportIOError, slru.c:918 STATEMENT: create temporary t