Re: Streaming replication status
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, Bruce Momjian <bruce@momjian.us>, Josh Berkus <josh@agliodbs.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-01-15T04:20:41Z
Lists: pgsql-hackers
On Thu, 2010-01-14 at 23:07 -0500, Greg Smith wrote: > pg_last_archived_xlogfile() text: Get the name of the last file the > archive_command [tried to|successfully] archived since the server was > started. If archiving is disabled or no xlog files have become ready > to archive since startup, a blank line will be returned. OK > It is possible for this function to return a result that does not > reflect an actual xlogfile if files are manually added to the server's > archive_status directory. > I'd find this extremely handy as a hook for monitoring scripts that > want to watch the server but don't have access to the filesystem > directly, even given those limitations. I'd prefer to have the "tried > to" version, because it will populate with the name of the troublesome > file it's stuck on even if archiving never gets its first segment > delivered. > > I'd happily write a patch to handle all that if I thought it would be > accepted. I fear that the whole approach will be considered a bit too > hackish and get rejected on that basis though. Not really sure of a > "right" way to handle this though. Anything better is going to be > more complicated because it requires passing more information into the > archiver, with little gain for that work beyond improving the quality > of this diagnostic routine. And I think most people would find what I > described above useful enough. Yes, please write it. It's separate from SR, so will not interfere. -- Simon Riggs www.2ndQuadrant.com