Re: [GENERAL] PGXLOG variable worthwhile?
От | scott.marlowe |
---|---|
Тема | Re: [GENERAL] PGXLOG variable worthwhile? |
Дата | |
Msg-id | Pine.LNX.4.33.0209241130031.1889-100000@css120.ihs.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] PGXLOG variable worthwhile? (Greg Copeland <greg@CopelandConsulting.Net>) |
Список | pgsql-hackers |
On 19 Sep 2002, Greg Copeland wrote: > I think Marc made a pretty good case about the use of command line > arguments but I think I have to vote with Tom. Many of the command line > arguments you seem to be using do sorta make sense to have for easy > reference or to help validate your runtime environment for each > instance. The other side of that is, I completely agree with Tom in the > it's a very dangerous option. It would be begging for people to shoot > themselves with it. Besides, just as you can easily parse the command > line, you can also parse the config file to out that information. Plus, > it really should be a very seldom used option. When it is used, it's > doubtful that you'll need the same level of dynamic control that you get > by using command line options. > > As a rule of thumb, if an option is rarely used or is very dangerous if > improperly used, I do think it should be in a configuration file to > discourage adhoc use. > > Let's face it, specify XLOG location is hardly something people need to > be doing on the fly. > > My vote is config file it and no command line option! I'd go one step further, and say that it should not be something a user should do by hand, but there should be a script to do it, and it would work this way: If there is a DIRECTORY called pg_xlog in $PGDATA, then use that. If there is a FILE called pg_xlog in $PGDATA, then that file will have the location of the directory stored in it. That file will be created when the move_pgxlog script is run, and that script will be have all the logic inside it to determine how to move the pg_xlog directory safely, i.e. making sure there's room on the destination, setting permissions, etc... that way, if you're dumb as a rock or smart as a rocket scientist, you do it the same way, and the script makes sure you don't scram your database in a not too bright moment. No postgresql.conf var, no command line switch, a file or directory, and a script. Seem workable? Or am I on crack?
В списке pgsql-hackers по дате отправления: