Re: [BUGS] BUG #7642: Unchecked “stats_temp_directory” causes server hang to requests
| От | Tianyin Xu |
|---|---|
| Тема | Re: [BUGS] BUG #7642: Unchecked “stats_temp_directory” causes server hang to requests |
| Дата | |
| Msg-id | CABBDWwdDvMw4OPhVH7MWG2WyqVQKYvxkPSR+f-W98D9KL9EPmQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #7642: Unchecked “stats_temp_directory” causes server hang to requests (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-bugs |
Thanks for the reply, Tom.
--
Tianyin XU,
http://cseweb.ucsd.edu/~tixu/
On Wed, Nov 7, 2012 at 10:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I just changed my previous setting to the empty one. I thought it would be under the data directory also. I got your point, I was stupid (I should comment this one if I don't need it).
What I notice is that any wrong setting might cause latter problems. Since many of us redirect the log messages into files, sometimes we do not notice the problem immediately (at least for me). Maybe I'm too careless. For this one, when I noticed the problem, the log file was filled up with the same error message, and many requests stuck there...
Yes, so I resend the previous mail.
I agree with you that users might make thousands of different mistakes, and all the checkers are not complete. My personal opinion is to check as early as possible, instead of finding errors at runtime. I really like the idea of data directory checking and all the out-of-range checking of the numeric values. What I envisioned is similar checking for semantic values. I don't know whether it's possible (Sorry for my crappy patch).
btw, what is training wheels?
tixu@cs.ucsd.edu writes:Why would you think that's a good idea? It's already going to be under
> I set the stats_temp_directory='' in my postgresql.conf file, with the
> expectation that the directory would be under the data directory.
the data directory. The only reason to change this setting is if you're
going to point to a ramdisk somewhere, which is going to need an
absolute path.
I just changed my previous setting to the empty one. I thought it would be under the data directory also. I got your point, I was stupid (I should comment this one if I don't need it).
What I notice is that any wrong setting might cause latter problems. Since many of us redirect the log messages into files, sometimes we do not notice the problem immediately (at least for me). Maybe I'm too careless. For this one, when I noticed the problem, the log file was filled up with the same error message, and many requests stuck there...
> I found pg has several unchecked user configurations which might causeThis patch seems to have got mangled by your mailer, but in any case I
> problems at run-time. I suggest to check it like what has been done for
> “data_directory” to avoid latter problems. Here is the patches.
don't really see the value. There are any number of ways to mess up
settings like these, and only some of them are detectable by tests
of this sort. Also, the proposed patch only checks at startup time;
if we're going to install training wheels, that doesn't seem sufficient.
Yes, so I resend the previous mail.
I agree with you that users might make thousands of different mistakes, and all the checkers are not complete. My personal opinion is to check as early as possible, instead of finding errors at runtime. I really like the idea of data directory checking and all the out-of-range checking of the numeric values. What I envisioned is similar checking for semantic values. I don't know whether it's possible (Sorry for my crappy patch).
btw, what is training wheels?
regards, tom lane
--
Tianyin XU,
http://cseweb.ucsd.edu/~tixu/
В списке pgsql-bugs по дате отправления: