On Thu, Mar 16, 2017 at 1:50 PM, Dilip Kumar wrote:
> fixed
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
On Thu, Mar 16, 2017 at 8:26 PM, Emre Hasegeli wrote:
>> Hopefully, this time I got it correct. Since I am unable to reproduce
>> the issue so I will again need your help in verifying the fix.
>
> It is not crashing with the new patch. Thank you.
Thanks for verifying.
--
Regards,
Dilip Kumar
On Thu, Mar 16, 2017 at 8:42 PM, Robert Haas wrote:
> Thanks for confirming. Some review comments on v2:
>
> +if (istate->pagetable)
fixed
>
> Please compare explicitly to InvalidDsaPointer.
>
> +if (iterator->ptbase)
> +ptbase = iterator->ptbase->ptentry;
> +if (iterator->ptp
On Thu, Mar 16, 2017 at 10:56 AM, Emre Hasegeli wrote:
>> Hopefully, this time I got it correct. Since I am unable to reproduce
>> the issue so I will again need your help in verifying the fix.
>
> It is not crashing with the new patch. Thank you.
Thanks for confirming. Some review comments on
> Hopefully, this time I got it correct. Since I am unable to reproduce
> the issue so I will again need your help in verifying the fix.
It is not crashing with the new patch. Thank you.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On Thu, Mar 16, 2017 at 5:14 PM, Dilip Kumar wrote:
> pg_atomic_write_u32_impl(val=0) at generic.h:57, queue =
> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>>> * frame #0: 0x000100caf314 postgres`tbm_prepare_shared_iterate
>>> [inlined] pg_atomic_write_u32_
On Thu, Mar 16, 2017 at 3:52 PM, Emre Hasegeli wrote:
>> * thread #1: tid = 0x51828fd, 0x000100caf314
>> postgres`tbm_prepare_shared_iterate [inlined]
>> pg_atomic_write_u32_impl(val=0) at generic.h:57, queue =
>> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>
> Are you getting the crash with the same test case?
Yes. Here is the new backtrace:
> * thread #1: tid = 0x51828fd, 0x000100caf314
> postgres`tbm_prepare_shared_iterate [inlined] pg_atomic_write_u32_impl(val=0)
> at generic.h:57, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_A
On Thu, Mar 16, 2017 at 5:02 AM, Dilip Kumar wrote:
> After above fix, I am not able to reproduce. Can you give me the
> backtrace of the crash location or the dump?
>
> I am trying on the below commit
>
> commit c5832346625af4193b1242e57e7d13e66a220b38
> Author: Stephen Frost
> Date: Wed Mar 1
On Thu, Mar 16, 2017 at 12:56 AM, Emre Hasegeli wrote:
>> Please verify the fix.
>
> The same test with both of the patches applied still crashes for me.
After above fix, I am not able to reproduce. Can you give me the
backtrace of the crash location or the dump?
I am trying on the below commit
> Please verify the fix.
The same test with both of the patches applied still crashes for me.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 15, 2017 at 10:21 PM, Emre Hasegeli wrote:
>> hasegeli=# create table r2 as select (random() * 3)::int as i from
>> generate_series(1, 100);
>> SELECT 100
>> hasegeli=# create index on r2 using brin (i);
>> CREATE INDEX
>> hasegeli=# analyze r2;
>> ANALYZE
>> hasegeli=# explai
> With my test case, I could not crash even with this patch applied.
> Can you provide your test case?
Yes:
> hasegeli=# create table r2 as select (random() * 3)::int as i from
> generate_series(1, 100);
> SELECT 100
> hasegeli=# create index on r2 using brin (i);
> CREATE INDEX
> hasege
On Wed, Mar 15, 2017 at 10:02 PM, Emre Hasegeli wrote:
> I was testing with the brin correlation patch [1] applied. I cannot
> crash it without the patch either. I am sorry for not testing it
> before. The patch make BRIN selectivity estimation function access
> more information.
>
> [1]
> htt
> This can crash at line:414, if either tuple is invalid memory(but I
> think it's not because we have already accessed this memory in above
> if check) or dtup is invalid (this is also not possible because
> brin_new_memtuple has already accessed this).
I was testing with the brin correlation pat
On Wed, Mar 15, 2017 at 8:11 PM, Emre Hasegeli wrote:
>> * thread #1: tid = 0x5045a8f, 0x00010ae44558
>> postgres`brin_deform_tuple(brdesc=0x7fea3c86a3a8,
>> tuple=0x7fea3c891040) + 40 at brin_tuple.c:414, queue =
>> 'com.apple.main-thread', stop reason = signal SIGUSR1
>> * frame
On Wed, Mar 15, 2017 at 8:51 PM, Dilip Kumar wrote:
>> I can try to provide a test case, if that wouldn't be enough to spot
>> the problem.
>
> Thanks for reporting, I am looking into this. Meanwhile, if you can
> provide the reproducible test case then locating the issue will be
> faster.
After
On Wed, Mar 15, 2017 at 8:11 PM, Emre Hasegeli wrote:
>
> I can try to provide a test case, if that wouldn't be enough to spot
> the problem.
Thanks for reporting, I am looking into this. Meanwhile, if you can
provide the reproducible test case then locating the issue will be
faster.
--
Regard
> I don't know if this is the only problem
> I'll be in this general area today, so will mention if I stumble over
> anything that looks broken.
I was testing the same patch with a large dataset and got a different segfault:
> hasegeli=# explain select * from only mp_notification_20170225 where
On 10 March 2017 at 06:17, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 11:50 AM, Dilip Kumar
> wrote:
> > On Thu, Mar 9, 2017 at 10:02 PM, Dilip Kumar
> wrote:
> >> I slightly modified your query to reproduce this issue.
> >>
> >> explain analyze select * from r1 where value<555;
> >>
> >> Patc
On Thu, Mar 9, 2017 at 11:50 AM, Dilip Kumar wrote:
> On Thu, Mar 9, 2017 at 10:02 PM, Dilip Kumar wrote:
>> I slightly modified your query to reproduce this issue.
>>
>> explain analyze select * from r1 where value<555;
>>
>> Patch is attached to fix the problem.
>
> I forgot to mention the caus
On Thu, Mar 9, 2017 at 10:02 PM, Dilip Kumar wrote:
> I slightly modified your query to reproduce this issue.
>
> explain analyze select * from r1 where value<555;
>
> Patch is attached to fix the problem.
I forgot to mention the cause of the problem.
if (istate->schunkptr < istate->nchunks)
{
On Thu, Mar 9, 2017 at 9:37 PM, Dilip Kumar wrote:
>> =# create table r1(value int);
>> CREATE TABLE
>> =# insert into r1 select (random()*1000)::int from
>> generate_Series(1,100);
>> INSERT 0 100
>> =# create index on r1 using brin(value);
>> CREATE INDEX
>> =# set enable_seqscan=0;
>> S
On Thu, Mar 9, 2017 at 9:17 PM, David Rowley
wrote:
> patch with [1]
>
> =# create table r1(value int);
> CREATE TABLE
> =# insert into r1 select (random()*1000)::int from
> generate_Series(1,100);
> INSERT 0 100
> =# create index on r1 using brin(value);
> CREATE INDEX
> =# set enable_seq
I was just doing some testing on [1] when I noticed that there's a problem
with parallel bitmap index scans scans.
Test case:
patch with [1]
=# create table r1(value int);
CREATE TABLE
=# insert into r1 select (random()*1000)::int from
generate_Series(1,100);
INSERT 0 100
=# create index
25 matches
Mail list logo
