From: | Shubham Khanna <khannashubham1197(at)gmail(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Log a warning in pg_createsubscriber for max_slot_wal_keep_size |
Date: | 2025-01-14 07:02:04 |
Message-ID: | CAHv8Rj+kEUJ__eW+s1nvwR8VNcJqC428JF_+UhGS-bG8s+t-PQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 10, 2025 at 8:21 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Mon, Jan 6, 2025 at 1:29 PM Hayato Kuroda (Fujitsu)
> <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> >
> > Dear Shubham,
> >
> > Thanks for creating a patch. I have one comment about it.
> >
> > check_publisher() assumed that the SQL function `pg_catalog.current_setting('max_slot_wal_keep_size')`
> > will return the numeric, but it just return the text representation. I.e., if the parameter is
> > set to 10MB, the function returns like below:
> >
> > ```
> > postgres=# SELECT * FROM pg_catalog.current_setting('max_slot_wal_keep_size');
> > current_setting
> > -----------------
> > 10MB
> > (1 row)
> > ```
> >
> > Your patch can work well because atoi() ignores the latter part of the string,
> > e.g., "10MB" is converted to "10", but this is not clean. I suggest either of
> > 1) accepting the value as the string, or 2) using an SQL function pg_size_bytes()
> > to get max_slot_wal_keep_size.
> >
>
> Hi Shubham.
>
> Kuroda-san gave a couple of ideas above and you chose the option 2.
>
> FWIW, recently I've been thinking that option 1 might have been a
> better choice, because:
> i) Using strtoi64 for a GUC value seems to be very rare. I didn't
> find any other examples of what you've ended up doing in v8-0001.
> ii) When you display the value in the pg_log_debug it would be better
> to display the same human-readable format that the user configured
> instead of some possibly huge int64 value
> iii) AFAIK, we only need to check this against "-1". The actual value
> is of no real importance to the patch, so going to extra trouble to
> extract an int64 that we don't care about seems unnecessary
>
I have fixed the given comment and used the string to accept the
value. The v9 version Patch attached at [1] has the changes for the
same.
[1] - https://www.postgresql.org/message-id/CAHv8RjL4MFEDosz9%2BTFmufYCDoNCnyN6PFeSxG6MwsH1ufhZLA%40mail.gmail.com
Thanks and regards,
Shubham Khanna.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2025-01-14 07:03:23 | Re: pg_createsubscriber TAP test wrapping makes command options hard to read. |
Previous Message | Ryohei Takahashi (Fujitsu) | 2025-01-14 06:55:04 | RE: COPY performance on Windows |