| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, tharar(at)amazon(dot)com |
| Subject: | Re: Why is parula failing? |
| Date: | 2024-05-13 23:24:53 |
| Message-ID: | CAApHDvqyLF881EvDtXT=ossa0i4ioJBtW2c0Wbouzt5d3HDb5Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 21 Mar 2024 at 13:53, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Thu, 21 Mar 2024 at 12:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > So yeah, if we could have log_autovacuum_min_duration = 0 perhaps
> > that would yield a clue.
>
> FWIW, I agree with your earlier statement about it looking very much
> like auto-vacuum has run on that table, but equally, if something like
> the pg_index record was damaged we could get the same plan change.
>
> We could also do something like the attached just in case we're
> barking up the wrong tree.
I've not seen any recent failures from Parula that relate to this
issue. The last one seems to have been about 4 weeks ago.
I'm now wondering if it's time to revert the debugging code added in
1db689715. Does anyone think differently?
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2024-05-13 23:27:53 | Re: Adding the extension name to EData / log_line_prefix |
| Previous Message | Tom Lane | 2024-05-13 23:11:53 | Re: Adding the extension name to EData / log_line_prefix |