Re: Damage control for planner's get_actual_variable_endpoint() runaway - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Damage control for planner's get_actual_variable_endpoint() runaway
Date
Msg-id CANbhV-GpbgFgucA+QpmH3VwRTTyLSywDxyj69A1Ni6JK1i=K-A@mail.gmail.com
Whole thread Raw
In response to Re: Damage control for planner's get_actual_variable_endpoint() runaway  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Damage control for planner's get_actual_variable_endpoint() runaway
List pgsql-hackers
On Mon, 21 Nov 2022 at 15:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > What we need is a solution that avoids reading an unbounded number of
> > tuples under any circumstances. I previously suggested using
> > SnapshotAny here, but Tom didn't like that. I'm not sure if there are
> > safety issues there or if Tom was just concerned about the results
> > being misleading. Either way, maybe there's some variant on that theme
> > that could work. For instance, could we teach the index scan to stop
> > if the first 100 tuples that it finds are all invisible? Or to reach
> > at most 1 page, or at most 10 pages, or something?
>
> A hard limit on the number of index pages examined seems like it
> might be a good idea.

Good, that is what the patch does.

> > If we don't find a
> > match, we could either try to use a dead tuple, or we could just
> > return false which, I think, would end up using the value from
> > pg_statistic rather than any updated value.
>
> Yeah, the latter seems like the best bet.

Yes, just breaking out of the loop is enough to use the default value.

> If we do install such a thing, should we undo any of the previous
> changes that backed off the reliability of the result?

Not sure.

-- 
Simon Riggs                http://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Allow single table VACUUM in transaction block
Next
From: sirisha chamarthi
Date:
Subject: Re: Catalog_xmin is not advanced when a logical slot is lost