On Fri, Dec 3, 2021 at 9:02 PM Tom Lane wrote:
>
> Dilip Kumar writes:
> > On Thu, Dec 2, 2021 at 9:35 AM Dilip Kumar wrote:
> >> I think there is no such view or anything which tells about which
> >> backend or transaction has more than 64 sub transaction. But if we
> >> are ready to modify th
On 5/12/2021, at 9:04 AM, Tom Lane wrote:
> So that probably means that you weren't careful about allocating your
> own state data in the long-lived context (agg_context), and so it
> got freed between calls.
It turns out I wasn’t careful about setting isnull on the passed in state
argument. Aft
On Fri, 2021-12-03 at 21:33 +0100, Daniel Frey wrote:
> But the real issue, at least for me, is PQfinish(). Considering that my
> application is not
> allowed to hang (or crash, leak, ...), what should I do in case of a timeout?
I am tempted to say that you shouldn't use TCP with the requirement
Matt Magoffin writes:
> On 5/12/2021, at 5:16 AM, Tom Lane wrote:
>> Are you testing in an --enable-cassert build? If not, do that;
>> it might make the cause of the crashes more apparent, thanks to
>> CLOBBER_FREED_MEMORY and other debug support.
> I did build with --enable-cassert, and I did
On 5/12/2021, at 5:16 AM, Tom Lane wrote:
> Calling numeric_avg_accum in the agg_context is unnecessary, and possibly
> counterproductive (it might leak memory in that context, since like all
> other aggregates it assumes it's called in a short-lived context).
OK, thanks for that, I’ll remove t
Matt Magoffin writes:
> So far, I have been working on average support via the vec_to_mean()
> aggregate, and my aggregate's [2] transition function sets up a
> FunctionCallInfo for the numeric_avg_accum() [3] function and then loops over
> the input array elements, calling numeric_avg_accum()
