| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Naga Appani <nagnrik(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com> |
| Subject: | Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby |
| Date: | 2026-09-21 07:30:59 |
| Message-ID: | arDdM0MrPGgFhNpQ@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Sep 21, 2026 at 10:19:47AM +0300, Heikki Linnakangas wrote:
> Hmm, the window could be very long, there's no guarantee that you'll see a
> MULTIXACT_TRUNCATE_ID record any time soon. And after restart, it'll revert
> back to 0 again. If we can't get a reasonable value at startup, I wonder if
> we should just always show NULL in the standby.
I'd like to think that we should just throw an ERROR in this case with
a ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE, similarly to a lot of the
WAL functions. NULL is useful when for example using such a function
with a JOIN on catalogs, when called for a lot of tuples, but that's
not the case here.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-09-21 07:35:03 | Re: psql: avoid over-reading unterminated prompt escapes |
| Previous Message | wenhui qiu | 2026-09-21 07:30:35 | Re: Assert failure in get_baserel_parampathinfo with lateral UNION ALL |