Re: review: CHECK FUNCTION statement - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: review: CHECK FUNCTION statement
Date
Msg-id CAFj8pRBETsCNVypNFEbA6L5qfnBEDf0w96BoTt-bamsE2+_T4Q@mail.gmail.com
Whole thread Raw
In response to Re: review: CHECK FUNCTION statement  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: review: CHECK FUNCTION statement  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
2011/12/16 Greg Smith <greg@2ndquadrant.com>:
> I just poked at this a bit myself to see how the patch looked.  There's just
> over 4000 lines in the diff.  Even though 1/4 of that is tests, which is
> itself encouraging, that's still a good sized feature.  The rate at which
> code here has still been changing regularly here has me nervous about
> considering this a commit candidate right now though.  It seems like it
> still needs a bit more time to have problems squeezed out still.
>
> Two ideas I was thinking about here:
>
> -If you take a step back and look at where the problem parts of the code
> have been recently, are there any new tests or assertions you might add to
> try and detect problems like that in the future?  I haven't been following
> this closely enough to have any suggestions where, and there is a lot of
> error checking aimed at logging already; maybe there's nothing new to chase
> there.

last bug was based on wrong untoasting of function parameters - and it
was hang on assertion - so it was ok

I can recheck code where I can add asserts

There is known issue - I cannot to check multi check statement in
regress tests, because results (notices, errors) can be in random
order. We don't sort functions by oid in check_functions_lookup.


>
> -Can we find some larger functions you haven't tested this against yet to
> throw at it?  It seems able to consume all the cases you've constructed for
> it; it would be nice to find some brand new ones it's never seen before to
> check.
>

I use it for checking of my most large plpgsql project - it is about
300KB plpgsql procedures - but this code is not free - and this module
helps to find lot of bugs.

I have plan to check a more functions from regress tests - but these
tests are no bugs - I checked almost all  four months ago - dynamic
sql based and temp table based cannot check.

> This has made a lot of progress and seems it will be a good commit candidate
> for the next CF.  I think it justs a bit more time than we have left in this
> CommitFest for it right now, particularly given the size of the patch.  I'm
> turning this one into "returned with feedback", but as a mediocre pl/pgsql
> author I'm hoping to see more updates still.

I'll send update early

Regards

Pavel

>
> --
> Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
> PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


pgsql-hackers by date:

Previous
From: Phil Sorber
Date:
Subject: WIP patch: Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation
Next
From: Pavel Stehule
Date:
Subject: Re: review: CHECK FUNCTION statement