Re: pg_walinspect - a new extension to get raw WAL data and WAL stats

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: ashu(dot)coek88(at)gmail(dot)com
Cc: sfrost(at)snowman(dot)net, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, pgsql(at)j-davis(dot)com, robertmhaas(at)gmail(dot)com, andrew(at)dunslane(dot)net, stark(at)mit(dot)edu, schneider(at)ardentperf(dot)com, bruce(at)momjian(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org, satyanarlapuram(at)gmail(dot)com, marvin_liang(at)qq(dot)com, actyzhang(at)outlook(dot)com
Subject: Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
Date: 2022-03-17 05:18:38
Message-ID: 20220317.141838.2298774060802316987.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 16 Mar 2022 20:49:12 +0530, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote in
> I can see that the pg_get_wal_records_info function shows the details
> of the WAL record whose existence is beyond the user specified
> stop/end lsn pointer. See below:
>
> ashu(at)postgres=# select * from pg_get_wal_records_info('0/01000028',
> '0/01000029');
> -[ RECORD 1 ]----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> start_lsn | 0/1000028
> end_lsn | 0/100009F
> prev_lsn | 0/0
...
> record_length | 114
...
> In this case, the end lsn pointer specified by the user is
> '0/01000029'. There is only one WAL record which starts before this
> specified end lsn pointer whose start pointer is at 01000028, but that
> WAL record ends at 0/100009F which is way beyond the specified end
> lsn. So, how come we are able to display the complete WAL record info?
> AFAIU, end lsn is the lsn pointer where you need to stop reading the
> WAL data. If that is true, then there exists no valid WAL record
> between the start and end lsn in this particular case.

You're right considering how pg_waldump behaves. pg_waldump works
almost the way as you described above. The record above actually ends
at 1000099 and pg_waldump shows that record by specifying -s 0/1000028
-e 0/100009a, but not for -e 0/1000099.

# I personally think the current behavior is fine, though..

It still suggests unspecifiable end-LSN..

> select * from pg_get_wal_records_info('4/4B28EB68', '4/4C000060');
> ERROR: cannot accept future end LSN
> DETAIL: Last known WAL LSN on the database system is 4/4C000060.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-03-17 05:59:26 Re: Out-of-tree certificate interferes ssltest
Previous Message Corey Huinker 2022-03-17 04:04:03 Re: Window Function "Run Conditions"