| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [BUG] Error in BRIN summarization |
| Date: | 2020-07-28 19:18:09 |
| Message-ID: | CAH2-Wz=eop3qZyL0DrsJnjnZA9ifSUKa4PsHekO=rEUfs0kFEg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 27, 2020 at 10:25 AM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> 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.)
I wonder if something like that is the underlying problem in a recent
problem case involving a "REINDEX index
pg_class_tblspc_relfilenode_index" command that runs concurrently with
the regression tests:
https://postgr.es/m/CAH2-WzmBxu4o=pMsniur+bwHqCGCmV_AOLkuK6BuU7ngA6evqw@mail.gmail.com
We see a violation of the HOT invariant in this case, though only for
a system catalog index, and only in fairly particular circumstances
involving concurrency.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2020-07-28 19:39:19 | Re: display offset along with block number in vacuum errors |
| Previous Message | Mahendra Singh Thalor | 2020-07-28 19:05:17 | Re: display offset along with block number in vacuum errors |