pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Arseny Sher <a.sher@postgrespro.ru>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Alexander Lakhin <a.lakhin@postgrespro.ru>
Subject: Re: Too rigorous assert in reorderbuffer.c
Date: Thu, 19 Dec 2019 19:30:10 +0300
Message-ID: <87lfr8wa5p.fsf@ars-thinkpad> (raw)
In-Reply-To: <87r2c8xocq.fsf@ars-thinkpad>
References: <87tvh9xa0g.fsf@ars-thinkpad>
	<20190212220022.GA16807@alvherre.pgsql>
	<87r2c8xocq.fsf@ars-thinkpad>


Arseny Sher <a.sher@postgrespro.ru> writes:

> I'm sorry to bother you with this again, but due to new test our
> internal buildfarm revealed that ajacent assert on cmin is also lie. You
> see, we can't assume cmin is stable because the same key (relnode, tid)
> might refer to completely different tuples if tuple was inserted by
> aborted subxact, immeditaly reclaimed and then space occupied by another
> one. Fix is attached.
>
> Technically this might mean a user-facing bug, because we only pick the
> first cmin which means we might get visibility wrong, allowing to see
> some version too early (i.e real cmin of tuple is y, but decoding thinks
> it is x, and x < y). However, I couldn't quickly make up an example
> where this would actually lead to bad consequences. I tried to create
> such extra visible row in pg_attribute, but that's ok because loop in
> RelationBuildTupleDesc spins exactly natts times and ignores what is
> left unscanned. It is also ok with pg_class, because apparently
> ScanPgRelation also fishes out the (right) first tuple and doesn't check
> for duplicates appearing later in the scan. Maybe I just haven't tried
> hard enough though.

This issue still exists, it would be nice to fix it...

--
Arseny Sher
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company





view thread (12+ messages)

Message-ID: <87lfr8wa5p.fsf@ars-thinkpad>
Permalink:  ../87lfr8wa5p.fsf@ars-thinkpad/
Also on:    postgresql.org/message-id/87lfr8wa5p.fsf@ars-thinkpad

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: a.sher@postgrespro.ru, alvherre@2ndquadrant.com, a.lakhin@postgrespro.ru
  Subject: Re: Too rigorous assert in reorderbuffer.c
  In-Reply-To: <87lfr8wa5p.fsf@ars-thinkpad>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox