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 | Resend email |
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
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 |