On 7/2/25 22:24, Michael Paquier wrote:
On Fri, Apr 25, 2025 at 01:50:16PM +, David Steele wrote:
That was my expectation. I just had some time to get this patch updated so
took the opportunity.
And well, now is the time to get this patch done. So, applied after
an extra lookup, with a sw
On Fri, Apr 25, 2025 at 01:50:16PM +, David Steele wrote:
> That was my expectation. I just had some time to get this patch updated so
> took the opportunity.
And well, now is the time to get this patch done. So, applied after
an extra lookup, with a switch from UINT_MAX to PG_UINT32_MAX in t
On 4/24/25 20:12, Michael Paquier wrote:
On Thu, Apr 24, 2025 at 03:34:29PM +, David Steele wrote:
Having said that, I think these tests are awfully expensive for a single
GUC. Unit tests would definitely be preferable but that's not an option for
GUCs, so far as I know.
On my laptop, 003
On Thu, Apr 24, 2025 at 03:34:29PM +, David Steele wrote:
> Done. This means there are no commas in the upper bound but I don't think
> it's a big deal and it more closely matches other GUC messages.
One thing that I have double-checked is if we have similar messages
for GUCs that are defined
On 2/14/25 02:42, Michael Paquier wrote:
On Fri, Jan 24, 2025 at 01:36:45PM +, David Steele wrote:
+ timeline = strtoull(*newval, &endp, 0);
+
+ if (*endp != '\0' || errno == EINVAL || errno == ERANGE)
{
GUC_check_errdetail
On Fri, Jan 24, 2025 at 01:36:45PM +, David Steele wrote:
> I attached the wrong patch. Oops!
Thanks for the new patch.
> + timeline = strtoull(*newval, &endp, 0);
> +
> + if (*endp != '\0' || errno == EINVAL || errno == ERANGE)
> {
>
On 1/24/25 01:44, Michael Paquier wrote:
On Thu, Jan 23, 2025 at 02:53:39PM +, David Steele wrote:
I discovered this while testing on Postgres versions < 12 where
The tests are probably excessive but I needed something to show that the
verification works as expected.
Even with your patch,
On Thu, Jan 23, 2025 at 02:53:39PM +, David Steele wrote:
> Currently check_recovery_target_timeline() converts any value that is not
> current, latest, or a valid integer to 0. So for example:
>
> recovery_target_timeline = 'currrent'
>
> results in the following error:
>
> FATAL: 22023: r
