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

help / color / mirror / Atom feed
From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Todd A. Cook <tcook@blackducksoftware.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Subject: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
Date: Wed, 6 Dec 2017 15:57:50 -0500
Message-ID: <20171206205750.GM4628@tamriel.snowman.net> (raw)
In-Reply-To: <20171206204616.wcect35fuj5gjde2@alap3.anarazel.de>
References: <CAEepm=3SC9zYLKhvtZbsnwf9vEpi96WCGz1rdGLofuzBau=fqA@mail.gmail.com>
	<17357.1511841783@sss.pgh.pa.us>
	<9cd29b81-7ba1-91a2-f491-9014f4ac87e6@blackducksoftware.com>
	<2a76784c-06cb-46ec-35be-9895d144b839@2ndquadrant.com>
	<263b03b1-3e1c-49ca-165a-8ac6751419c4@2ndquadrant.com>
	<20171206193545.3imvbfwjgrmuho3s@alap3.anarazel.de>
	<ebe8b411-006e-7863-3c60-67ddafe1c636@2ndquadrant.com>
	<790BC80E-D8E5-499B-A1E3-8EE0752B53ED@anarazel.de>
	<06523583-b9c5-1424-ef0a-1fc8063e9ed7@2ndquadrant.com>
	<20171206204616.wcect35fuj5gjde2@alap3.anarazel.de>

Andres, all,

* Andres Freund (andres@anarazel.de) wrote:
> On 2017-12-06 21:38:42 +0100, Tomas Vondra wrote:
> > FWIW I've constructed the data sets for two reasons - to convince myself
> > that my understanding of the simplehash code is correct, and to provide
> > a data set triggering the other growth condition in simplehash code. My
> > understanding is that if we stop growing the table after the load factor
> > drops below some threshold (as TL proposed earlier in this thread), it
> > should address both of these cases.
> 
> Yea, I'm not adverse to adding a few stopgaps that break in a less
> annoying manner. WAll I'm saying is that I don't think we need to be
> super concerned about this specific way of breaking things.

I think I'm agreeing with Tomas here when I say that we shouldn't have a
system that breaks in the "tries to allocate infinite memory" way when
the load factor drops far below some reasonable threshold and that we
*should* be concerned that we have this problem in the existing
implementation.  It's bad, and we should care about that and fix it.

Running forever in a loop isn't great either, but at least you only
expend at most one CPU to it and can go kill it, assuming we have an
appropriate CHECK_FOR_INTERRUPTS() placement.  Running the box out of
memory can lead to other things *failing* (even entirely reasonable
things!), not just being slower.  That's an important difference.

Thanks!

Stephen

Attachments:

  signature.asc (application/pgp-signature, 818B) download

view thread (70+ messages)  latest in thread

Message-ID: <20171206205750.GM4628@tamriel.snowman.net>
Permalink:  ../20171206205750.GM4628@tamriel.snowman.net/
Also on:    postgresql.org/message-id/20171206205750.GM4628@tamriel.snowman.net

 · 

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: sfrost@snowman.net, andres@anarazel.de, tomas.vondra@2ndquadrant.com, tcook@blackducksoftware.com, tgl@sss.pgh.pa.us, thomas.munro@enterprisedb.com
  Subject: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
  In-Reply-To: <20171206205750.GM4628@tamriel.snowman.net>

* 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