From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16329: Valgrind detects an invalid read when building a gist index with buffering |
Date: | 2020-10-12 20:03:10 |
Message-ID: | 3249980.1602532990@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> writes:
>> I investigated this issue under Valgrind and found that in v13 it is no
>> longer detected and the patch in the discussion above is no longer needed.
> I want to correct myself that issue is no longer detected in master, but
> not in 13stable. Everything else is without changes.
I went to try to evaluate this, and found that with or without your
proposed testing addition, the code coverage for gistbuildbuffers.c
remains at 0.0%. The previous testing patch is the same. So that's
why the issue is "no longer detectable": the code is not reached in
HEAD.
After some investigation, I found that commit 16fa9b2b3 broke this:
if the opclass(es) have GIST_SORTSUPPORT_PROC, then the buffering
code will not be used, no matter what the index's options say.
This seems like a spectacularly bad idea from a testing standpoint,
even if it's the right thing for most users. Basically, it is now
impossible to test buffering builds at all, unless you find a gist
opclass that lacks GIST_SORTSUPPORT_PROC. Although there are a
few candidates to pick from, someone could at any time add such
a support proc and silently break your testing plan, just as
16fa9b2b3 did by adding such a proc to point_ops.
So I think 16fa9b2b3 has to be reconsidered: if we have a
buffering=on index parameter, we must go with that independently
of the availability of sort support procs. Unless I hear very
loud squawks very quickly, I'll go make that happen.
(I observe that 16fa9b2b3 also failed to update the relevant
documentation in 65.4.1...)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | adam grech | 2020-10-12 21:23:30 | Re: BUG #16667: COMMIT AND CHAIN does not udpates database metrics ie. xact_commit |
Previous Message | Tom Lane | 2020-10-12 18:12:15 | Re: Identity column behavior discrepancies when inserting one or many rows |