tuplesort_gettuple_common() and *should_free argument

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[ 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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