2009/7/14 Frank van Vugt :
> Hi,
>
>> This is a normal interbackend communication signal. You need to
>> configure gdb to ignore SIGUSR2 (ie, pass it on and not stop execution).
>> Probably SIGUSR1 too.
Frank,
thanks for letting me know about your post - I didn't have time yet to
read yesterday po
2009/7/14 Frank van Vugt :
> Basically the flow is as follows:
> You can quit gdb by a plain -c, just confirm when it asks you to detach.
> The backend will continue to run, your app should now show the error.
Thanks.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make change
2009/7/14 Tom Lane :
> Tom Lane wrote:
I've applied the patch - I hope it will fix our problem. I will ask
users of our application to do those things they did when the error
was thrown. Thanks a lot Tom.
ML
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
2009/7/15 Frank van Vugt :
> Hi Tom,
> Yep, after applying it yesterday evening, we didn't see this problem at all
> today, so it definitely looks as if this patch nailed it.
> Thanks for the [great|quick] support !
I confirm that too - no errors after applying the patch. Great work
Tom, thanks
The following bug has been logged online:
Bug reference: 5075
Logged by: Marek Lewczuk
Email address: ma...@lewczuk.com
PostgreSQL version: 8.4.0
Operating system: All
Description:Text Search parser does not identify xml tag when
attribute name's contains under
W dniu 2009-11-15 14:56, Peter Eisentraut pisze:
On ons, 2009-09-23 at 20:31 -0300, Euler Taveira de Oliveira wrote:
Marek Lewczuk escreveu:
Please execute following example:
select * from ts_debug('english', '')
Fix committed to 8.3, 8.4, 8.5.
Great. Thanks.
ML
--
Hello,
I think that there is a bug in plPGSQL - or maybe I don't know something
about this language. Try to create this function
Ok., this is the function created in plPGSQL:
CREATE FUNCTION "public"."test" (text, text) RETURNS text AS'
BEGIN
IF $1 THEN
RETURN $1;
ELSE
RETURN $2;
E
I belive that I have found a bug - or maybe it was done on purpose. Have
a look at this query:
SELECT integer_field FROM bugtable WHERE (CASE WHEN '' <> '' THEN
integer_field = '' ELSE integer_field = 0 END);
Result: ERROR: invalid input syntax for integer: ""
SELECT text_field FROM bugtable W
Alexander Litvinov wrote:
This is normaol behavior.
I belive that I have found a bug - or maybe it was done on purpose. Have
a look at this query:
SELECT integer_field FROM bugtable WHERE (CASE WHEN '' <> '' THEN
integer_field = '' ELSE integer_field = 0 END);
Result: ERROR: invalid input syntax
Richard Huxton wrote:
On Friday 19 December 2003 09:02, Marek Lewczuk wrote:
But until it's evaluated ''<>'' it doesn't know it is false. When building the
CASE expression, it's trying to map types to each elements and notes that ''
is not an
Csaba Nagy wrote:
Because that's a syntax check, which does NOT evaluate any of the
expressions, only the types of them. Even if it will not be executed
ever, it is still wrong, and it should generate an error, because it
means a mistake on your side which potentially could leave to results
you did
11 matches
Mail list logo
