Re: wal_dump output on CREATE DATABASE - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: wal_dump output on CREATE DATABASE
Date
Msg-id 8ba884ad-a7f9-2882-10ed-5aead394d126@2ndquadrant.com
Whole thread Raw
In response to wal_dump output on CREATE DATABASE  (Jean-Christophe Arnu <jcarnu@gmail.com>)
Responses Re: wal_dump output on CREATE DATABASE
List 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


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgbench doc fix
Next
From: Amit Langote
Date:
Subject: Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT