From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
---|---|
To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lowering the ever-growing heap->pd_lower |
Date: | 2021-03-09 19:28:19 |
Message-ID: | CAEze2Whr5dQd=r6vFP0AuOJmS60Rc2zTNp3YYBe1QLcpBZCtWg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 9 Mar 2021 at 17:21, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
> For a prior discussion on this topic:
>
> https://www.postgresql.org/message-id/2e78013d0709130606l56539755wb9dbe17225ffe90a%40mail.gmail.com
Thanks for the reference! I note that that thread mentions the
old-style VACUUM FULL as a reason as to why it would be unsafe, which
I believe was removed quite a few versions ago (v9.0).
The only two existing mechanisms that I could find (in the access/heap
directory) that possibly could fail on shrunken line pointer arrays;
being xlog recovery (I do not have enough knowledge on recovery to
determine if that may touch pages that have shrunken line pointer
arrays, or if those situations won't exist due to never using dirtied
pages in recovery) and backwards table scans on non-MVCC snapshots
(which would be fixed in the attached patch).
With regards,
Matthias van de Meent
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Truncate-a-pages-line-pointer-array-when-it-has-t.patch | text/x-patch | 3.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2021-03-09 19:30:21 | Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[] |
Previous Message | Tom Lane | 2021-03-09 19:15:09 | Procedures versus the "fastpath" API |