From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: balazs@obiserver.hu
Cc: pgsql-bugs@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: [BUGS] BUG #14825: enum type: unsafe use?
Date: Sat, 23 Sep 2017 18:06:21 -0400
Message-ID: <25662.1506204381@sss.pgh.pa.us> (raw)
In-Reply-To: <4942e2c0-3302-f496-d4c1-a967f77d0143@2ndQuadrant.com>
References: <20170922185904.1448.16585@wrigleys.postgresql.org>
<15165.1506116768@sss.pgh.pa.us>
<3cece400-af56-7145-2e65-f044de1b0b68@2ndQuadrant.com>
<28968.1506136792@sss.pgh.pa.us>
<f29e2d7e-7d71-b3b7-2fed-d52bddd8ca61@2ndQuadrant.com>
<24380.1506179805@sss.pgh.pa.us>
<16272.1506189656@sss.pgh.pa.us>
<928f5974-151f-0273-0221-fac213e7624f@2ndQuadrant.com>
<19137.1506196325@sss.pgh.pa.us>
<4942e2c0-3302-f496-d4c1-a967f77d0143@2ndQuadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> OK, I think I'm convinced. Here's is the WIP code I put together for the
> blacklist. I'm was looking for a place to put the init call, but since
> it's possibly not going anywhere I stopped :-) . My initial thought
> about substransactions was that we should ignore them for this purpose
> (That's why I used TopTransactionContext for the table).
For the blacklist, I agree we could just ignore subtransactions: all
subtransaction levels are equally uncommitted for this purpose, and
leaving entries from failed subtransactions in place seems like a
non-issue, since they'd never be referenced again. (Well, barring OID
wraparound and an enum-value-OID collision while the transaction runs,
but I think we can ignore that as having probability epsilon.)
But you need to actually put the table in TopTransactionContext, not
CurTransactionContext ;-). Also, I don't think you need an init call
so much as an end-of-transaction cleanup call. Maybe call it
AtEOXactEnum(), for consistency with other functions called in the
same area.
> w.r.t. table size - how large? I confess I haven't seen any systems with
> more than a few hundred enum types. But even a million or two shouldn't
> consume a huge amount of memory, should it?
Dynahash tables are self-expanding, so I don't see a need to stress about
that too much. Anything in 10-100 seems reasonable for initial size.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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, andrew.dunstan@2ndquadrant.com, balazs@obiserver.hu, pgsql-hackers@postgresql.org
Subject: Re: [BUGS] BUG #14825: enum type: unsafe use?
In-Reply-To: <25662.1506204381@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