| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Guillaume Lelarge <guillaume(at)lelarge(dot)info>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Weird planner issue on a standby |
| Date: | 2022-10-11 16:27:36 |
| Message-ID: | 20221011162736.cd2h5ajdbhtwdc4l@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 2022-Oct-11, Tom Lane wrote:
> Are there any tables in this query where extremal values of the join
> key are likely to be in recently-added or recently-dead rows? Does
> VACUUM'ing on the primary help?
I remember having an hypothesis, upon getting a report of this exact
problem on a customer system once, that it could be due to killtuple not
propagating to standbys except by FPIs. I do not remember if we proved
that true or not. I do not remember observing that tables were being
read, however.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Lelarge | 2022-10-11 17:42:55 | Re: Weird planner issue on a standby |
| Previous Message | Tom Lane | 2022-10-11 16:17:28 | Re: Weird planner issue on a standby |