| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: tuplestore API problem |
| Date: | 2009-03-27 15:19:06 |
| Message-ID: | 9457.1238167146@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> writes:
> 2009/3/27 Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>:
>> 2009/3/27 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> A brute-force solution is to change tuplestore_gettupleslot() so that it
>>> always copies the tuple, but this would be wasted cycles for most uses
>>> of tuplestores. I'm thinking of changing tuplestore_gettupleslot's API
>>> to add a bool parameter specifying whether the caller wants to force
>>> a copy.
> Here's the patch. Hope there are no more on the same reason. It seems
> that we'd need to implement something like garbage collector in
> tuplestore, marking and tracing each row references, if the complete
> solution is required.
I don't like this; I'm planning to go with the aforementioned API
change instead. The way you have it guarantees an extra copy cycle
even when tuplestore is already making a copy internally; and it doesn't
help if we find similar problems elsewhere. (While I'm making the
API change I'll take a close look at each call site to see if it has
any similar risk.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-03-27 15:42:34 | Re: 8.4 open items list |
| Previous Message | Heikki Linnakangas | 2009-03-27 15:00:09 | Re: psql: Make tab completion work for ANALYZE VERBOSE ... |