Andres Freund writes:
> On second thought, it might not be so good looking - the queries results
> are independent of the data from merge-append. So we only check that we
> don't crash and not that the results make any sense. How about the
> attached patch?
Good point --- pushed.
On 2013-08-30 19:28:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
> >> Not sure. It's pretty disturbing that this wasn't caught earlier;
> >> it seems to me that means there's no regression coverage that hits
> >> ExecReScanMergeAppend. Howev
Andres Freund writes:
> On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
>> Not sure. It's pretty disturbing that this wasn't caught earlier;
>> it seems to me that means there's no regression coverage that hits
>> ExecReScanMergeAppend. However, I don't much like this specific test case
>> because
On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-08-30 23:05:25 +0200, Andres Freund wrote:
> >> ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
> >> binaryheap. Thus no new elements fit.
>
> > Ok, patch for that attached.
>
> I think the comme
Andres Freund writes:
> On 2013-08-30 23:05:25 +0200, Andres Freund wrote:
>> ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
>> binaryheap. Thus no new elements fit.
> Ok, patch for that attached.
I think the comments need a bit of copy-editing, but looks good otherwise.
Will
On Aug 31, 2013, at 12:22 AM, Tom Lane wrote:
> Or even more to the point, can you apply the just-posted patch and see
> if the problem goes away for you?
Will do.
At our current organic load though, we likely wouldn't get any good
confirmation either way this week.
I'll see if I can set up so
Andres Freund writes:
> Terje, do you use read committed or repeatable read/serializable?
Or even more to the point, can you apply the just-posted patch and see
if the problem goes away for you?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgres
On Aug 30, 2013, at 11:49 PM, Andres Freund wrote:
> Even better explanation: The merge append is some steps below a LockRows
> node, so the number of rescans might depend on the concurrency because
> we'll do the EvalPlanQual dance on a concurrent row update.
>
> Terje, do you use read committed
On 2013-08-30 17:23:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > No need, found the bug. And I think can build a testcase myself.
>
> > ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
> > binaryheap. Thus no new elements fit.
>
> Sounds like a bug all right, but I'm n
On 2013-08-30 23:05:25 +0200, Andres Freund wrote:
> On 2013-08-30 23:00:15 +0200, Andres Freund wrote:
> > Hi,
> >
> >
> > On 2013-08-30 20:46:27 +, te...@elde.net wrote:
> > > I'm getting "out of binary heap slots", which offcourse spoils the fun of
> > > the query.
> >
> > > Explain analy
On 30. aug. 2013, at 23:05, Andres Freund wrote:
> No need, found the bug. And I think can build a testcase myself.
Sounds good. :)
Please do let me know if there's anything I can do.
Terje
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscriptio
On Aug 30, 2013, at 10:46 PM, te...@elde.net wrote:
> The following bug has been logged on the website:
That didn't work out too well, rendering-wize.
Sending the explain analyze by email as well, hoping it'll be more readable:
Hi,
On 2013-08-30 20:46:27 +, te...@elde.net wrote:
> I'm getting "out of binary heap slots", which offcourse spoils the fun of
> the query.
> Explain analyze gives this plan (again anonymized a bit, but can send proper
> off-list):
Since I reviewed the patch that introduced that message, I
On 2013-08-30 23:00:15 +0200, Andres Freund wrote:
> Hi,
>
>
> On 2013-08-30 20:46:27 +, te...@elde.net wrote:
> > I'm getting "out of binary heap slots", which offcourse spoils the fun of
> > the query.
>
> > Explain analyze gives this plan (again anonymized a bit, but can send proper
> > o
On 2013-08-30 17:15:32 -0400, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > No need, found the bug. And I think can build a testcase myself.
> >
> > ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
> > binaryheap. Thus no new elements fit.
>
> Um. Are we missing a binaryh
On Aug 30, 2013, at 11:23 PM, Tom Lane wrote:
> Sounds like a bug all right, but I'm not convinced it explains Terje's
> report. The thing this theory doesn't explain is why would Terje be
> having trouble reproducing the failure? Seems like re-running the same
> query ought to produce the same
On 2013-08-30 17:23:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > No need, found the bug. And I think can build a testcase myself.
>
> > ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
> > binaryheap. Thus no new elements fit.
>
> Sounds like a bug all right, but I'm n
Andres Freund writes:
> No need, found the bug. And I think can build a testcase myself.
> ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
> binaryheap. Thus no new elements fit.
Sounds like a bug all right, but I'm not convinced it explains Terje's
report. The thing this the
The following bug has been logged on the website:
Bug reference: 8410
Logged by: Terje Elde
Email address: te...@elde.net
PostgreSQL version: Unsupported/Unknown
Operating system: FreeBSD
Description:
Running:
PostgreSQL 9.3beta1 on amd64-portbld-freebsd9.1, compile
Andres Freund wrote:
> No need, found the bug. And I think can build a testcase myself.
>
> ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
> binaryheap. Thus no new elements fit.
Um. Are we missing a binaryheap_clear() method?
--
Álvaro Herrerahttp://www.2n
20 matches
Mail list logo
