On 2020-Aug-17, Alvaro Herrera wrote:
> Hmm, the only explanation I can see for this is that autovacuum managed
> to summarize the range before the test script did it. So the solution
> would simply be to disable autovacuum for the table across the whole
> script.
>
> I'm running the scripts and
On 2020-Aug-15, Tom Lane wrote:
> hyrax's latest report suggests that this patch has issues under
> CLOBBER_CACHE_ALWAYS:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hyrax&dt=2020-08-13%2005%3A09%3A58
>
> Hard to tell whether there's an actual bug there or just test instability,
hyrax's latest report suggests that this patch has issues under
CLOBBER_CACHE_ALWAYS:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hyrax&dt=2020-08-13%2005%3A09%3A58
Hard to tell whether there's an actual bug there or just test instability,
but either way it needs to be resolved.
On 2020-Aug-13, Anastasia Lubennikova wrote:
> Cool.
> This version looks much simpler than mine and passes the tests fine.
Thanks, pushed it to all branches. Thanks for diagnosing this problem!
--
Ălvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On 12.08.2020 22:58, Alvaro Herrera wrote:
On 2020-Aug-12, Alvaro Herrera wrote:
'anyvisible' mode is not required AFAICS; reading the code, I think this
could also hit REINDEX CONCURRENTLY and CREATE INDEX CONCURRENTLY, which
do not use that flag. I didn't try to reproduce it there, though.
A
On 2020-Aug-12, Alvaro Herrera wrote:
> 'anyvisible' mode is not required AFAICS; reading the code, I think this
> could also hit REINDEX CONCURRENTLY and CREATE INDEX CONCURRENTLY, which
> do not use that flag. I didn't try to reproduce it there, though.
> Anyway, I'm going to remove that Assert
On 2020-Aug-11, Alvaro Herrera wrote:
> A much more troubling thought is what happens if the range is
> desummarized, then the index item is used for the summary of a different
> range. Then the index might end up returning corrupt results.
Actually, this is not a concern because the brin tuple'
On 2020-Aug-11, Alvaro Herrera wrote:
> I think this is more complicated than necessary. It seems easier to
> solve this problem by just checking whether the given root pointer is
> set to InvalidOffsetNumber, which is already done in the existing coding
> of heap_get_root_tuples (only they spell
On 2020-Jul-28, Peter Geoghegan wrote:
> On Mon, Jul 27, 2020 at 10:25 AM Alvaro Herrera
> wrote:
> > (I was also considering whether it needs to be a loop to reobtain root
> > tuples, in case a concurrent transaction can create a new item while
> > we're checking that item; but I don't think tha
On 2020-Jul-23, Anastasia Lubennikova wrote:
> This error is caused by the problem with root_offsets array bounds. It
> occurs if a new HOT tuple was inserted after we've collected root_offsets,
> and thus we don't have root_offset for tuple's offnum. Concurrent insertions
> are possible, because
On 2020-Jul-30, Anastasia Lubennikova wrote:
> While testing this fix, Alexander Lakhin spotted another problem. I
> simplified the test case to this:
Ah, good catch. I think a cleaner way to fix this problem is to just
consider the range as not summarized and return NULL from there, as in
the
On 30.07.2020 16:40, Anastasia Lubennikova wrote:
While testing this fix, Alexander Lakhin spotted another problem.
After a few runs, it will fail with "ERROR: corrupted BRIN index:
inconsistent range map"
The problem is caused by a race in page locking in
brinGetTupleForHeapBlock [1]:
(1
On 27.07.2020 20:25, Alvaro Herrera wrote:
On 2020-Jul-27, Anastasia Lubennikova wrote:
Here is the updated version of the fix.
The problem can be reproduced on all supported versions, so I suggest to
backpatch it.
Code slightly changed in v12, so here are two patches: one for versions 9.5
to 1
On Mon, Jul 27, 2020 at 10:25 AM Alvaro Herrera
wrote:
> (I was also considering whether it needs to be a loop to reobtain root
> tuples, in case a concurrent transaction can create a new item while
> we're checking that item; but I don't think that can really happen for
> one individual tuple.)
On 2020-Jul-27, Anastasia Lubennikova wrote:
> Here is the updated version of the fix.
> The problem can be reproduced on all supported versions, so I suggest to
> backpatch it.
> Code slightly changed in v12, so here are two patches: one for versions 9.5
> to 11 and another for versions from 12 t
On 23.07.2020 20:39, Anastasia Lubennikova wrote:
One of our clients caught an error "failed to find parent tuple for
heap-only tuple at (50661,130) in table "tbl'" in PostgreSQL v12.
Steps to reproduce (REL_12_STABLE):
1) Create table with primary key, create brin index, fill table with
some
One of our clients caught an error "failed to find parent tuple for
heap-only tuple at (50661,130) in table "tbl'" in PostgreSQL v12.
Steps to reproduce (REL_12_STABLE):
1) Create table with primary key, create brin index, fill table with
some initial data:
create table tbl (id int primary k
17 matches
Mail list logo
