Tom Lane wrote: > Kevin Brown <[EMAIL PROTECTED]> writes: > > I agree with your assessment for the most part, except for PGDATA. > > There's no good reason I can think of for the postmaster to look at > > it. > > The other side of that coin is, what's the good reason to remove it? > There's a long way between "I don't want my setup to depend on PGDATA" > and "I don't think your setup should be allowed to depend on PGDATA". > If you don't want to use it, then don't use it. Why do you need to > tell me how I'm allowed to run my installation?
I'm not talking about getting rid of ALL dependency on PGDATA in our entire distribution, only postmaster's. Recall that the main purpose of making any of these changes at all is to make life easier for the guys who have to manage the systems that will be running PostgreSQL. Agreed? So: imagine you're the newly-hired DBA and your boss points you to the system and says "administrate the database on that". You go over to the computer and start looking around. You do a "ps" and see a postmaster process running. You know that it's the process that is listening for connections. The "ps" listing only says "/usr/bin/postmaster". No arguments to clue you in, nothing. Where do you look to figure out where the data is? How do you figure out what port it's listening on? Well, we're already agreed on how to deal with that question: you look in /etc/postgresql, and because this is a relatively new install (and the PostgreSQL maintainers, who are very wise and benevolent, made that the default location for configs :-), it has a postgresql.conf file with a line that says "data_directory = /var/lib/pgsql". It doesn't mention a port to listen to so you know that it's listening on port 5432. As a DBA, you're all set. Now let's repeat that scenario, except that instead of seeing one postmaster process, you see five. And they all say "/usr/bin/postmaster" in the "ps" listing. No arguments to clue you in or anything, as before. You might be able to figure out where one of them is going by looking at /etc/postgresql, but what about the rest? Now you're stuck unless you want to do a "find" (time consuming and I/O intensive -- a good way to slow the production database down a bit), or you're knowledgeable enough to use 'lsof' or black magic like digging into kernel memory to figure out where the config files and data directories are, or you have enough knowledge to pore through the startup scripts and understand what they're doing. Lest you think that this is an unlikely scenario, keep in mind that most startup scripts, including pg_ctl, currently start the postmaster without arguments and rely on PGDATA, so a shop that hasn't already been bitten by this *will* be. Right now shops that wish to avoid the trap I described have to go to *extra* lengths: they have to make exactly the same kinds of changes to the scripts that I'm talking about us making (putting an explicit '-D "$PGDATA"' where none now exists) or they have to resort to tricks like renaming the postmaster executable and creating a shell script in its place that will invoke the (renamed) postmaster with '-D "$PGDATA"'. It's not so bad if only a few shops have to make those changes. But what if it's thousands? Yeah, the distribution guys can patch the scripts to do this, but why should they have to? They, and the shops that run PostgreSQL, are our customers. All of that is made possible because the postmaster can use an inherited PGDATA for the location of the config files and (if the config files don't say differently in our new scheme) the data directory, and pg_ctl takes advantage of that fact (as do most startup scripts that I've seen, that don't just invoke pg_ctl). I'm not arguing that we should remove the use of PGDATA *everywhere*, only in postmaster (and then, only postmaster's use of an *inherited* PGDATA. It should still set PGDATA so its children can use it). It means changing pg_ctl and the startup scripts we ship. The earlier we make these changes, the less overall pain there will be in the long run. > > ... people who are starting things by hand hopefully aren't so > > inflexible as to demand that PGDATA remain treated as-is. > > Yes, I could reconfigure my scripts to not depend on this. You have > not given me an adequate argument why I should have to. [By this I'm assuming you're referring to the scripts you use for testing, and not the ones that ship with the distribution] I'm not arguing that you should get rid of all the references to PGDATA in your scripts or anything crazy like that. The changes I'm talking about are minor: where you see "postmaster" without any "-D" arguments, you simply add '-D "$PGDATA"' to it, before any other arguments that you might also be passing. That's it. Nothing else should be needed. The reason for removing postmaster's use of an inherited PGDATA is the same as the reason for making the other changes we already agree should be made: to make things easier for the guys in the field who have to manage production systems. -- Kevin Brown [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
