On 17 October 2010 15:38, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andrew Dunstan <and...@dunslane.net> writes: >> On 10/17/2010 05:30 AM, Dean Rasheed wrote: >>> I just thought of another corner case, which can lead to a crash. The >>> comparison code assumes that the number of elements in the enumeration >>> is constant during a query, but that's not necessarily the case. >>> ... >>> Of course that's a pathalogical example, but we should protect against >>> it, preferrably without compromising performance in more normal cases. > >> Yeah, good point. But how do we manage that? > > Why is it crashing? I can see that this sort of thing might lead to > nonsensical answers, but a crash is harder to understand. >
Hmm, it's harder than I thought. The crash is because each time it finds a label it hasn't seen before it adds it to the array of cached values without checking the array bounds. That array is only as big as the number of elements in the enum the first time it was called. Allowing the array to grow would prevent crashes, but not protect again returning incorrect answers. Perhaps it should just read and cache all the values the first time it is called. Then if it ever fails to find a value in the array, it knows that the enum must have grown, and it can rebuild the whole array. Regards, Dean > regards, tom "haven't read the patch" lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
