| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
| |
per tuple memory context doesn't discard them.
|
| |
|
|
|
|
|
| |
it's hard to keep such massive changes in sync with the tree
so I need to get it in and work from there now).
Jan
|
| |
|
|
| |
Rather surprising we hadn't seen bug reports about this ...
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
allocated by plan nodes are not leaked at end of query. This doesn't
really matter for normal queries, but it sure does for queries invoked
repetitively inside SQL functions. Clean up some other grotty code
associated with tupdescs, and fix a few other memory leaks exposed by
tests with simple SQL functions.
|
| | |
|
| |
|
|
|
|
| |
for example, an SQL function can be used in a functional index. (I make
no promises about speed, but it'll work ;-).) Clean up and simplify
handling of functions returning sets.
|
| |
|
|
|
|
|
|
|
| |
These two routines will now ALWAYS elog() on failure, whether you ask for
a lock or not. If you really want to get a NULL return on failure, call
the new routines heap_open_nofail()/heap_openr_nofail(). By my count there
are only about three places that actually want that behavior. There were
rather more than three places that were missing the check they needed to
make under the old convention :-(.
|
| |
|
|
|
|
| |
memory contexts. Currently, only leaks in expressions executed as
quals or projections are handled. Clean up some old dead cruft in
executor while at it --- unused fields in state nodes, that sort of thing.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Ensure that outer tuple link needed for inner indexscan qual evaluation
gets set in the EvalPlanQual case. This stops coredump, but we still
have resource leaks due to failure to clean up EvalPlanQual properly...
|
| |
|
|
|
|
| |
* Portions Copyright (c) 1996-2000, PostgreSQL, Inc
to all files copyright Regents of Berkeley. Man, that's a lot of files.
|
| | |
|
| |
|
|
| |
Jan
|
| |
|
