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 ntuples as
>>> that matches with what you are actually assigning in the fu
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 the function.
>>
>> okay, corrected it. Attached
>> >>
>> >> 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 f
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 in the function.
> >
> > okay, corrected it. Att
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, this version looks good t
>>> > 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
>>> > (xl_ha
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 there is a merit to deviate
>> > from what btree does to handle this case. O
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 AM, Amit Kapila
> >> wrote:
> >>
> >> To fix this, I think we should pass
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 'REGBUF_KEEP_DATA' while
>> registering the buffer. Something like this,
>>
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,
>
> - XLogRegisterBuffer(0, buf, REGBUF_STAND
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 reproduce the problem in the first place, or that
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 fixes it? If the first o
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 st
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), I got a segfault in the hot
> standby.
> >>
> >
> > I think I see the
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 hash_xlog_vacuum_get_latestRemovedXid().
> It seems to me that we ar
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 deleted items in xlog XLO
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 pg_create_physical_replication_sl
17 matches
Mail list logo