From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
cc: Michael Paquier <michael.paquier@gmail.com>,
        Andrew Gierth <rhodiumtoad@postgresql.org>,
        PostgreSQL mailing lists <pgsql-bugs@postgresql.org>,
        Kevin Grittner <kgrittn@gmail.com>
Subject: Re: BUG #14808: V10-beta4, backend abort
In-reply-to: 
 <CAEepm=3h5CBfx1+7hoNH2yUZnFoJ97PgAp8yc1ce_P57pWwpZw@mail.gmail.com>
References: <20170909064853.25630.12825@wrigleys.postgresql.org>
 <CAB7nPqRBE35VOtvU=VfV66sqvV5L+raGi8R64WBD3jjS3G4HZA@mail.gmail.com>
 <3702.1504976930@sss.pgh.pa.us> <9324.1504983594@sss.pgh.pa.us>
 <25326.1505070173@sss.pgh.pa.us>
 <CAEepm=0rNhRe8Zjf46H__au+KrAYktbefpNyFHVqn9ZfFyKV_Q@mail.gmail.com>
 <14016.1505135324@sss.pgh.pa.us> <8201.1505149431@sss.pgh.pa.us>
 <CAEepm=2P2a4hO8dED+1g0emRUbWFmc85Ahug4YbbrO0GYwYkiA@mail.gmail.com>
 <31365.1505342642@sss.pgh.pa.us>
 <CAEepm=0dy9BZuPTxY7UDsKstfoCwPYinvkOBPpn5rymBHeYuiA@mail.gmail.com>
 <CAEepm=3h5CBfx1+7hoNH2yUZnFoJ97PgAp8yc1ce_P57pWwpZw@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@enterprisedb.com>
	message dated "Thu, 14 Sep 2017 11:40:59 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1682.1505346888.1@sss.pgh.pa.us>
Date: Wed, 13 Sep 2017 19:54:48 -0400
Message-ID: <1683.1505346888@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

Thomas Munro <thomas.munro@enterprisedb.com> writes:
> Incidentally, understanding that made me wonder why we don't have a
> binary chunk-oriented in-memory-up-to-some-size-then-spill-to-disk
> spooling mechanism that could be used for the trigger queue itself
> (which currently doesn't know how to spill to disk and therefore can
> take your server out), including holding these tuple images directly
> (instead of spilling just the tuples in synchronised order with the
> in-memory trigger queue).

The past discussions about spilling the trigger queue have generally
concluded that by the time your event list was long enough to cause
serious pain, you already had a query that was never gonna complete.
That may be getting less true as time goes on, but I'm not sure ---
seems like RAM capacity is growing faster than CPU speed.  Anyway,
that's why it never got done.

Given the addition of transition tables, I suspect there will be
even less motivation to fix it: the right thing to do with mass
updates will be to use a TT with an after-statement trigger, and
that fixes it by putting the bulk data into a spillable tuplestore.

			regards, tom lane


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