Thread: tuplesort_gettuple_common() and *should_free argument
I noticed that the routine tuplesort_gettuple_common() fails to set *should_free in all paths in master branch (no bug in 9.6). Consider the TSS_SORTEDONTAPE case, where we can return false without also setting "*should_free = false" to instruct caller not to pfree() tuple memory that tuplesort still owns. I suppose that this is okay because caller should never pfree() a tuple when NULL pointer was returned at higher level (as "pointer-to-tuple"). Even still, it seems like a bad idea to rely on caller testing things such that caller doesn't go on to pfree() a NULL pointer when seemingly instructed to do so by tuplesort "get tuple" interface routine (that is, some higher level routine that calls tuplesort_gettuple_common()). More importantly, there are no remaining cases where tuplesort_gettuple_common() sets "*should_free = true", because there is no remaining need for caller to *ever* pfree() tuple. Moreover, I don't anticipate any future need for this -- the scheme recently established around per-tape "slab slots" makes it seem unlikely to me that the need to "*should_free = true" will ever arise again. So, for Postgres 10, why not rip out the "*should_free" arguments that appear in a bunch of places? This lets us slightly simplify most tuplesort.c callers. Now, it is still true that at least some callers to tuplesort_gettupleslot() (but not any other "get tuple" interface routine) are going to *require* ownership of memory for returned tuples, which means a call to heap_copy_minimal_tuple() remains necessary there (see recent commit d8589946ddd5c43e1ebd01c5e92d0e177cbfc198 for details). But, that's beside the point. In the master branch only, the tuplesort_gettupleslot() test "if (!should_free)" seems tautological, just as similar tests are for every other tuplesort_gettuple_common() caller. So, tuplesort_gettupleslot() can safely assume it should *always* heap_copy_minimal_tuple() in the master branch. (BTW, I'm going to teach tuplesort_gettuple_common() to avoid this heap_copy_minimal_tuple() call for callers that don't actually need it, but that's a discussion for another thread). -- Peter Geoghegan
On 10/22/2016 02:45 AM, Peter Geoghegan wrote: > I noticed that the routine tuplesort_gettuple_common() fails to set > *should_free in all paths in master branch (no bug in 9.6). Consider > the TSS_SORTEDONTAPE case, where we can return false without also > setting "*should_free = false" to instruct caller not to pfree() tuple > memory that tuplesort still owns. I suppose that this is okay because > caller should never pfree() a tuple when NULL pointer was returned at > higher level (as "pointer-to-tuple"). Even still, it seems like a bad > idea to rely on caller testing things such that caller doesn't go on > to pfree() a NULL pointer when seemingly instructed to do so by > tuplesort "get tuple" interface routine (that is, some higher level > routine that calls tuplesort_gettuple_common()). > > More importantly, there are no remaining cases where > tuplesort_gettuple_common() sets "*should_free = true", because there > is no remaining need for caller to *ever* pfree() tuple. Moreover, I > don't anticipate any future need for this -- the scheme recently > established around per-tape "slab slots" makes it seem unlikely to me > that the need to "*should_free = true" will ever arise again. So, for > Postgres 10, why not rip out the "*should_free" arguments that appear > in a bunch of places? This lets us slightly simplify most tuplesort.c > callers. Yeah, I agree we should just remove the *should_free arguments. Should we be worried about breaking the API of tuplesort_get* functions? They might be used by extensions. I think that's OK, but wanted to bring it up. This would be only for master, of course, and any breakage would be straightforward to fix. > Now, it is still true that at least some callers to > tuplesort_gettupleslot() (but not any other "get tuple" interface > routine) are going to *require* ownership of memory for returned > tuples, which means a call to heap_copy_minimal_tuple() remains > necessary there (see recent commit > d8589946ddd5c43e1ebd01c5e92d0e177cbfc198 for details). But, that's > beside the point. In the master branch only, the > tuplesort_gettupleslot() test "if (!should_free)" seems tautological, > just as similar tests are for every other tuplesort_gettuple_common() > caller. So, tuplesort_gettupleslot() can safely assume it should > *always* heap_copy_minimal_tuple() in the master branch. (BTW, I'm > going to teach tuplesort_gettuple_common() to avoid this > heap_copy_minimal_tuple() call for callers that don't actually need > it, but that's a discussion for another thread). Yep. - Heikki
On Wed, Dec 7, 2016 at 11:55 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > Should we be worried about breaking the API of tuplesort_get* functions? > They might be used by extensions. I think that's OK, but wanted to bring it > up. This would be only for master, of course, and any breakage would be > straightforward to fix. I don't think so. I'm not aware of any third party extensions that call tuplesort.c routines, despite having looked for them. I noticed that pg_repack doesn't. For any that do, they'll break in a predictable, obvious way. -- Peter Geoghegan
Peter Geoghegan <pg@heroku.com> writes:
> On Wed, Dec 7, 2016 at 11:55 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> Should we be worried about breaking the API of tuplesort_get* functions?
>> They might be used by extensions. I think that's OK, but wanted to bring it
>> up. This would be only for master, of course, and any breakage would be
>> straightforward to fix.
> I don't think so. I'm not aware of any third party extensions that
> call tuplesort.c routines, despite having looked for them. I noticed
> that pg_repack doesn't. For any that do, they'll break in a
> predictable, obvious way.
Adding or subtracting function arguments is something we do all the time.
As long as it's not proposed for back-patch, I don't see a problem.
regards, tom lane
Peter Geoghegan <pg@heroku.com> writes:
> On Wed, Dec 7, 2016 at 11:55 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> Should we be worried about breaking the API of tuplesort_get* functions?
>> They might be used by extensions. I think that's OK, but wanted to bring it
>> up. This would be only for master, of course, and any breakage would be
>> straightforward to fix.
> I don't think so. I'm not aware of any third party extensions that
> call tuplesort.c routines, despite having looked for them. I noticed
> that pg_repack doesn't. For any that do, they'll break in a
> predictable, obvious way.
Adding or subtracting function arguments is something we do all the time.
As long as it's not proposed for back-patch, I don't see a problem.
regards, tom lane
On Fri, Oct 21, 2016 at 4:45 PM, Peter Geoghegan <pg@heroku.com> wrote: > More importantly, there are no remaining cases where > tuplesort_gettuple_common() sets "*should_free = true", because there > is no remaining need for caller to *ever* pfree() tuple. Moreover, I > don't anticipate any future need for this -- the scheme recently > established around per-tape "slab slots" makes it seem unlikely to me > that the need to "*should_free = true" will ever arise again. Attached patch 0001-* removes all should_free arguments. To reiterate, this is purely a refactoring patch. > Now, it is still true that at least some callers to > tuplesort_gettupleslot() (but not any other "get tuple" interface > routine) are going to *require* ownership of memory for returned > tuples, which means a call to heap_copy_minimal_tuple() remains > necessary there (see recent commit > d8589946ddd5c43e1ebd01c5e92d0e177cbfc198 for details). But, that's > beside the point. In the master branch only, the > tuplesort_gettupleslot() test "if (!should_free)" seems tautological, > just as similar tests are for every other tuplesort_gettuple_common() > caller. So, tuplesort_gettupleslot() can safely assume it should > *always* heap_copy_minimal_tuple() in the master branch. (BTW, I'm > going to teach tuplesort_gettuple_common() to avoid this > heap_copy_minimal_tuple() call for callers that don't actually need > it, but that's a discussion for another thread). I decided that it made sense to address this at the same time after all. So, the second patch attached here, 0002-*, goes on to do so. This is a performance optimization that we already agreed was a good idea for Postgres 10 when d8589946ddd5c43e1ebd01c5e92d0e177cbfc198 went in. Note that the call sites that now opt out of receiving their own personal copy are essentially returning to their behavior for the entire beta phase of PostgreSQL 9.6. The problem with that accidental state of affairs was that it wasn't always safe. But, it was still generally safe for the majority of callers, I believe, not least because it took months to hear any complaints at all. That majority of callers now opt out. The main question for reviewers of 0002-*, then, is whether or not I have correctly determined which particular callers can safely opt out. Finally, 0003-* is a Valgrind suppression borrowed from my parallel CREATE INDEX patch. It's self-explanatory. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
On Fri, Dec 9, 2016 at 5:59 PM, Peter Geoghegan <pg@heroku.com> wrote: > Attached patch 0001-* removes all should_free arguments. To reiterate, > this is purely a refactoring patch. I think this patch might have a bug. In the existing code, tuplesort_gettupleslot sets should_free = true if it isn't already just before calling ExecStoreMinimalTuple((MinimalTuple) stup.tuple, slot, should_free), so it seems that ExecStoreMinimalTuple() will always get "true" as the fourth argument. However the patch changes that line of code like this: + ExecStoreMinimalTuple((MinimalTuple) stup.tuple, slot, false); So the patch seems to have the effect of changing the fourth argument to this call to ExecStoreMinimalTuple() from always-true to always-false. I might be missing something, but my guess is that's not right. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, Dec 12, 2016 at 9:31 AM, Robert Haas <robertmhaas@gmail.com> wrote: > I think this patch might have a bug. In the existing code, > tuplesort_gettupleslot sets should_free = true if it isn't already > just before calling ExecStoreMinimalTuple((MinimalTuple) stup.tuple, > slot, should_free), so it seems that ExecStoreMinimalTuple() will > always get "true" as the fourth argument. However the patch changes > that line of code like this: > > + ExecStoreMinimalTuple((MinimalTuple) stup.tuple, slot, false); > > So the patch seems to have the effect of changing the fourth argument > to this call to ExecStoreMinimalTuple() from always-true to > always-false. I might be missing something, but my guess is that's > not right. There was a memory leak added by 0001-*, but then fixed by 0002-*. I should have done more testing of 0001-* alone. Oops. Attached revision of 0001-* fixes this. A revised 0002-* is also attached, just as a convenience for reviewers (they won't need to resolve the conflict themselves). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
On Mon, Dec 12, 2016 at 2:30 PM, Peter Geoghegan <pg@heroku.com> wrote: > On Mon, Dec 12, 2016 at 9:31 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> I think this patch might have a bug. In the existing code, >> tuplesort_gettupleslot sets should_free = true if it isn't already >> just before calling ExecStoreMinimalTuple((MinimalTuple) stup.tuple, >> slot, should_free), so it seems that ExecStoreMinimalTuple() will >> always get "true" as the fourth argument. However the patch changes >> that line of code like this: >> >> + ExecStoreMinimalTuple((MinimalTuple) stup.tuple, slot, false); >> >> So the patch seems to have the effect of changing the fourth argument >> to this call to ExecStoreMinimalTuple() from always-true to >> always-false. I might be missing something, but my guess is that's >> not right. > > There was a memory leak added by 0001-*, but then fixed by 0002-*. I > should have done more testing of 0001-* alone. Oops. > > Attached revision of 0001-* fixes this. A revised 0002-* is also > attached, just as a convenience for reviewers (they won't need to > resolve the conflict themselves). Committed 0001. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, Dec 12, 2016 at 12:59 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Committed 0001. Thanks. I should have already specifically pointed out that the original discussion on what became 0002-* is here: postgr.es/m/7256.1476711733@sss.pgh.pa.us As I said already, the general idea seems uncontroversial. -- Peter Geoghegan
Peter Geoghegan <pg@heroku.com> writes:
> I should have already specifically pointed out that the original
> discussion on what became 0002-* is here:
> postgr.es/m/7256.1476711733@sss.pgh.pa.us
> As I said already, the general idea seems uncontroversial.
I looked at the 0002 patch, and while the code is probably OK, I am
dissatisfied with this API spec:
+ * If copy is TRUE, the slot receives a copied tuple that will stay valid
+ * regardless of future manipulations of the tuplesort's state. Memory is
+ * owned by the caller. If copy is FALSE, the slot may just receive a pointer
+ * to a tuple held within the tuplesort. The latter is more efficient, but
+ * the slot contents may be corrupted if there is another call here before
+ * previous slot contents are used.
What does "here" mean? If that means specifically "another call of
tuplesort_gettupleslot", say so. If "here" refers to the whole module,
it would be better to say something like "the slot contents may be
invalidated by any subsequent manipulation of the tuplesort's state".
In any case it'd be a good idea to delineate safe usage patterns, perhaps
"copy=FALSE is recommended only when the next tuplesort manipulation will
be another tuplesort_gettupleslot fetch into the same slot."
There are several other uses of "call here", both in this patch and
pre-existing in tuplesort.c, that I find equally vague and unsatisfactory.
Let's try to improve that.
regards, tom lane
On Wed, Jan 25, 2017 at 2:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I looked at the 0002 patch, and while the code is probably OK, I am > dissatisfied with this API spec: > > + * If copy is TRUE, the slot receives a copied tuple that will stay valid > + * regardless of future manipulations of the tuplesort's state. Memory is > + * owned by the caller. If copy is FALSE, the slot may just receive a pointer > + * to a tuple held within the tuplesort. The latter is more efficient, but > + * the slot contents may be corrupted if there is another call here before > + * previous slot contents are used. > > What does "here" mean? If that means specifically "another call of > tuplesort_gettupleslot", say so. If "here" refers to the whole module, > it would be better to say something like "the slot contents may be > invalidated by any subsequent manipulation of the tuplesort's state". > In any case it'd be a good idea to delineate safe usage patterns, perhaps > "copy=FALSE is recommended only when the next tuplesort manipulation will > be another tuplesort_gettupleslot fetch into the same slot." I agree with your analysis. It means "another call to tuplesort_gettupleslot", but I believe that it would be safer (more future-proof) to actually specify "the slot contents may be invalidated by any subsequent manipulation of the tuplesort's state" instead. > There are several other uses of "call here", both in this patch and > pre-existing in tuplesort.c, that I find equally vague and unsatisfactory. > Let's try to improve that. Should I write a patch along those lines? -- Peter Geoghegan
Peter Geoghegan <pg@heroku.com> writes:
> It means "another call to tuplesort_gettupleslot", but I believe that
> it would be safer (more future-proof) to actually specify "the slot
> contents may be invalidated by any subsequent manipulation of the
> tuplesort's state" instead.
WFM.
>> There are several other uses of "call here", both in this patch and
>> pre-existing in tuplesort.c, that I find equally vague and unsatisfactory.
>> Let's try to improve that.
> Should I write a patch along those lines?
Please. You might want to hit the existing ones with a separate patch,
but it doesn't much matter; I'd be just as happy with a patch that did
both things.
regards, tom lane
On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Please. You might want to hit the existing ones with a separate patch, > but it doesn't much matter; I'd be just as happy with a patch that did > both things. Got it. -- Peter Geoghegan
[ in the service of closing out this thread... ]
Peter Geoghegan <pg@heroku.com> writes:
> Finally, 0003-* is a Valgrind suppression borrowed from my parallel
> CREATE INDEX patch. It's self-explanatory.
Um, I didn't find it all that self-explanatory. Why wouldn't we want
to avoid writing undefined data? I think the comment at least needs
to explain exactly what part of the written data might be uninitialized.
And I'd put the comment into valgrind.supp, too, not in the commit msg.
Also, the suppression seems far too broad. It would for instance
block any complaint about a write() invoked via an elog call from
any function invoked from any LogicalTape* function, no matter
how far removed.
regards, tom lane
On Thu, Jan 26, 2017 at 8:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > [ in the service of closing out this thread... ] > > Peter Geoghegan <pg@heroku.com> writes: >> Finally, 0003-* is a Valgrind suppression borrowed from my parallel >> CREATE INDEX patch. It's self-explanatory. > > Um, I didn't find it all that self-explanatory. Why wouldn't we want > to avoid writing undefined data? I think the comment at least needs > to explain exactly what part of the written data might be uninitialized. > And I'd put the comment into valgrind.supp, too, not in the commit msg. > > Also, the suppression seems far too broad. It would for instance > block any complaint about a write() invoked via an elog call from > any function invoked from any LogicalTape* function, no matter > how far removed. It seems like a new patch will be provided, so moved to next CF with "waiting on author". -- Michael
Peter, On 2/1/17 12:59 AM, Michael Paquier wrote: > On Thu, Jan 26, 2017 at 8:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> [ in the service of closing out this thread... ] >> >> Peter Geoghegan <pg@heroku.com> writes: >>> Finally, 0003-* is a Valgrind suppression borrowed from my parallel >>> CREATE INDEX patch. It's self-explanatory. >> >> Um, I didn't find it all that self-explanatory. Why wouldn't we want >> to avoid writing undefined data? I think the comment at least needs >> to explain exactly what part of the written data might be uninitialized. >> And I'd put the comment into valgrind.supp, too, not in the commit msg. >> >> Also, the suppression seems far too broad. It would for instance >> block any complaint about a write() invoked via an elog call from >> any function invoked from any LogicalTape* function, no matter >> how far removed. It looks like we are waiting on a new patch. Do you know when you will have that ready? Thanks, -- -David david@pgmasters.net
Hi Peter, On 3/2/17 9:43 AM, David Steele wrote: > Peter, > > On 2/1/17 12:59 AM, Michael Paquier wrote: >> On Thu, Jan 26, 2017 at 8:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> [ in the service of closing out this thread... ] >>> >>> Peter Geoghegan <pg@heroku.com> writes: >>>> Finally, 0003-* is a Valgrind suppression borrowed from my parallel >>>> CREATE INDEX patch. It's self-explanatory. >>> >>> Um, I didn't find it all that self-explanatory. Why wouldn't we want >>> to avoid writing undefined data? I think the comment at least needs >>> to explain exactly what part of the written data might be uninitialized. >>> And I'd put the comment into valgrind.supp, too, not in the commit msg. >>> >>> Also, the suppression seems far too broad. It would for instance >>> block any complaint about a write() invoked via an elog call from >>> any function invoked from any LogicalTape* function, no matter >>> how far removed. > > It looks like we are waiting on a new patch. Do you know when you will > have that ready? It's been a while since there was a new patch or any activity on this thread. If you need more time to produce a patch, please post an explanation for the delay and a schedule for the new patch. If no patch or explanation is is posted by 2017-03-16 AoE I will mark this submission "Returned with Feedback". Thanks, -- -David david@pgmasters.net
On Mon, Mar 13, 2017 at 8:23 AM, David Steele <david@pgmasters.net> wrote: > It's been a while since there was a new patch or any activity on this > thread. > > If you need more time to produce a patch, please post an explanation for > the delay and a schedule for the new patch. If no patch or explanation > is is posted by 2017-03-16 AoE I will mark this submission > "Returned with Feedback". Apologies for the delay on this. I intend to get back to it before that time. -- Peter Geoghegan
On Wed, Jan 25, 2017 at 3:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Um, I didn't find it all that self-explanatory. Why wouldn't we want > to avoid writing undefined data? For roughly the same reason we'd want to avoid it in existing cases that are next to the proposed new suppression. We happen to not need to initialize the data, but the interface we're using still requires that we write at a coarser granularity than bytes. logtape.c always writes whole blocks at a time. > Also, the suppression seems far too broad. It would for instance > block any complaint about a write() invoked via an elog call from > any function invoked from any LogicalTape* function, no matter > how far removed. Writing blocks doesn't just happen in what tuplesort.c or even logtape.c would consider to be a write path -- it happens when logtape.c has a dirty buffer that it cleans. Plus you have double buffering here -- buffile.c manages its own BLCKSZ buffer at the end of the BufFile struct. IIRC the reason I did things this way is because both LogicalTapeRead() and LogicalTapeWrite() both appeared in offending stack traces, and ltsWriteBlock() would not have plugged that, because ltsReadBlock() could be involved instead. I don't remember the exact details offhand, so I will have to look into it again. -- Peter Geoghegan
On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan <pg@heroku.com> wrote: > On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Please. You might want to hit the existing ones with a separate patch, >> but it doesn't much matter; I'd be just as happy with a patch that did >> both things. > > Got it. Attached is a patch that does both things at once. The internal function tuplesort_gettuple_common() still mentions repeated fetches, since that context matters to its internal callers. The various external-facing functions have a simpler, stricter contract, as discussed. I didn't end up adding a line like "copy=FALSE is recommended only when the next tuplesort manipulation will be another tuplesort_gettupleslot fetch into the same slot", which you suggested. When the tuplesort state machine is in any state following "performing" a sort, there are very few remaining sane manipulations. Just things like skipping or seeking around for tuples, and actually ending the tuplesort and releasing resources. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
Hi Anastasia, On 3/13/17 9:14 PM, Peter Geoghegan wrote: > On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan <pg@heroku.com> wrote: >> On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Please. You might want to hit the existing ones with a separate patch, >>> but it doesn't much matter; I'd be just as happy with a patch that did >>> both things. >> >> Got it. > > Attached is a patch that does both things at once. The internal > function tuplesort_gettuple_common() still mentions repeated fetches, > since that context matters to its internal callers. The various > external-facing functions have a simpler, stricter contract, as > discussed. > > I didn't end up adding a line like "copy=FALSE is recommended only > when the next tuplesort manipulation will be another > tuplesort_gettupleslot fetch into the same slot", which you suggested. > When the tuplesort state machine is in any state following > "performing" a sort, there are very few remaining sane manipulations. > Just things like skipping or seeking around for tuples, and actually > ending the tuplesort and releasing resources. You are signed up to review this patch. Do you know when you'll have a chance to do that? Thanks, -- -David david@pgmasters.net
On 2017-03-13 18:14:07 -0700, Peter Geoghegan wrote:
> From 5351b5db257cb39832647d9117465c0217e6268b Mon Sep 17 00:00:00 2001
> From: Peter Geoghegan <pg@bowt.ie>
> Date: Thu, 13 Oct 2016 10:54:31 -0700
> Subject: [PATCH 1/2] Avoid copying within tuplesort_gettupleslot().
s/Avoid/Allow to avoid/
> Add a "copy" argument to make it optional to receive a copy of caller
> tuple that is safe to use following a subsequent manipulating of
> tuplesort's state. This is a performance optimization. Most existing
> tuplesort_gettupleslot() callers are made to opt out of copying.
> Existing callers that happen to rely on the validity of tuple memory
> beyond subsequent manipulations of the tuplesort request their own copy.
>
> This brings tuplesort_gettupleslot() in line with
> tuplestore_gettupleslot(). In the future, a "copy" tuplesort_getdatum()
> argument may be added, that similarly allows callers to opt out of
> receiving their own copy of tuple.
>
> In passing, clarify assumptions that callers of other tuplesort fetch
> routines may make about tuple memory validity, per gripe from Tom Lane.
> ---
> src/backend/executor/nodeAgg.c | 10 +++++++---
> src/backend/executor/nodeSort.c | 5 +++--
> src/backend/utils/adt/orderedsetaggs.c | 5 +++--
> src/backend/utils/sort/tuplesort.c | 28 +++++++++++++++++-----------
> src/include/utils/tuplesort.h | 2 +-
> 5 files changed, 31 insertions(+), 19 deletions(-)
>
> diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executor/nodeAgg.c
> index aa08152..b650f71 100644
> --- a/src/backend/executor/nodeAgg.c
> +++ b/src/backend/executor/nodeAgg.c
> @@ -570,6 +570,10 @@ initialize_phase(AggState *aggstate, int newphase)
> * Fetch a tuple from either the outer plan (for phase 0) or from the sorter
> * populated by the previous phase. Copy it to the sorter for the next phase
> * if any.
> + *
> + * Callers cannot rely on memory for tuple in returned slot remaining valid
> + * past any subsequent manipulation of the sorter, such as another fetch of
> + * input from sorter. (The sorter may recycle memory.)
> */
It's not just the sorter, right? I'd just rephrase that the caller
cannot rely on tuple to stay valid beyond a single call.
> static bool
> tuplesort_gettuple_common(Tuplesortstate *state, bool forward,
> @@ -2091,12 +2092,15 @@ tuplesort_gettuple_common(Tuplesortstate *state, bool forward,
> * NULL value in leading attribute will set abbreviated value to zeroed
> * representation, which caller may rely on in abbreviated inequality check.
> *
> - * The slot receives a copied tuple (sometimes allocated in caller memory
> - * context) that will stay valid regardless of future manipulations of the
> - * tuplesort's state.
> + * If copy is TRUE, the slot receives a copied tuple that will stay valid
> + * regardless of future manipulations of the tuplesort's state. Memory is
> + * owned by the caller. If copy is FALSE, the slot will just receive a
> + * pointer to a tuple held within the tuplesort, which is more efficient,
> + * but only safe for callers that are prepared to have any subsequent
> + * manipulation of the tuplesort's state invalidate slot contents.
> */
Hm. Do we need to note anything about how long caller memory needs to
live? I think we'd get into trouble if the caller does a memory context
reset, without also clearing the slot?
> bool
> -tuplesort_gettupleslot(Tuplesortstate *state, bool forward,
> +tuplesort_gettupleslot(Tuplesortstate *state, bool forward, bool copy,
> TupleTableSlot *slot, Datum *abbrev)
> {
> MemoryContext oldcontext = MemoryContextSwitchTo(state->sortcontext);
> @@ -2113,8 +2117,10 @@ tuplesort_gettupleslot(Tuplesortstate *state, bool forward,
> if (state->sortKeys->abbrev_converter && abbrev)
> *abbrev = stup.datum1;
>
> - stup.tuple = heap_copy_minimal_tuple((MinimalTuple) stup.tuple);
> - ExecStoreMinimalTuple((MinimalTuple) stup.tuple, slot, true);
> + if (copy)
> + stup.tuple = heap_copy_minimal_tuple((MinimalTuple) stup.tuple);
> +
> + ExecStoreMinimalTuple((MinimalTuple) stup.tuple, slot, copy);
> return true;
Other than these minimal adjustments, this looks good to go to me.
- Andres
On Tue, Apr 4, 2017 at 1:32 PM, Andres Freund <andres@anarazel.de> wrote: > s/Avoid/Allow to avoid/ WFM. >> + * >> + * Callers cannot rely on memory for tuple in returned slot remaining valid >> + * past any subsequent manipulation of the sorter, such as another fetch of >> + * input from sorter. (The sorter may recycle memory.) >> */ > > It's not just the sorter, right? I'd just rephrase that the caller > cannot rely on tuple to stay valid beyond a single call. It started that way, but changed on the basis of Tom's feedback. I would be equally happy with either wording. >> static bool >> tuplesort_gettuple_common(Tuplesortstate *state, bool forward, >> @@ -2091,12 +2092,15 @@ tuplesort_gettuple_common(Tuplesortstate *state, bool forward, >> * NULL value in leading attribute will set abbreviated value to zeroed >> * representation, which caller may rely on in abbreviated inequality check. >> * >> - * The slot receives a copied tuple (sometimes allocated in caller memory >> - * context) that will stay valid regardless of future manipulations of the >> - * tuplesort's state. >> + * If copy is TRUE, the slot receives a copied tuple that will stay valid >> + * regardless of future manipulations of the tuplesort's state. Memory is >> + * owned by the caller. If copy is FALSE, the slot will just receive a >> + * pointer to a tuple held within the tuplesort, which is more efficient, >> + * but only safe for callers that are prepared to have any subsequent >> + * manipulation of the tuplesort's state invalidate slot contents. >> */ > > Hm. Do we need to note anything about how long caller memory needs to > live? I think we'd get into trouble if the caller does a memory context > reset, without also clearing the slot? Since we arrange to have caller explicitly own memory (it's always in their own memory context (current context), which is not the case with other similar routines), it's 100% the caller's problem. As I assume you know, convention in executor around resource management of memory like this is pretty centralized within ExecStoreTuple(), and nearby routines. In general, the executor is more or less used to having this be its problem alone, and is pessimistic about memory lifetime unless otherwise noted. > Other than these minimal adjustments, this looks good to go to me. Cool. I'll try to get out a revision soon, maybe later today, including an updated 0002-* (Valgrind suppression), which I have not forgotten about. -- Peter Geoghegan
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation: not tested The patch looks fine to me. Changes are clear and all functions are commented properly. So I marked it "Ready for committer". The new status of this patch is: Ready for Committer
On 2017-04-04 13:49:11 -0700, Peter Geoghegan wrote: > On Tue, Apr 4, 2017 at 1:32 PM, Andres Freund <andres@anarazel.de> wrote: > >> static bool > >> tuplesort_gettuple_common(Tuplesortstate *state, bool forward, > >> @@ -2091,12 +2092,15 @@ tuplesort_gettuple_common(Tuplesortstate *state, bool forward, > >> * NULL value in leading attribute will set abbreviated value to zeroed > >> * representation, which caller may rely on in abbreviated inequality check. > >> * > >> - * The slot receives a copied tuple (sometimes allocated in caller memory > >> - * context) that will stay valid regardless of future manipulations of the > >> - * tuplesort's state. > >> + * If copy is TRUE, the slot receives a copied tuple that will stay valid > >> + * regardless of future manipulations of the tuplesort's state. Memory is > >> + * owned by the caller. If copy is FALSE, the slot will just receive a > >> + * pointer to a tuple held within the tuplesort, which is more efficient, > >> + * but only safe for callers that are prepared to have any subsequent > >> + * manipulation of the tuplesort's state invalidate slot contents. > >> */ > > > > Hm. Do we need to note anything about how long caller memory needs to > > live? I think we'd get into trouble if the caller does a memory context > > reset, without also clearing the slot? > > Since we arrange to have caller explicitly own memory (it's always in > their own memory context (current context), which is not the case with > other similar routines), it's 100% the caller's problem. As I assume > you know, convention in executor around resource management of memory > like this is pretty centralized within ExecStoreTuple(), and nearby > routines. In general, the executor is more or less used to having this > be its problem alone, and is pessimistic about memory lifetime unless > otherwise noted. I'm not sure you entirely got my point here. If tuplesort_gettupleslot is called with copy = true, it'll store that tuple w/ ExecStoreMinimalTuple passing shouldFree = copy = true. If the caller is in a short-lived context, e.g. some expression context, and resets that context before the slot is cleared (either by storing another tuple or ExecClearTuple()) you'll get a double free, because the context has freed the tuple in bulk, and thenif (slot->tts_shouldFree) heap_freetuple(slot->tts_tuple); will do its work. Now, that's obviously not a problem for existing code, because it worked that way for a long time - I just was wondering whether that needs to be called out. - Andres
On Thu, Apr 6, 2017 at 2:05 PM, Andres Freund <andres@anarazel.de> wrote: > I'm not sure you entirely got my point here. If tuplesort_gettupleslot > is called with copy = true, it'll store that tuple w/ > ExecStoreMinimalTuple passing shouldFree = copy = true. If the caller > is in a short-lived context, e.g. some expression context, and resets > that context before the slot is cleared (either by storing another tuple > or ExecClearTuple()) you'll get a double free, because the context has > freed the tuple in bulk, and then > if (slot->tts_shouldFree) > heap_freetuple(slot->tts_tuple); > will do its work. Calling ExecClearTuple() will mark the slot "tts_shouldFree = false" -- you only have a problem when a memory context is reset, which obviously cannot be accounted for by ExecClearTuple(). ISTM that ResetExprContext() is kind of called to "make sure" that memory is freed in a short-lived expression context, at a level up from any ExecStoreMinimalTuple()/ExecClearTuple() style memory management. The conventions are not centrally documented, AFAIK, but this still seems natural enough to me. Per-tuple contexts tend to be associated with expression contexts. In any case, I'm not sure where you'd centrally document the conventions. Although, it seems clear that it wouldn't be anywhere this patch currently touches. The executor README, perhaps? -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/
On 2017-03-13 18:14:07 -0700, Peter Geoghegan wrote: > On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan <pg@heroku.com> wrote: > > On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Please. You might want to hit the existing ones with a separate patch, > >> but it doesn't much matter; I'd be just as happy with a patch that did > >> both things. > > > > Got it. > > Attached is a patch that does both things at once. Pushed with very minor wording changes. Thanks, Andres
On Thu, Apr 6, 2017 at 2:50 PM, Andres Freund <andres@anarazel.de> wrote: > Pushed with very minor wording changes. Thanks Andres. -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/
On Thu, Apr 6, 2017 at 2:50 PM, Andres Freund <andres@anarazel.de> wrote: > Pushed with very minor wording changes. This had a typo: + * If copy is true, the slot receives a copied tuple that'll that will stay -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/
On 2017-04-06 14:57:56 -0700, Peter Geoghegan wrote: > On Thu, Apr 6, 2017 at 2:50 PM, Andres Freund <andres@anarazel.de> wrote: > > Pushed with very minor wording changes. > > This had a typo: > > + * If copy is true, the slot receives a copied tuple that'll that will stay Belatedly fixed.