On Thu, Apr 3, 2025 at 9:30 PM Sami Imseih <samimseih@gmail.com> wrote:
>
> While looking at [1] which introduces a new function called pg_log_query_plan to
> write an explain plan to the log file, I noticed that we currently
> have overloaded
> the meaning of the "pg_log_" prefix.
>
> Currently there is pg_log_backend_memory_contexts which logs memory
> contexts to the log file, but there is also a pg_log_standby_snapshot which
> takes a snapshot of running transactions and writes them to wal, so it has
> nothing to do with writing to the log file.
>
> List of functions
> Schema | Name | Result data type |
> Argument data types | Type
> ------------+--------------------------------+------------------+---------------------+------
> pg_catalog | pg_log_backend_memory_contexts | boolean |
> integer | func
> pg_catalog | pg_log_standby_snapshot | pg_lsn |
> | func
> (3 rows)
>
> Should the pg_log_ prefix strictly refer to functions that write to
> logs?
>
I don't know how strict we should be about this, but your question has
merit and deserves some bike-shedding because the user can get
confused with the term *_log_* in the function name that intends to
write a WAL record for standby_snapshot.
> If so, should we rename
> pg_log_standby_snapshot to something else, such as
> pg_standby_snapshot_xip_to_wal?
>
The other option could be pg_create_standby_snapshot(), which would be
similar to the existing function pg_create_restore_point(). I think we
need to think about backward compatibility if we agree with moving in
this direction.
--
With Regards,
Amit Kapila.
