On Mon, Apr 28, 2014 at 2:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Mon, Apr 28, 2014 at 1:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> It's more verbose, it's not actually any more information, and in many
>>> cases it's actively misleading, because what's printed is NOT the real
>>> file name --- it omits segment numbers for instance.  As a particularly
>>> egregious example, in xact_desc_commit() we print a pathname including
>>> MAIN_FORKNUM, which is a flat out lie to the reader, because what will
>>> actually get deleted is all forks.
>> Yeah, technically it's a lie, but ls <copy-and-paste-here>* is pretty
>> handy.  If you format it some other way it's annoying to reformat it.
> Handy for what?  How often do you need to do that?  (And if you do do it,
> how often will you remember that the filename is only approximate?)


I think if you're looking at the output of xact_desc_commit() and you
*don't* know that the filenames are approximate (or at least that you
should Use The Source, Luke) then you're probably in way over your

I have to admit it's been a few years since I've had to play with
WAL_DEBUG, so I don't really remember what I was trying to do.  But I
don't see any real argument that three slash-separated numbers will be
more useful to somebody who has to dig through this than a pathname,
even an approximate pathname, and I think people wanting to figure out
approximately where they need to look to find the data affected by the
WAL record will be pretty common among people decoding WAL records.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to