Re: wal_dump output on CREATE DATABASE

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Jean-Christophe Arnu <jcarnu(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: wal_dump output on CREATE DATABASE
Date: 2018-11-02 07:37:13
Message-ID: 8ba884ad-a7f9-2882-10ed-5aead394d126@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On 26/10/2018 15:53, Jean-Christophe Arnu wrote:
> Exemple on CREATE DATABASE (without defining a template database) :
> rmgr: Database    len (rec/tot):     42/    42, tx:        568, lsn:
> 0/01865790, prev 0/01865720, desc: CREATE copy dir 1/1663 to 16384/1663
>
> It comes out (to me) it may be more consistent to use the same template
> than the other operations in pg_waldump.
> I propose to swap the parameters positions for the copy dir operation
> output.
>
> You'll find a patch file included which does the switching job :
> rmgr: Database    len (rec/tot):     42/    42, tx:        568, lsn:
> 0/01865790, prev 0/01865720, desc: CREATE copy dir 1663/1 to 1663/16384

I see your point. I suspect this was mainly implemented that way
because that's how the fields occur in the underlying
xl_dbase_create_rec structure. (But that structure also has the target
location first, so it's not entirely consistent that way either.) We
could switch the fields around in the output, but I wonder whether we
couldn't make the whole thing a bit more readable like this:

desc: CREATE copy dir ts=1663 db=1 to ts=1663 db=16384

or maybe like this

desc: CREATE copy dir (ts/db) 1663/1 to 1663/16384

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-11-02 07:39:07 Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT
Previous Message Fabien COELHO 2018-11-02 07:35:29 Re: pgbench doc fix