The lack of plan invalidation is limitation that also has two bugs attached to it.
I agree that full fledged patch to fix all the isssues should not be done in 8.3.
I can't agree that effort to get the bugs fixed already in 8.3 should not be made.
I can understand that hackers here have learned to live with these bugs and limitations but not all the users are reading these flame wars here and most of them are not even aware of these bugs until they are hit by them.
Sql function bug is such that users probably won't even understand what hit them and how the data got mangled.
- If there is nothing that can be done in 8.3 at least warning should be added into the documentation. It will be just one more don't in our long list don'ts for our developers.
ERROR: cache lookup failed for function.
- Could the plan be marked as invalid so it would fail only once so the next call to the function would get replanned and work again. At least it would be better than losing parts of application for indeterminate time.
- Should update pg_proc set proname = proname; be the current solution to the problem or has someone something better to offer. We could scan released code for DROP FUNCTION and generate plan invalidation statement as last item of transaction releasing the code.
- Could some less dangerous looking mechanism be added to 8.3 that wouldn't make users not used to PostgreSQL limitations gasp for air when they see the workarounds :)
Calling the problem limitation will not make it go away. I am quite sure that new users consider it a bug until thay are converted to perceive it as lmitation.
No matter how many time the usage of functions in database is called corner case it does not make it a corner case. In my experience it is quite common practice on all the database systems i have worked with. I do get the impression that Tom who would prefer to get all the pl's out of PostgreSQL and live happily ever after with pure SQL standard.
I agree that full fledged patch to fix all the isssues should not be done in 8.3.
I can't agree that effort to get the bugs fixed already in 8.3 should not be made.
I can understand that hackers here have learned to live with these bugs and limitations but not all the users are reading these flame wars here and most of them are not even aware of these bugs until they are hit by them.
Sql function bug is such that users probably won't even understand what hit them and how the data got mangled.
- If there is nothing that can be done in 8.3 at least warning should be added into the documentation. It will be just one more don't in our long list don'ts for our developers.
ERROR: cache lookup failed for function.
- Could the plan be marked as invalid so it would fail only once so the next call to the function would get replanned and work again. At least it would be better than losing parts of application for indeterminate time.
- Should update pg_proc set proname = proname; be the current solution to the problem or has someone something better to offer. We could scan released code for DROP FUNCTION and generate plan invalidation statement as last item of transaction releasing the code.
- Could some less dangerous looking mechanism be added to 8.3 that wouldn't make users not used to PostgreSQL limitations gasp for air when they see the workarounds :)
Calling the problem limitation will not make it go away. I am quite sure that new users consider it a bug until thay are converted to perceive it as lmitation.
No matter how many time the usage of functions in database is called corner case it does not make it a corner case. In my experience it is quite common practice on all the database systems i have worked with. I do get the impression that Tom who would prefer to get all the pl's out of PostgreSQL and live happily ever after with pure SQL standard.
On Wed, Aug 20, 2008 at 11:27 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote:
Le mercredi 20 août 2008, Tom Lane a écrit :
> That just begs the question of what's the difference between a "bug" andAs a person who previously insisted it was a bug, I'd like to take the
> a "limitation". AFAICS, having such a policy/guideline/whatchacallit
> in place wouldn't have done a single thing to stop the current flamewar,
> because the people who want this thing back-patched are insisting that
> it's a bug, while those who don't are saying it's a long-known
> limitation.
opportunity to claim that I didn't realize this was a limitation of the
design of plan invalidation, which now seems related to DDL operations.
Realizing this earlier would have resulted in no mail at all on this thread
from here.
There's certainly a balance between -hackers readers not doing their homework
and people in the know choosing not to re-estate known things...
And this way the project works is what leads its users not to fear minor
> Also, there are a whole lot more considerations in a backpatch decision
> than just "is it a bug". The (estimated) risk of creating new bugs and
> the extent to which the patch will change behavior that apps might be
> relying on are two big reasons why we might choose not to back-patch
> a bug fix.
upgrades, which is something I (we all?) highly value.
Regards,
--
dim
No comments:
Post a Comment