On Mon, Apr 28, 2014 at 2:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Apr 28, 2014 at 1:20 PM, Tom Lane <tgl@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?)
*shrug*
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
head.
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