On 04/28/2014 04:51 PM, Tom Lane wrote:
Heikki Linnakangas <hlinnakan...@vmware.com> writes:
On 04/28/2014 03:29 PM, Christoph Berg wrote:
Re: Heikki Linnakangas 2014-04-28 <535e09b7.3090...@vmware.com>
I'm using it in the pg_rewind tool. It needs to know how to map relfilenodes
to physical files.
Isn't pg_rewind so low-level server-close that it needs tons of server
headers anyway, including one that would still have relpath()? We are
talking here about what headers pure client apps need.
It knows how to decode WAL, similar to pg_xlogdump. And it knows about
the data directory layout, in particular, how relfilenodes are mapped to
physical files. Those are the low-level parts. So, it certainly needs
some server headers, but I wouldn't call it tons.
I'm not even worried about which headers this program uses. What I'm
worried about is that you've got CATALOG_VERSION_NO compiled into a
non-server executable. Is that really such a great idea? Wouldn't it be
better if pg_rewind did not depend on that? (Perhaps it should get the
database's catalog version out of the pg_control file, for example.)
Sure, that would be better. Although I don't have much hope to make it
completely version-independent. At the moment, pg_rewind explicitly
reads the control file (yeah, it knows about that too), and checks that
the catalog version matches what pg_rewind was compiled with.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
