[BUGS] 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: [EMAIL PROTECTED] PostgreSQL version: 7.4.7 Operating system: GNU/Linux, Debian3.1 Description:/etc/init.d/postgresql reload doesn't reflect /etc/postgresql/postgresql

Re: [BUGS] BUG #3589: /etc/init.d/postgresql reload doesn't reflect /etc/postgresql/postgresql.conf log_statement

On Thu, Aug 30, 2007 at 03:02:54AM +, fuminori ido wrote: > > The following bug has been logged online: > > Bug reference: 3589 > Logged by: fuminori ido > Email address: [EMAIL PROTECTED] > PostgreSQL version: 7.4.7 > Operating system: GNU/Linux, Debian3.1 > Description:

Re: [BUGS] BUG #3589: /etc/init.d/postgresql reload doesn't reflect /etc/postgresql/postgresql.conf log_statement

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 *wil

[BUGS] to_tsquery stack overflow

Passing a query with enough nested parenthesis in it causes a segfault. Attached is a handy little program to generate such a query, the actual query was too big to get through to the list. The problem seems to be unbounded recursion in the makepol function that converts the input query from infix

Re: [BUGS] to_tsquery stack overflow

Heikki Linnakangas wrote: > Passing a query with enough nested parenthesis in it causes a segfault. > Attached is a handy little program to generate such a query, the actual > query was too big to get through to the list. > > The problem seems to be unbounded recursion in the makepol function that

Re: [BUGS] BUG #3589: /etc/init.d/postgresql reload doesn't reflect /etc/postgresql/postgresql.conf log_statement

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 >> se

Re: [BUGS] BUG #3589: /etc/init.d/postgresql reload doesn't reflect /etc/postgresql/postgresql.conf log_statement

Kris Jurka <[EMAIL PROTECTED]> 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/pgs

Re: [BUGS] to_tsquery stack overflow

"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > The problem seems to be unbounded recursion in the makepol function that > converts the input query from infix to polish notation. An easy fix > would be to just add a level parameter to makepol that's incremented on > each recursion, and throw an

Re: [BUGS] BUG #3587: EXECUTE and trigger problem [VASCL:A1226546842]

but the documentation does not say I shouldn't be able to do it.  Additionally, an alternate method (which was not included) using temporary tables works fine.  It fails when switching to the old record. thanks cyrus Tom Lane wrote: Cyrus Downey <[EMAIL PROTECTED]> writes: Accord

Re: [BUGS] BUG #3588: coalesce not working in join

"Richard Harris" <[EMAIL PROTECTED]> writes: > The queries, query1 and query2, below are identical except that query1 has a > 'left join' where query2 has a 'join'. Both queries return three rows. > However query2 (with the 'join') returns all non-null values in column > t1b_pkt1 where query 1 with

[BUGS] to_date gives odd results

example from docs: pagila=# select to_date('05 Dec 2000', 'DD Mon '); to_date 2000-12-05 (1 row) slight modification: pagila=# select to_date('05 December 2000', 'DD Month '); to_date --- 0001-12-05 BC (1 row) I can't imagine that's expected behavior bug? o

[BUGS] Re: BUG #3504: Some listening sessions never return from writing, problems ensue

Peter, I don't know if this is directly related to your problem, but the version of dbd_db_pg_notifies you are using has a memory leak in it. The memory leak causes a small amount of memory to be leaked every time pg_notifies is called from your perl code. This memory leak affected several

Re: [BUGS] to_date gives odd results

Robert Treat <[EMAIL PROTECTED]> writes: > pagila=# select to_date('05 December 2000', 'DD Month '); > to_date > --- > 0001-12-05 BC > (1 row) > I can't imagine that's expected behavior bug? You needed to say FMMonth, else it expects fixed-width column. to_date and friends a

Re: [BUGS] to_date gives odd results

On Thursday 30 August 2007 21:15, Tom Lane wrote: > Robert Treat <[EMAIL PROTECTED]> writes: > > pagila=# select to_date('05 December 2000', 'DD Month '); > > to_date > > --- > > 0001-12-05 BC > > (1 row) > > > > I can't imagine that's expected behavior bug? > > You needed to sa

Re: [BUGS] to_tsquery stack overflow

"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > Actually, the right way to fix that is of course to call > check_stack_depth() in makepol and TS_execute. Done. That is, I did it in HEAD's integrated tsearch code. I suppose the same hazard exists in all back-branch contrib/tsearch2 versions ..