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?)
*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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers