Date: Fri, 12 Jan 2018 14:06:12 -0800
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>,
	Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>,
	Bruce Momjian <bruce@momjian.us>,
	"David E. Wheeler" <david@justatheory.com>,
	Christophe Pettus <christophe.pettus@pgexperts.com>,
	Postgres-Bugs <pgsql-bugs@postgresql.org>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?
Message-ID: <20180112220612.jvblkkumiifb5355@alap3.anarazel.de>
References: <5161729c-4597-8a41-f4e2-c7d97e84d86e@2ndQuadrant.com>
 <32160eb9-60df-746b-bbc0-dd232b993d6d@2ndQuadrant.com>
 <10135.1506538374@sss.pgh.pa.us>
 <a19b6647-5e64-57dc-5c34-06d9f982bff0@2ndQuadrant.com>
 <20171004013856.2xzd2nw6oufbbtms@alap3.anarazel.de>
 <CA+TgmobNQeCTY2v+tLzO54y8BLUrp+ECaKaUxs+Mp2Hb-BKCxA@mail.gmail.com>
 <CAEepm=3SKxCi=P8UnrZ2yhgA8UdnJvAoq_Oxo4R4kG2Wpf-tZg@mail.gmail.com>
 <CA+TgmoaJ-8QtU4qRdd73uOEkG1pQu1hdsrd++OmkkxRBYyR6ig@mail.gmail.com>
 <CAEepm=2fzMEzjeJNdaADx501G9QtF2UfZ=Hi50cDb7daE31W0Q@mail.gmail.com>
 <CA+TgmobfvQzP6qnnYVBR1vojDmutsbu3yzbCEtgCA0YC__bz-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmobfvQzP6qnnYVBR1vojDmutsbu3yzbCEtgCA0YC__bz-w@mail.gmail.com>
Precedence: bulk

On 2018-01-12 07:51:34 -0500, Robert Haas wrote:
> On Thu, Jan 11, 2018 at 11:01 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
> > Are you saying we should do the work now to create a per-transaction
> > DSM segment + DSA area + thing that every backend attaches to?
> 
> No, I was just thinking you could stuff it into the per-parallel-query
> DSM/DSA.  But...
> 
> > I didn't think creating backend local hash tables would be a problem
> > because it's a vanishingly rare occurrence for the hash table to be
> > created at all (ie when you've altered an enum), and if created, to
> > have more than a couple of entries in it.
> 
> ...this is also a fair point.

OTOH, it seems quite likely that we'll add more transaction-lifetime
shared data (e.g. combocid), so building per-xact infrastructure
actually seems like a good idea.

Greetings,

Andres Freund