Re: [PATCH] add relation and block-level filtering to pg_waldump
| От | David Christensen |
|---|---|
| Тема | Re: [PATCH] add relation and block-level filtering to pg_waldump |
| Дата | |
| Msg-id | CAOxo6X+6OXWprxDMdz0+PC_YkU9_E2fyOOqKfR3XwcD0j2_Z5Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] add relation and block-level filtering to pg_waldump (Thomas Munro <thomas.munro@gmail.com>) |
| Ответы |
Re: [PATCH] add relation and block-level filtering to pg_waldump
|
| Список | pgsql-hackers |
On Mon, Mar 21, 2022 at 4:39 PM Thomas Munro <thomas.munro@gmail.com> wrote:
[snip]
I guess you did this because init fork references aren't really
expected in the WAL, but I think it's more consistent to allow up to
MAX_FORKNUM, not least because your documentation mentions 3 as a
valid value. So I adjust this to allow MAX_FORKNUM. Make sense?
Makes sense, but I think I'd actually thought it was +1 of the max forks, so you give me more credit than I deserve in this case... :-)
Here are some more details I noticed, as a likely future user of this
very handy feature, which I haven't changed, because they seem more
debatable and you might disagree...
1. I think it'd be less surprising if the default value for --fork
wasn't 0... why not show all forks?
Agreed; made it default to all, with the ability to filter down if desired.
2. I think it'd be less surprising if --fork without --relation
either raised an error (like --block without --relation), or were
allowed, with the meaning "show me this fork of all relations".
Agreed; reworked to support the use case of only showing target forks.
3. It seems funny to have no short switch for --fork when everything
else has one... what about -F?
Good idea; I'd hadn't seen capitals in the getopt list so didn't consider them, but I like this.
Enclosed is v6, incorporating these fixes and docs tweaks.
Best,
David
Вложения
В списке pgsql-hackers по дате отправления: