Skip site navigation (1) Skip section navigation (2)

Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Denis Afonin <vadm(at)itkm(dot)ru>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions
Date: 2009-02-27 15:31:32
Message-ID: 18983.1235748692@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> I think we should instead try to break the PANIC cycle. If we exceed 
> ERRORDATA_STACK_SIZE, and we're already PANICing, we should just die 
> immediately instead of throwing another PANIC about exceeding the stack 
> size. The attached patch does that.

I don't think that's an improvement.

I'm not sure exactly why the previous fix for this type of problem
failed to cover this case --- did you identify why?

> However, a more serious issue is that a regular user can do that and 
> bring down the whole system. I suggest that we make "CREATE [DEFAULT] 
> CONVERSION" to call the conversion function with a empty string, to 
> check that it is in fact capable of doing the conversion.

That part seems like a good idea, now that the conversion functions
throw errors (rather than Asserts) for wrong calls.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-02-27 15:44:01
Subject: Re: Immediate shutdown and system(3)
Previous:From: Tom LaneDate: 2009-02-27 15:25:48
Subject: Re: Error codes for LIMIT and OFFSET

pgsql-bugs by date

Next:From: Heikki LinnakangasDate: 2009-02-27 15:51:01
Subject: Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions
Previous:From: Heikki LinnakangasDate: 2009-02-27 15:10:45
Subject: Re: BUG #4679: invalid UTF-8 byte sequence detected near byte 0xa3 + postgresql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group