On Tue, Dec 10, 2024 at 4:45 PM Tom Lane wrote:
> Anyway, if you feel like rewriting that stuff, step right up.
> My feeling about it is that the law of conservation of cruft
> will prevent a replacement from being all that much cleaner,
> but maybe I'm wrong.
Thanks for the thoughts. It's always
Robert Haas writes:
> On Tue, Dec 10, 2024 at 2:53 PM Tom Lane wrote:
>> I'm thinking about something like this:
> That seems pretty good, although the last sentence seems like it might
> be a little too alarming. Maybe add "although we know of no specific
> problem" or something like that.
OK,
On Tue, Dec 10, 2024 at 2:53 PM Tom Lane wrote:
> Robert Haas writes:
> > Thanks for the research, and +1 if you feel like adding more commentary.
>
> I'm thinking about something like this:
>
> diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
> index 13f3fcdaee..7eb
Robert Haas writes:
> Thanks for the research, and +1 if you feel like adding more commentary.
I'm thinking about something like this:
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 13f3fcdaee..7ebb17fc2e 100644
--- a/src/backend/executor/execMain.c
+++ b/sr
On Tue, Dec 10, 2024 at 1:37 PM Tom Lane wrote:
> And ExecutorRun skips ExecutePlan if direction is
> NoMovementScanDirection. So unless there are gaps in pquery.c's EOF
> checks, I think we're OK: the "re-execution" call will not reach
> ExecutePlan. This could probably do with more commentary
I wrote:
> My recollection is that even before parallelism we had some plan node
> types that didn't cope well with being called again after they'd once
> returned EOF (ie a null tuple). So maybe a defense against trying to
> do that would be wise.
I spent a little time trying to run that recolle
On Tue, Dec 10, 2024 at 12:14 PM Tom Lane wrote:
> > Did you look at the commit message for
> > 691b8d59281b5177f16fe80858df921f77a8e955? IMHO, that's pretty clear
> > about what the goals of this were.
>
> Well, it's not very clear about what implementation limitations we
> are trying to protect.
Robert Haas writes:
> On Thu, Dec 5, 2024 at 8:09 PM Tom Lane wrote:
>> After looking at this further, I think this whole "run_once"
>> business is badly designed, worse documented, and redundant
>> (as well as buggy). It can be replaced with three self-contained
>> lines in ExecutePlan, as per
On Thu, Dec 5, 2024 at 8:09 PM Tom Lane wrote:
> After looking at this further, I think this whole "run_once"
> business is badly designed, worse documented, and redundant
> (as well as buggy). It can be replaced with three self-contained
> lines in ExecutePlan, as per the attached.
Did you look
I wrote:
> Yugo NAGATA writes:
>> I guess planstate is removed due to the redundancy that this is included
>> in queryDesc. If so, I think we can also remove use_parallel_mode for the
>> same reason.
> Certainly there's a bit of aesthetic judgment involved here.
After thinking awhile longer, I
Yugo NAGATA writes:
> On Sun, 08 Dec 2024 14:25:53 -0500
> Tom Lane wrote:
> - *
> - * Note: the ctid attribute is a 'junk' attribute that is removed before the
> - * user can see it
> *
> */
> This comment remove seems not rel
On Sun, 08 Dec 2024 14:25:53 -0500
Tom Lane wrote:
> I wrote:
> > After looking at this further, I think this whole "run_once"
> > business is badly designed, worse documented, and redundant
> > (as well as buggy). It can be replaced with three self-contained
> > lines in ExecutePlan, as per the
I wrote:
> After looking at this further, I think this whole "run_once"
> business is badly designed, worse documented, and redundant
> (as well as buggy). It can be replaced with three self-contained
> lines in ExecutePlan, as per the attached.
> (Obviously, the API changes in this wouldn't do f
I wrote:
> Don't like this much. I'm not sure I believe any part of this
> approach to deciding whether the portal is "run once". In any
> case, a proper fix for this needs to include actually documenting
> what that field means and does.
After looking at this further, I think this whole "run_on
Yugo Nagata writes:
> I notice that the following Assert in PortalRun fails when a same portal is
> executed more than once by an Execute message whose "max number of rows"
> is specified to zero, that is, "no limit".
> /* Set run_once flag. Shouldn't be clear if previously set. */
>
On Fri, 6 Dec 2024 06:25:49 +0900
Yugo Nagata wrote:
> Hi,
>
> I notice that the following Assert in PortalRun fails when a same portal is
> executed more than once by an Execute message whose "max number of rows"
> is specified to zero, that is, "no limit".
>
> /* Set run_once flag.
Hi,
I notice that the following Assert in PortalRun fails when a same portal is
executed more than once by an Execute message whose "max number of rows"
is specified to zero, that is, "no limit".
/* Set run_once flag. Shouldn't be clear if previously set. */
Assert(!portal->run
17 matches
Mail list logo
