Subject: should pg_basebackup be listed as a server application?

From: Peter Eisentraut <[email-masked]>
Date: Fri, 06 May 2011 20:18:19 +0300

The pg_basebackup reference page is currently under "Client
Applications" [0].  I think it's more of a server application, because
it's what you'd run instead of initdb on the server.  Should it be moved
to the "Server Applications" section?

[0] http://developer.postgresql.org/pgdocs/postgres/reference.html

---

From: Magnus Hagander <[email-masked]>
Date: Fri, 6 May 2011 19:30:27 +0200

> to the "Server Applications" section?

Not sure I buy that argument. pg_dump/pg_dumpall/pg_restore are under
client applications. They're something you run *alongside* initdb and
not instead, sure.. But they're all backup tools.

And normally you *don't* necessarily run pg_basebackup instead of
initdb. That is just one usecase - the one of setting up a clone or a
replication slave. If you're using it to just take a base backup
(which is what it's named for), it's not done instead of initdb...

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

---

From: Alvaro Herrera <[email-masked]>
Date: Fri, 06 May 2011 15:30:04 -0300

> not instead, sure.. But they're all backup tools.

Is there really a dichotomy here? Client/server?  Maybe we just need
another category, "administrative applications" or something like that.

-- 
Álvaro Herrera <[email-masked]>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---

From: Josh Kupershmidt <[email-masked]>
Date: Fri, 6 May 2011 19:23:24 -0400

> another category, "administrative applications" or something like that.

You can draw a clear line between applications which can connect to a
server remotely, and those which need to be executed on the actual
server machine, and thus distinguish "Client" from "Server"
Applications. If we use that logic, I think pg_config should be listed
as a "Server Application" and pg_basebackup should remain a "Client
Application", and we'd be consistent.

I think trying to break the Client Applications down into
administrative and non-administrative isn't very helpful -- the only
client applications I see which are clearly non-administrative (i.e.
non-superusers would normally use) are psql and ecpg. Everything else
seems like stuff you either generally need superuser privs for
(create*, drop*, etc.) or are tools typically used by the server admin
(taking and restoring backups).

Josh

---

From: Tom Lane <[email-masked]>
Date: Fri, 06 May 2011 20:18:13 -0400

> Application", and we'd be consistent.

Well, pg_config still fails to fit neatly into either category, since
you might want it on the server to find out how the server is
configured, and you might want it on the client to find out how the
client is configured (which could very easily be different, especially
if you are inquiring about things like installation directories).

I also tend to agree with Alvaro that a lot of the stuff that falls on
the "client" side of the fence when using the strict "can it be executed
remotely" test is stuff that typically would *not* be wanted on a
client machine.  A packager who had thought twice about it would
probably not put pg_basebackup, pg_dump*, vacuumdb, reindexdb, or
clusterdb into a "client" rather than a "server" package, for instance.
(Although I notice that I've drunk the koolaid to the extent of
slavishly following the current division in the Fedora packages :-()

I'm not entirely sure if the notion of an "administrative" app helps
much, but for sure I've never been satisfied with the equation of "can
in principle execute remotely" with "client".  This is a good time to be
rethinking that.

			regards, tom lane

---

From: Peter Eisentraut <[email-masked]>
Date: Sun, 08 May 2011 00:38:18 +0300

On fre, 2011-05-06 at 20:18 -0400, Tom Lane wrote:
> in principle execute remotely" with "client".  This is a good time to
> be rethinking that. 

One piece of supporting evidence that has been moderately useful over
the years is that what we list as server applications are dependent on a
particular major version (or the dependency closure of that, to include
pg_ctl), whereas clients work with multiple server versions to varying
degrees.

And another, possibly equivalent, factor is that what you see under
"server" is that it packaged in the server package, and what is under
"client" is packaged in the client package.  That's kind of useful for
quickly finding what to install.

So where would pg_basebackup fit in according to these two criteria?

---

From: Magnus Hagander <[email-masked]>
Date: Sun, 8 May 2011 21:55:05 +0200

> So where would pg_basebackup fit in according to these two criteria?

It should work with different versions of the server. It will require
a 9.1 or newer server, but I see no reason why pg_basebackup 9.2
shouldn't work with a 9.1 server, for example.

I'm not sure if it'd go in a server or client RPM though, I'll let a
packager comment on that part.

---

From: Euler Taveira de Oliveira <[email-masked]>
Date: Mon, 09 May 2011 16:28:42 -0300

Em 06-05-2011 21:18, Tom Lane escreveu:
> remotely" test
I think this idea is strict from docs [1] ("The common feature of these 
applications is that they can be run on any host, independent of where the 
database server resides."). I agree that is not a good way to categorize 
binaries but who bothers? (It is only two categories.)

It seems logical that all "clients" use some postgresql library. So I would 
put pg_basebackup on the "client" side of the fence.

[1] http://www.postgresql.org/docs/9.1/static/reference-client.html

-- 
   Euler Taveira de Oliveira - Timbira       http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento