On Jun 16, 2011, at 8:01 PM, Florian Pflug wrote: > On Jun16, 2011, at 18:46 , Alexey Klyukin wrote: >> On Jun 16, 2011, at 6:49 PM, Florian Pflug wrote: >>> Hm, wouldn't a test for "context == PGC_POSTMASTER" be more appropriate? >> >> In such a case the errors caused by command-line arguments won't stop the >> postmaster. >> PGC_S_FILE seems to handle this correctly. I'm not sure whether it is >> appropriate to use >> there though. > > Ah, yeah, you're right. PGC_S_FILE sounds fine, then. I guess this means you > can > drop the check for "context == PGC_SIGHUP" though, because surely the source > must > be PGC_S_DEFAULT or PGC_S_FILE if context == PGC_SIGHUP, right? So the check > would > become > if (source == PGC_S_FILE || source == PGC_S_DEFAULT) > where it now says > if (context == PGC_SIGHUP || source == PGC_S_DEFAULT)
Yes, AFAIK PGC_SIGHUP is redundant, thank you for the suggestion. >> >> I just recalled a reason for counting the total number of errors. There is a >> condition that >> checks that the total number of errors is less than 100 and bails out if >> it's more than that >> (100 is arbitrary). The reason is to avoid bloating the logs w/ something >> totally unrelated >> to postgresql.conf. That was suggested by Tom Lane here: >> http://archives.postgresql.org/pgsql-hackers/2009-03/msg01142.php > > Ah, right, I missed that. Guess it'll have to stay a counter, then. Still, I > don't think it's > worth the effort to make the count correct in case of included files, so I'd > say just add > a comment explaining that the count isn't totally accurate. Well, while thinking about this I decided to leave the counter for the ParseConfigFp, but drop it in ProcessConfigFile. The case we are protecting against is a single file full of junk. It's unlikely that this junk would contain include directives with valid file paths, neither it's likely to find a file with a correct syntax, but full of invalid directives. Thank you, Alexey. -- Command Prompt, Inc. http://www.CommandPrompt.com PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
