| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: regdatabase |
| Date: | 2025-05-30 20:59:39 |
| Message-ID: | aDocO6XGgLU8NRTa@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 30, 2025 at 04:55:58PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
>> For now, I've just added another case block for REGDATABASEOID to match the
>> others. If there are problems with non-pinned objects being considered
>> shippable, it's not really the fault of this patch. Also, from reading
>> around [0], I get the idea that "shippability" might just mean that the
>> same object _probably_ exists on the remote server. Plus, there seems to
>> be very few use-cases for shipping reg* values in the first place. But
>> even after reading lots of threads, code, and docs, I'm still not sure I
>> fully grasp all the details here.
>
> It's all quite squishy, unfortunately, because shippability is a
> heuristic rather than something we can determine with certainty
> (at reasonable cost, anyway). But I agree with treating regdatabase
> the same as the other reg* types, at least until someone shows up
> with a counterexample.
Got it, thanks for confirming.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2025-05-30 21:16:07 | Re: Correcting freeze conflict horizon calculation |
| Previous Message | Tom Lane | 2025-05-30 20:55:58 | Re: regdatabase |