pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Andrew Gierth <rhodiumtoad@postgresql.org>
Cc: PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Cc: Kevin Grittner <kgrittn@gmail.com>
Subject: Re: BUG #14808: V10-beta4, backend abort
Date: Wed, 13 Sep 2017 19:54:48 -0400
Message-ID: <1683.1505346888@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>

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



view thread (28+ messages)  latest in thread

Message-ID: <1683.1505346888@sss.pgh.pa.us>
Permalink:  ../1683.1505346888@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1683.1505346888@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, thomas.munro@enterprisedb.com, michael.paquier@gmail.com, rhodiumtoad@postgresql.org, kgrittn@gmail.com
  Subject: Re: BUG #14808: V10-beta4, backend abort
  In-Reply-To: <1683.1505346888@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox