Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-27 Thread Ashutosh Sharma
On Mar 27, 2017 22:25, "Robert Haas" wrote: On Fri, Mar 24, 2017 at 3:49 AM, Amit Kapila wrote: > On Fri, Mar 24, 2017 at 12:25 PM, Ashutosh Sharma wrote: >>> >>> I think it would have been probably okay to use *int* for

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-27 Thread Robert Haas
On Fri, Mar 24, 2017 at 3:49 AM, Amit Kapila wrote: > On Fri, Mar 24, 2017 at 12:25 PM, Ashutosh Sharma > wrote: >>> >>> I think it would have been probably okay to use *int* for ntuples as >>> that matches with what you are actually assigning in

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-27 Thread Ashutosh Sharma
>> >> >> >> I think it would have been probably okay to use *int* for ntuples as >> >> that matches with what you are actually assigning in the function. >> > >> > okay, corrected it. Attached is newer version of patch. >> > >> >> Thanks, this version looks good to me. > > > It solves the problem

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-27 Thread Jeff Janes
On Fri, Mar 24, 2017 at 12:49 AM, Amit Kapila wrote: > On Fri, Mar 24, 2017 at 12:25 PM, Ashutosh Sharma > wrote: > >> > >> I think it would have been probably okay to use *int* for ntuples as > >> that matches with what you are actually assigning

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-24 Thread Amit Kapila
On Fri, Mar 24, 2017 at 12:25 PM, Ashutosh Sharma wrote: >> >> I think it would have been probably okay to use *int* for ntuples as >> that matches with what you are actually assigning in the function. > > okay, corrected it. Attached is newer version of patch. > Thanks,

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-24 Thread Ashutosh Sharma
>>> > I think this will work, but not sure if there is a merit to deviate >>> > from what btree does to handle this case. One thing I find slightly >>> > awkward in hash_xlog_vacuum_get_latestRemovedXid() is that you are >>> > using a number of tuples registered as part of fixed data >>> >

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-23 Thread Amit Kapila
On Thu, Mar 23, 2017 at 4:26 PM, Ashutosh Sharma wrote: > On Thu, Mar 23, 2017 at 9:17 AM, Amit Kapila wrote: >> >> On Thu, Mar 23, 2017 at 8:43 AM, Amit Kapila wrote: >> > >> > I think this will work, but not sure if

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-23 Thread Ashutosh Sharma
On Thu, Mar 23, 2017 at 9:17 AM, Amit Kapila wrote: > > On Thu, Mar 23, 2017 at 8:43 AM, Amit Kapila wrote: > > On Wed, Mar 22, 2017 at 3:39 PM, Ashutosh Sharma > > wrote: > >> Hi, > >> > >> On Wed, Mar 22, 2017 at 8:41

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-22 Thread Amit Kapila
On Thu, Mar 23, 2017 at 8:43 AM, Amit Kapila wrote: > On Wed, Mar 22, 2017 at 3:39 PM, Ashutosh Sharma > wrote: >> Hi, >> >> On Wed, Mar 22, 2017 at 8:41 AM, Amit Kapila wrote: >> >> To fix this, I think we should pass

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-22 Thread Amit Kapila
On Wed, Mar 22, 2017 at 3:39 PM, Ashutosh Sharma wrote: > Hi, > > On Wed, Mar 22, 2017 at 8:41 AM, Amit Kapila wrote: > > To fix this, I think we should pass 'REGBUF_KEEP_DATA' while > registering the buffer. Something like this, > > -

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-22 Thread Ashutosh Sharma
Hi, On Wed, Mar 22, 2017 at 8:41 AM, Amit Kapila wrote: > On Tue, Mar 21, 2017 at 11:49 PM, Ashutosh Sharma > wrote: >>> >>> I can confirm that that fixes the seg faults for me. >> >> Thanks for confirmation. >> >>> >>> Did you mean you couldn't

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-21 Thread Amit Kapila
On Tue, Mar 21, 2017 at 11:49 PM, Ashutosh Sharma wrote: >> >> I can confirm that that fixes the seg faults for me. > > Thanks for confirmation. > >> >> Did you mean you couldn't reproduce the problem in the first place, or that >> you could reproduce it and now the patch

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-21 Thread Ashutosh Sharma
Hi Jeff, > > I can confirm that that fixes the seg faults for me. Thanks for confirmation. > > Did you mean you couldn't reproduce the problem in the first place, or that > you could reproduce it and now the patch fixes it? If the first of those, I > forget to say you do have to wait for hot

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-21 Thread Jeff Janes
On Tue, Mar 21, 2017 at 4:00 AM, Ashutosh Sharma wrote: > Hi Jeff, > > On Tue, Mar 21, 2017 at 1:54 PM, Amit Kapila > wrote: > > On Tue, Mar 21, 2017 at 1:28 PM, Jeff Janes > wrote: > >> Against an unmodified HEAD (17fa3e8),

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-21 Thread Ashutosh Sharma
Hi Jeff, On Tue, Mar 21, 2017 at 1:54 PM, Amit Kapila wrote: > On Tue, Mar 21, 2017 at 1:28 PM, Jeff Janes wrote: >> Against an unmodified HEAD (17fa3e8), I got a segfault in the hot standby. >> > > I think I see the problem in

Re: [HACKERS] segfault in hot standby for hash indexes

2017-03-21 Thread Amit Kapila
On Tue, Mar 21, 2017 at 1:28 PM, Jeff Janes wrote: > Against an unmodified HEAD (17fa3e8), I got a segfault in the hot standby. > I think I see the problem in hash_xlog_vacuum_get_latestRemovedXid(). It seems to me that we are using different block_id for registering the

[HACKERS] segfault in hot standby for hash indexes

2017-03-21 Thread Jeff Janes
Against an unmodified HEAD (17fa3e8), I got a segfault in the hot standby. Using the attached files, I start the test case like this: nice sh do_nocrash_sr.sh >& do_nocrash_sr.err & And start the replica like: rm -r /tmp/data2_replica/ ; psql -p 9876 -c "select