Combine pg_walinspect till_end_of_wal functions with others
От | Bharath Rupireddy |
---|---|
Тема | Combine pg_walinspect till_end_of_wal functions with others |
Дата | |
Msg-id | CALj2ACU0_q-o4DSweyaW9NO1KBx-QkN6G_OzYQvpjf3CZVASkg@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Combine pg_walinspect till_end_of_wal functions with others
|
Список | pgsql-hackers |
Hi, In a recent discussion [1], Michael Paquier asked if we can combine pg_walinspect till_end_of_wal functions with other functions pg_get_wal_records_info and pg_get_wal_stats. The code currently looks much duplicated and the number of functions that pg_walinspect exposes to the users is bloated. The point was that the till_end_of_wal functions determine the end LSN and everything else that they do is the same as their counterpart functions. Well, the idea then was to keep things simple, not clutter the APIs, have better and consistent user-inputted end_lsn validations at the cost of usability and code redundancy. However, now I tend to agree with the feedback received. I'm attaching a patch doing the $subject with the following behavior: 1. If start_lsn is NULL, error out/return NULL. 2. If end_lsn isn't specified, default to NULL, then determine the end_lsn. 3. If end_lsn is specified as NULL, then determine the end_lsn. 4. If end_lsn is specified as non-NULL, then determine if it is greater than start_lsn if yes, go ahead do the job, otherwise error out. Another idea is to convert till_end_of_wal flavors to SQL-only functions and remove the c code from pg_walinspect.c. However, I prefer $subject and completely remove till_end_of_wal flavors for better usability in the long term. Thoughts? [1] https://www.postgresql.org/message-id/CALj2ACV-WBN%3DEUgUPyYOGitp%2Brn163vMnQd%3DHcWrnKt-uqFYFA%40mail.gmail.com -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: