Обсуждение: BUG #3589: /etc/init.d/postgresql reload doesn't reflect /etc/postgresql/postgresql.conf log_statement
The following bug has been logged online: Bug reference: 3589 Logged by: fuminori ido Email address: ido@netlab.jp PostgreSQL version: 7.4.7 Operating system: GNU/Linux, Debian3.1 Description: /etc/init.d/postgresql reload doesn't reflect /etc/postgresql/postgresql.conf log_statement Details: Dear, When I operate the following steps from command-line, postgres still generates SQL statement. Is this bug or spec?: 1) At first, set log_statement=true in /etc/postgresql/postgresql.conf 2) do reload by /etc/init.d/postgresql reload I can see a lot of SQL in /var/log/postgresql/postgres.log. 3) Then, I commented-out the log_statement=true. This means I thought default setting(log_statement=false) would be effective. 4) do reload as the same; /etc/init.d/postgresql reload Still SQL is genrated as follows: > (lot of SQLs in the log) > : > 2007-08-30 11:32:45 [3791] LOG: received SIGHUP, reloading configuration files > 2007-08-30 11:32:47 [3833] LOG: statement: start transaction;set transaction isolation level serializable;select last_value from "_mrs".sl_action_seq; > : > (still lot of SQLs in the log) This is not what I expected. At step 3) above, I think commented-out means set to default value. However, this behavior means, I guess, reload does nothing when config statement is missing. Maybe I need to write explicitly "log_statement=false" even though it is default value in order to be effective on reload? I couldn't get answer by searching Google so I'm posting this unknown behavior here. Much appreciate for your answer! Best Regards
On Thu, Aug 30, 2007 at 03:02:54AM +0000, fuminori ido wrote: > > The following bug has been logged online: > > Bug reference: 3589 > Logged by: fuminori ido > Email address: ido@netlab.jp > PostgreSQL version: 7.4.7 > Operating system: GNU/Linux, Debian3.1 > Description: /etc/init.d/postgresql reload doesn't reflect > /etc/postgresql/postgresql.conf log_statement > Details: > > Dear, > > When I operate the following steps from command-line, postgres still > generates SQL statement. Is this bug or spec?: > > 1) At first, set log_statement=true in /etc/postgresql/postgresql.conf > > 2) do reload by /etc/init.d/postgresql reload > I can see a lot of SQL in /var/log/postgresql/postgres.log. > > 3) Then, I commented-out the log_statement=true. This means I thought > default setting(log_statement=false) would be effective. There's your problem right there: it does *not* mean that the default setting would be effective. It means that the setting won't be changed. Remove the comment and set it to false, and it'll work. (if you restart the server instead of reload it *will* fall back to the default, which isn't very consistent) This is a known problem (though arguably not actually a bug) but it's far from trivial to fix which is why it hasn't been fixed yet. //Magnus
On Thu, 30 Aug 2007, Magnus Hagander wrote: > There's your problem right there: it does *not* mean that the default > setting would be effective. It means that the setting won't be changed. > Remove the comment and set it to false, and it'll work. > (if you restart the server instead of reload it *will* fall back to the > default, which isn't very consistent) > > This is a known problem (though arguably not actually a bug) but it's far > from trivial to fix which is why it hasn't been fixed yet. > Actually this will be fixed in 8.3: http://archives.postgresql.org/pgsql-committers/2007-03/msg00097.php Kris Jurka
Dear Kris and Magnus, Thanks you very much for your prompt reply. I'm now clear the behavior and its future plan. Thanks again! best regards, Kris Jurka wrote: > > > On Thu, 30 Aug 2007, Magnus Hagander wrote: > >> There's your problem right there: it does *not* mean that the default >> setting would be effective. It means that the setting won't be changed. >> Remove the comment and set it to false, and it'll work. >> (if you restart the server instead of reload it *will* fall back to the >> default, which isn't very consistent) >> >> This is a known problem (though arguably not actually a bug) but it's far >> from trivial to fix which is why it hasn't been fixed yet. >> > > Actually this will be fixed in 8.3: > > http://archives.postgresql.org/pgsql-committers/2007-03/msg00097.php > > Kris Jurka -- =================================== æ ªå¼ä¼ç¤¾ ãããã¯ã¼ã¯å¿ç¨éä¿¡ç 究æ NaCl<http://www.netlab.jp/> äºæ¸ æå <ido@netlab.jp> ===================================
Kris Jurka <books@ejurka.com> writes: > On Thu, 30 Aug 2007, Magnus Hagander wrote: >> This is a known problem (though arguably not actually a bug) but it's far >> from trivial to fix which is why it hasn't been fixed yet. > Actually this will be fixed in 8.3: > http://archives.postgresql.org/pgsql-committers/2007-03/msg00097.php Given the long history of failed attempts to fix it, I wouldn't be surprised if this one crashes and burns too ... regards, tom lane