Robert Haas wrote
> That's a sufficiently astonishing result that it wouldn't be
> surprising for this to get reported as a bug where a simple
> performance gap wouldn't be, and I think if we don't fix it the
> perception will be that we've left that bug unfixed. Now, there are
> lots of things we don't fix just because there is not an infinitely
> large army of trained PostgreSQL hackers who love to fix other
> people's bugs for free, so I'm not going to say we HAVE to fix this or
> whatever - but neither do I think fixing it is useless and worthless.
Having had this same thought WRT the "FOR UPDATE in LOOP" bug posting the
lack of a listing of outstanding bugs does leave some gaps. I would imagine
people would appreciate something like:
Frequency: Rare
Severity: Low
Fix Complexity: Moderate
Work Around: Easy - create an actual function; create some form of loop
Status: Confirmed - Awaiting Volunteers to Fix
Even without a formal system it may not hurt for bug threads to have a
posting with this kind of information summarizing the thread. As Tom is apt
to do - "for the sake of the archives" - though mostly I see those once
something has been fixed and not for items that are being left open.
Ideally these could also be migrated to the wiki, with links back to the
main thread, to provide a basic "known open items" interface - something
that I imagine would make corporate acceptance of PostgreSQL more likely.
I don't see where there are a considerably large number of these unresolved
items - most things do indeed get fixed or explained away as normal user
learning.
Sorry for the digression but it seems relevant.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Transaction-lifespan-memory-leak-with-plpgsql-DO-blocks-tp5777942p5778001.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
