| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)bowt(dot)ie>, David Rowley <dgrowley(at)gmail(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Subject: | Re: Trigger more frequent autovacuums of heavy insert tables |
| Date: | 2025-02-25 20:05:22 |
| Message-ID: | Z74igqjAf5H58Hl_@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 25, 2025 at 01:52:28PM -0500, Robert Haas wrote:
> Given that users could manually update the catalog, we have to be able
> to tolerate bad data in the catalogs without the world ending. If that
> code has to exist anyway, then it's not mandatory to cap. On the other
> hand, there's no great virtue in refusing to correct data that we know
> to be wrong. Unless there is some other consideration which makes one
> way better than the other, this feels like author's choice.
Maybe the most conservative choice is to simply follow the example of
surrounding code. If it's careful to cap relallvisible to relpages, also
have it cap relallfrozen. If not, don't. *shrug*
In any case, I don't want to hold up this patch on this relatively minor
point. This seems like something we could pretty easily change in the
future if needed.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2025-02-25 20:23:31 | Re: Log connection establishment timings |
| Previous Message | Ekaterina Sokolova | 2025-02-25 19:44:33 | Proposal: Limitations of palloc inside checkpointer |