On Fri, 25 Mar 2022 at 08:55, Thomas Munro wrote:
> On Fri, Mar 25, 2022 at 1:43 PM Japin Li wrote:
>> + printf(_(" -x, --xid=XID only show records with
>> transaction ID XID\n"));
>>
>> I think the description of transaction ID is enough, IIUC, XID is use in
>> core,
>>
On Fri, Mar 25, 2022 at 1:43 PM Japin Li wrote:
> + printf(_(" -x, --xid=XID only show records with transaction
> ID XID\n"));
>
> I think the description of transaction ID is enough, IIUC, XID is use in core,
> which means transaction ID.
The mention of "XID" corresponds to XID
On Fri, 25 Mar 2022 at 05:11, Thomas Munro wrote:
> Cool.
>
> I had another thought while changing that (and also re-alphabetising):
> Why don't we switch to -B for --block and -R for --relation? I
> gather you used -k and -l because -b and -r were already taken, but
> since we already
> On Mar 24, 2022, at 4:12 PM, Thomas Munro wrote:
>
> On Fri, Mar 25, 2022 at 1:43 AM David Christensen
> wrote:
On Mar 24, 2022, at 6:43 AM, Thomas Munro wrote:
>>> On Fri, Mar 25, 2022 at 12:26 AM Thomas Munro
>>> wrote:
> On Fri, Mar 25, 2022 at 12:01 AM Peter Eisentraut
On Fri, Mar 25, 2022 at 1:43 AM David Christensen
wrote:
> > On Mar 24, 2022, at 6:43 AM, Thomas Munro wrote:
> > On Fri, Mar 25, 2022 at 12:26 AM Thomas Munro
> > wrote:
> >>> On Fri, Mar 25, 2022 at 12:01 AM Peter Eisentraut
> >>> wrote:
> >>> Or even: Why are we exposing fork *numbers*
> On Mar 24, 2022, at 6:43 AM, Thomas Munro wrote:
>
> On Fri, Mar 25, 2022 at 12:26 AM Thomas Munro wrote:
>>> On Fri, Mar 25, 2022 at 12:01 AM Peter Eisentraut
>>> wrote:
>>> Or even: Why are we exposing fork *numbers* in the user interface?
>>> Even low-level tools such as pageinspect
On Fri, Mar 25, 2022 at 12:26 AM Thomas Munro wrote:
> On Fri, Mar 25, 2022 at 12:01 AM Peter Eisentraut
> wrote:
> > Or even: Why are we exposing fork *numbers* in the user interface?
> > Even low-level tools such as pageinspect use fork *names* in their
> > interface.
>
> I wondered about
On Fri, Mar 25, 2022 at 12:01 AM Peter Eisentraut
wrote:
> Or even: Why are we exposing fork *numbers* in the user interface?
> Even low-level tools such as pageinspect use fork *names* in their
> interface.
I wondered about that but thought it seemed OK for such a low level
tool. It's a fair
On 24.03.22 11:57, Peter Eisentraut wrote:
On 23.03.22 23:54, Thomas Munro wrote:
That's because ForkNum is a signed type. You will probably succeed if
you use "%d" instead.
Erm, is that really OK? C says "Each enumerated type shall be
compatible with char, a signed integer type, or an
On 23.03.22 23:54, Thomas Munro wrote:
That's because ForkNum is a signed type. You will probably succeed if
you use "%d" instead.
Erm, is that really OK? C says "Each enumerated type shall be
compatible with char, a signed integer type, or an
unsigned integer type. The choice of type is
On Tue, Mar 22, 2022 at 12:01 PM David Christensen
wrote:
> Enclosed is v6, incorporating these fixes and docs tweaks.
Thanks!
I made a couple of minor changes in the docs, to wit: fixed
copy/paste-o "-F block" -> "-F fork", fork names didn't have initial
caps elsewhere, tablespace is better
On 2022-03-24 11:54:15 +1300, Thomas Munro wrote:
> Erm, is that really OK? C says "Each enumerated type shall be
> compatible with char, a signed integer type, or an
> unsigned integer type. The choice of type is implementation-defined,
> but shall be capable of representing the values of all
On Thu, Mar 24, 2022 at 9:53 AM Peter Eisentraut
wrote:
> On 21.03.22 05:55, Thomas Munro wrote:
> > [04:30:50.630] pg_waldump.c:963:26: error: format ‘%u’ expects
> > argument of type ‘unsigned int *’, but argument 3 has type ‘ForkNumber
> > *’ [-Werror=format=]
> > [04:30:50.630] 963 | if
On 21.03.22 05:55, Thomas Munro wrote:
[04:30:50.630] pg_waldump.c:963:26: error: format ‘%u’ expects
argument of type ‘unsigned int *’, but argument 3 has type ‘ForkNumber
*’ [-Werror=format=]
[04:30:50.630] 963 | if (sscanf(optarg, "%u",
_by_relation_forknum) != 1 ||
[04:30:50.630] | ~^
On Mon, Mar 21, 2022 at 4:39 PM Thomas Munro 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
On Tue, Mar 22, 2022 at 6:14 AM David Christensen
wrote:
> Updated to include the V3 fixes as well as the unsigned int/enum fix.
Hi David,
I ran this though pg_indent and adjusted some remaining
non-project-style whitespace, and took it for a spin. Very minor
comments:
pg_waldump: error:
Updated to include the V3 fixes as well as the unsigned int/enum fix.
>
v4-0001-Add-additional-filtering-options-to-pg_waldump.patch
Description: Binary data
On Sun, Mar 20, 2022 at 11:56 PM Thomas Munro
wrote:
> On Mon, Mar 21, 2022 at 4:36 PM Thomas Munro
> wrote:
> > On Sat, Feb 26, 2022 at 7:58 AM David Christensen
> > wrote:
> > > Attached is V2 with additional feedback from this email, as well as
> the specification of the
> > > ForkNumber
On Mon, Mar 21, 2022 at 4:36 PM Thomas Munro wrote:
> On Sat, Feb 26, 2022 at 7:58 AM David Christensen
> wrote:
> > Attached is V2 with additional feedback from this email, as well as the
> > specification of the
> > ForkNumber and FPW as specifiable options.
>
> Trivial fixup needed after
On Sat, Feb 26, 2022 at 7:58 AM David Christensen
wrote:
> Attached is V2 with additional feedback from this email, as well as the
> specification of the
> ForkNumber and FPW as specifiable options.
Trivial fixup needed after commit 3f1ce973.
From 39e683756e718904b3a8651508cb1e2198a852e4 Mon
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi
I am glad to find this patch here because it helps with
Bharath Rupireddy writes:
> On Fri, Feb 25, 2022 at 12:36 AM David Christensen
> wrote:
>>
>> Greetings,
>>
>> This patch adds the ability to specify a RelFileNode and optional BlockNum
>> to limit output of
>> pg_waldump records to only those which match the given criteria. This
>> should
On Fri, Feb 25, 2022 at 7:08 AM Japin Li wrote:
>
> On Fri, 25 Feb 2022 at 20:48, David Christensen <
> david.christen...@crunchydata.com> wrote:
> >> Cool. I think we can report an error instead of reading wal files,
> >> if the tablespace, database, or relation is invalid. Does there any
>
On Fri, Feb 25, 2022 at 7:33 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> Thanks for the patch. This is not adding something that users can't do
> right now, but definitely improves the usability of the pg_waldump as
> it avoids external filterings. Also, it can give
On Fri, Feb 25, 2022 at 12:36 AM David Christensen
wrote:
>
> Greetings,
>
> This patch adds the ability to specify a RelFileNode and optional BlockNum to
> limit output of
> pg_waldump records to only those which match the given criteria. This should
> be more performant
> than `pg_waldump |
On Fri, 25 Feb 2022 at 20:48, David Christensen
wrote:
>> Cool. I think we can report an error instead of reading wal files,
>> if the tablespace, database, or relation is invalid. Does there any
>> WAL record that has invalid tablespace, database, or relation OID?
>
> The only sort of
> Cool. I think we can report an error instead of reading wal files,
> if the tablespace, database, or relation is invalid. Does there any
> WAL record that has invalid tablespace, database, or relation OID?
The only sort of validity check we could do here is range checking for the
underlying
On Fri, 25 Feb 2022 at 03:02, David Christensen
wrote:
> Greetings,
>
> This patch adds the ability to specify a RelFileNode and optional BlockNum to
> limit output of
> pg_waldump records to only those which match the given criteria. This should
> be more performant
> than `pg_waldump |
Added to commitfest as:
https://commitfest.postgresql.org/37/3565/
On Thu, Feb 24, 2022 at 11:06 AM David Christensen
wrote:
> This patch adds the ability to specify a RelFileNode and optional BlockNum to
> limit output of
> pg_waldump records to only those which match the given criteria. This should
> be more performant
> than `pg_waldump | grep` as well as
Greetings,
This patch adds the ability to specify a RelFileNode and optional BlockNum to
limit output of
pg_waldump records to only those which match the given criteria. This should
be more performant
than `pg_waldump | grep` as well as more reliable given specific variations in
output style
31 matches
Mail list logo
