Re: review: CHECK FUNCTION statement

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: review: CHECK FUNCTION statement
Date: 2011-12-17 21:00:56
Message-ID: CAFj8pRBETsCNVypNFEbA6L5qfnBEDf0w96BoTt-bamsE2+_T4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/12/16 Greg Smith <greg(at)2ndquadrant(dot)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(at)2ndQuadrant(dot)com   Baltimore, MD
> PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-12-17 21:25:02 Re: review: CHECK FUNCTION statement
Previous Message Phil Sorber 2011-12-17 20:52:29 WIP patch: Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation