BUG #8684: Tables with custom range domain type cannot be analyzed

Started by Brett Neumeierover 12 years ago5 messagesbugs
Jump to latest
#1Brett Neumeier
bneumeier@gmail.com

The following bug has been logged on the website:

Bug reference: 8684
Logged by: Brett Neumeier
Email address: bneumeier@gmail.com
PostgreSQL version: 9.3.2
Operating system: Ubuntu Linux 13.04 64-bit
Description:

In 9.3.2 and master HEAD (3b97e6823b), in a freshly-created postgresql
database (with all tests passing from "make check-world"), this sequence:

-----cut here-----
CREATE DOMAIN range_domain AS tstzrange
CONSTRAINT exclusive_upper CHECK ((NOT upper_inc(VALUE)))
CONSTRAINT inclusive_lower CHECK (lower_inc(VALUE));

CREATE TABLE cannot_analyze (
rng range_domain NOT NULL
);

VACUUM ANALYZE;
-----cut here-----

results in the analyze failing with "ERROR: type 16385 is not a range type"
rather than succeeding.

(This error is being emitted from range_get_typcache because the result of
lookup_type_cache(rngtypid, TYPECACHE_RANGE_INFO) has a rngelemtype of NULL,
but I haven't tried to figure out why that is or what it should be instead.)

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

#2Brett Neumeier
bneumeier@gmail.com
In reply to: Brett Neumeier (#1)
Re: BUG #8684: Tables with custom range domain type cannot be analyzed

On Tue, Dec 17, 2013 at 11:10 AM, <bneumeier@gmail.com> wrote:

The following bug has been logged on the website:

Bug reference: 8684
Logged by: Brett Neumeier
Email address: bneumeier@gmail.com
PostgreSQL version: 9.3.2
Operating system: Ubuntu Linux 13.04 64-bit
Description:

In 9.3.2 and master HEAD (3b97e6823b), in a freshly-created postgresql
database (with all tests passing from "make check-world"), this sequence:

Also, in case it helps, I've localized this issue to commit 918eee0c
"Collect and use histograms of lower and upper bounds for range types."

--
Brett Neumeier (bneumeier@gmail.com)

#3Brett Neumeier
bneumeier@gmail.com
In reply to: Brett Neumeier (#1)
Re: BUG #8684: Tables with custom range domain type cannot be analyzed

On Tue, Dec 17, 2013 at 11:10 AM, <bneumeier@gmail.com> wrote:

Bug reference: 8684

(This error is being emitted from range_get_typcache because the result of
lookup_type_cache(rngtypid, TYPECACHE_RANGE_INFO) has a rngelemtype of
NULL,
but I haven't tried to figure out why that is or what it should be
instead.)

The problem appears to be that domains based on a range type are found by
the histogram-construction code, but have no range type information within
them; the range info is in the base type for the domain instead.

Perhaps this function should detect domain types and iteratively climb up
the base-type hierarchy until it finds the actual range type?

I would be happy to attempt such a thing and see if it helps, but have very
little familiarity with the postgresql codebase. Is there a document
somewhere that describes type lookup functions?

--
Brett Neumeier (bneumeier@gmail.com)

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Brett Neumeier (#1)
Re: BUG #8684: Tables with custom range domain type cannot be analyzed

bneumeier@gmail.com writes:

[ ANALYZE doesn't work on a domain over a range type ]

Fixed, thanks for the report! Patch against 9.3 is here:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=663f8419b6e75b6ebc4c22d10fbe55f133f768e0

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

#5Brett Neumeier
bneumeier@gmail.com
In reply to: Tom Lane (#4)
Re: BUG #8684: Tables with custom range domain type cannot be analyzed

On Mon, Dec 23, 2013 at 9:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

bneumeier@gmail.com writes:

[ ANALYZE doesn't work on a domain over a range type ]

Fixed, thanks for the report! Patch against 9.3 is here:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=663f8419b6e75b6ebc4c22d10fbe55f133f768e0

Thank you Mr Lane! Your help is very much appreciated. I've confirmed that
this fixes the issue we were having.

--
Brett Neumeier (bneumeier@gmail.com)