| 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-03-21 00:53:31 |
| Message-ID: | CAApHDvrEEkNnq_Xf5w-KFBhhNnUs3oYhr8EUtQxPy-2JU3hw-A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
David
| Attachment | Content-Type | Size |
|---|---|---|
| debug_partition_prune_failures.patch | text/plain | 3.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-03-21 01:19:44 | Re: Why is parula failing? |
| Previous Message | David Rowley | 2024-03-21 00:45:06 | Re: Flushing large data immediately in pqcomm |