From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | amit(dot)kapila16(at)gmail(dot)com |
Cc: | alvherre(at)alvh(dot)no-ip(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: A recent message added to pg_upgade |
Date: | 2023-10-30 07:40:45 |
Message-ID: | 20231030.164045.650827844386195435.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Mon, 30 Oct 2023 08:51:18 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in
> I think we can simply change that error message to assert if we want
> to go with the check hook idea of yours. BTW, can we add
> GUC_check_errdetail() with a better message as some of the other check
> function uses? Also, I guess we can add some comments or at least
> refer to the existing comments to explain the reason of such a check.
Definitely. I've attached the following changes.
1. Added GUC_check_errdetail() to the check function.
2. Added a comment to the check function (based on my knowledge about
the feature).
3. Altered the ereport() into Assert() in
InvalidatePossiblyObsoleteSlot(). I considered removing the
!SlotIsLogical() condition since pg_upgrade always sets
max_slot_wal_keep_size to -1, but I left it unchanged.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
inhibit_m_s_w_k_s_during_upgrade_2.txt | text/plain | 3.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2023-10-30 07:46:42 | Re: A recent message added to pg_upgade |
Previous Message | torikoshia | 2023-10-30 07:35:19 | Add new option 'all' to pg_stat_reset_shared() |