From: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: error_severity of brin work item |
Date: | 2021-09-24 08:36:16 |
Message-ID: | 20210924083616.GA19556@ahch-to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 10, 2021 at 08:24:50AM -0500, David Steele wrote:
> On 12/1/20 5:25 PM, Justin Pryzby wrote:
> > On Tue, Dec 01, 2020 at 03:57:24PM -0300, Alvaro Herrera wrote:
> >
> > > > Another idea is if perform_work_item() were responsible for discarding
> > > > relations which disappear. Currently it does this, which is racy since it
> > > > holds no lock.
> > >
> > > That has the property that it remains contained in autovacuum.c, but no
> > > other advantages I think.
> >
> > It has the advantage that it moves all the try_open stuff out of brin.
> >
> > I started implementing this, and then realized that the try_open stuff *has* to
> > be in the brin_summarize function, to handle the case that someone passes a
> > non-index, since it's SQL exposed.
> > So maybe we should use your LockOid patch now, and refactor in the future if we
> > add additional work-item types.
>
> Thoughts on this, Álvaro? I can see that the first version of this patch was
> not ideal but the rework seems to have stalled. Since it is a bug perhaps it
> would be better to get something in as Justin suggests?
>
Hi Álvaro,
Do you plan to work on this for this CF?
--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-09-24 08:39:25 | Re: row filtering for logical replication |
Previous Message | Etsuro Fujita | 2021-09-24 08:36:06 | Re: BUG #16583: merge join on tables with different DB collation behind postgres_fdw fails |