Home • Explore • Blog • CI
☰



postgresql
3rd chunk of `doc/src/sgml/pgwalinspect.sgml`
2f585c744c790092ea7523aa18554e1acf727837fa65e001000000010000094e

      This example involves a WAL record that only contains one block
      reference, but many WAL records contain several block
      references.  Rows output by
      <function>pg_get_wal_block_info</function> are guaranteed to
      have a unique combination of
      <replaceable>start_lsn</replaceable> and
      <replaceable>block_id</replaceable> values.
     </para>
     <para>
      Much of the information shown here matches the output that
      <function>pg_get_wal_records_info</function> would show, given
      the same arguments.  However,
      <function>pg_get_wal_block_info</function> unnests the
      information from each WAL record into an expanded form by
      outputting one row per block reference, so certain details are
      tracked at the block reference level rather than at the
      whole-record level.  This structure is useful with queries that
      track how individual blocks changed over time.  Note that
      records with no block references (e.g.,
      <literal>COMMIT</literal> WAL records) will have no rows
      returned, so <function>pg_get_wal_block_info</function> may
      actually return <emphasis>fewer</emphasis> rows than
      <function>pg_get_wal_records_info</function>.
     </para>
     <para>
      The <structfield>reltablespace</structfield>,
      <structfield>reldatabase</structfield>, and
      <structfield>relfilenode</structfield> parameters reference
      <link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.<structfield>oid</structfield>,
      <link linkend="catalog-pg-database"><structname>pg_database</structname></link>.<structfield>oid</structfield>, and
      <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relfilenode</structfield>
      respectively.  The <structfield>relforknumber</structfield>
      field is the fork number within the relation for the block
      reference; see <filename>common/relpath.h</filename> for
      details.
     </para>
     <tip>
      <para>
       The <function>pg_filenode_relation</function> function (see
       <xref linkend="functions-admin-dblocation"/>) can help you to
       determine which relation was modified during original execution.
      </para>
     </tip>
     <para>
      It is possible for clients to avoid the overhead of
      materializing block data.  This may
Title: Detailed Explanation of pg_get_wal_block_info Function
Summary
This section provides an in-depth explanation of the pg_get_wal_block_info function in PostgreSQL's pg_walinspect module. It highlights that the function outputs one row per block reference for each WAL record, ensuring unique combinations of start_lsn and block_id. The function offers a more detailed view compared to pg_get_wal_records_info by unnesting information to the block reference level. This makes it particularly useful for tracking changes to individual blocks over time. The output includes various fields referencing database objects and their properties. The text also notes that records without block references (like COMMIT records) won't produce any rows. Additionally, it mentions the possibility for clients to avoid materializing block data for efficiency.