Hi,
On 2018-12-16 17:30:30 -0300, Alvaro Herrera wrote:
> On 2018-Dec-16, Andres Freund wrote:
>
> > > I think there's a one-line fix, attached: just add the number of changes
> > > in a subxact to nentries_mem when the transaction is assigned to the
> > > parent.
> >
> > Isn't this going to cau
On 2018-Dec-16, Andres Freund wrote:
> > I think there's a one-line fix, attached: just add the number of changes
> > in a subxact to nentries_mem when the transaction is assigned to the
> > parent.
>
> Isn't this going to cause significant breakage, because we rely on
> nentries_mem to be accura
Hi,
On 2018-12-16 12:06:16 -0300, Alvaro Herrera wrote:
> Found this on Postgres 9.6, but I think it affects back to 9.4.
>
> I've seen a case where reorderbuffer keeps very large amounts of memory
> in use, without spilling to disk, if the main transaction does little or
> no changes and many su
On 12/16/18 4:06 PM, Alvaro Herrera wrote:
> Hello
>
> Found this on Postgres 9.6, but I think it affects back to 9.4.
>
> I've seen a case where reorderbuffer keeps very large amounts of memory
> in use, without spilling to disk, if the main transaction does little or
> no changes and many subtr
Hello
Found this on Postgres 9.6, but I think it affects back to 9.4.
I've seen a case where reorderbuffer keeps very large amounts of memory
in use, without spilling to disk, if the main transaction does little or
no changes and many subtransactions execute changes just below the
threshold to sp
