pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Stephen Frost <sfrost@snowman.net>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Postgres hackers <pgsql-hackers@postgresql.org>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Subject: Re: pg_partition_tree crashes for a non-defined relation
Date: Mon, 10 Dec 2018 08:21:22 -0500
Message-ID: <20181210132122.GI3415@tamriel.snowman.net> (raw)
In-Reply-To: <20181209223941.GA3710@paquier.xyz>
References: <20181207230540.GA12740@paquier.xyz>
	<6105.1544243612@sss.pgh.pa.us>
	<20181208065436.GC1989@paquier.xyz>
	<20181208134608.GY3415@tamriel.snowman.net>
	<20181208231507.GA1833@paquier.xyz>
	<20181209174815.GD3415@tamriel.snowman.net>
	<16590.1544378743@sss.pgh.pa.us>
	<20181209185452.GF3415@tamriel.snowman.net>
	<19520.1544382449@sss.pgh.pa.us>
	<20181209223941.GA3710@paquier.xyz>

Greetings,

* Michael Paquier (michael@paquier.xyz) wrote:
> On Sun, Dec 09, 2018 at 02:07:29PM -0500, Tom Lane wrote:
> > Stephen Frost <sfrost@snowman.net> writes:
> >> I don't entirely buy off on the argument that it's code that's 'highly
> >> unlikely to break once written' though- we do add new relkinds from time
> >> to time, for example.  Perhaps we could have these functions run just
> >> once per relkind.
> > 
> > Well, the relevant code is likely to be "if relkind is not x, y, or z,
> > then PG_RETURN_NULL".  If we add a new relkind and forget to consider the
> > function, the outcome is a NULL result that perhaps should not have been
> > NULL ... but a test like this won't help us notice that.
> 
> Yes, in order to prevent problems with newly-introduced relkinds, I
> think that the checks within functions should be careful to check only
> for relkinds that they support, and not list those they do not support.

Yes, but it's certainly possible for someone to add another relkind to
that list without looking through the rest of the function carefully
enough.  Perhaps not the best example.  I still don't like the
assumption that the code won't be broken once it's written correctly the
first time though, and I continue to feel that it would be good to have
regression tests which run these functions with interesting arguments.

I also agree that we don't want to make the regression tests take a lot
of additional time.

Thanks!

Stephen

Attachments:

  [application/pgp-signature] signature.asc (818B, ../20181210132122.GI3415@tamriel.snowman.net/2-signature.asc)
  download

view thread (36+ messages)  latest in thread

Message-ID: <20181210132122.GI3415@tamriel.snowman.net>
Permalink:  ../20181210132122.GI3415@tamriel.snowman.net/
Also on:    postgresql.org/message-id/20181210132122.GI3415@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-hackers@postgresql.org
  Cc: sfrost@snowman.net, michael@paquier.xyz, tgl@sss.pgh.pa.us, Langote_Amit_f8@lab.ntt.co.jp
  Subject: Re: pg_partition_tree crashes for a non-defined relation
  In-Reply-To: <20181210132122.GI3415@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