Thread: Odd warning from pg_dump
In connection with a question on -general, I tried this:
$ pg_dump -n '*' regression >regression.dump
pg_dump: WARNING: typtype of data type "any" appears to be invalid
pg_dump: WARNING: typtype of data type "anyarray" appears to be invalid
pg_dump: WARNING: typtype of data type "anyelement" appears to be invalid
pg_dump: WARNING: typtype of data type "anyenum" appears to be invalid
pg_dump: WARNING: typtype of data type "anynonarray" appears to be invalid
pg_dump: WARNING: typtype of data type "anyrange" appears to be invalid
pg_dump: WARNING: typtype of data type "cstring" appears to be invalid
pg_dump: WARNING: typtype of data type "event_trigger" appears to be invalid
pg_dump: WARNING: typtype of data type "fdw_handler" appears to be invalid
pg_dump: WARNING: typtype of data type "index_am_handler" appears to be invalid
pg_dump: WARNING: typtype of data type "internal" appears to be invalid
pg_dump: WARNING: typtype of data type "language_handler" appears to be invalid
pg_dump: WARNING: typtype of data type "opaque" appears to be invalid
pg_dump: WARNING: typtype of data type "pg_ddl_command" appears to be invalid
pg_dump: WARNING: typtype of data type "record" appears to be invalid
pg_dump: WARNING: typtype of data type "trigger" appears to be invalid
pg_dump: WARNING: typtype of data type "tsm_handler" appears to be invalid
pg_dump: WARNING: typtype of data type "void" appears to be invalid
$
The datatypes being complained of are evidently all the pseudo-types.
I haven't looked into the code to figure out why this happens.
The dump is produced anyway, so it's only a cosmetic issue, but seems
probably worth fixing.
regards, tom lane
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> In connection with a question on -general, I tried this:
>
> $ pg_dump -n '*' regression >regression.dump
> pg_dump: WARNING: typtype of data type "any" appears to be invalid
> pg_dump: WARNING: typtype of data type "anyarray" appears to be invalid
> pg_dump: WARNING: typtype of data type "anyelement" appears to be invalid
> pg_dump: WARNING: typtype of data type "anyenum" appears to be invalid
> pg_dump: WARNING: typtype of data type "anynonarray" appears to be invalid
> pg_dump: WARNING: typtype of data type "anyrange" appears to be invalid
> pg_dump: WARNING: typtype of data type "cstring" appears to be invalid
> pg_dump: WARNING: typtype of data type "event_trigger" appears to be invalid
> pg_dump: WARNING: typtype of data type "fdw_handler" appears to be invalid
> pg_dump: WARNING: typtype of data type "index_am_handler" appears to be invalid
> pg_dump: WARNING: typtype of data type "internal" appears to be invalid
> pg_dump: WARNING: typtype of data type "language_handler" appears to be invalid
> pg_dump: WARNING: typtype of data type "opaque" appears to be invalid
> pg_dump: WARNING: typtype of data type "pg_ddl_command" appears to be invalid
> pg_dump: WARNING: typtype of data type "record" appears to be invalid
> pg_dump: WARNING: typtype of data type "trigger" appears to be invalid
> pg_dump: WARNING: typtype of data type "tsm_handler" appears to be invalid
> pg_dump: WARNING: typtype of data type "void" appears to be invalid
> $
>
> The datatypes being complained of are evidently all the pseudo-types.
> I haven't looked into the code to figure out why this happens.
> The dump is produced anyway, so it's only a cosmetic issue, but seems
> probably worth fixing.
This is fixed in my changes to pg_dump, though I didn't expect you'd be
able to hit them in released versions and so hadn't been planning to
break it out.
This is the hunk for that particular change (line numbers are probably
off due to my other changes in the overall patch):
*************** dumpType(Archive *fout, TypeInfo *tyinfo
*** 8722,8727 ****
--- 8727,8743 ---- dumpRangeType(fout, tyinfo); else if (tyinfo->typtype == TYPTYPE_PSEUDO &&
!tyinfo->isDefined) dumpUndefinedType(fout, tyinfo);
+ else if (tyinfo->typtype == TYPTYPE_PSEUDO && tyinfo->isDefined &&
+ strncmp(tyinfo->dobj.namespace->dobj.name, "pg_catalog", 10) == 0)
+ /*
+ * skip defined pseudo-types in pg_catalog, they are special cases in
+ * the type system which are defined at initdb time only.
+ *
+ * Should a user manage to create one (which would require hand hacking
+ * the catalog, currently), throwing the below error seems entirely
+ * reasonable.
+ */
+ return; else write_msg(NULL, "WARNING: typtype of data type \"%s\" appears to be invalid\n",
tyinfo->dobj.name);
I can certainly look at committing that independently from the other
pg_dump changes that I'm working on.
Thanks!
Stephen
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> pg_dump: WARNING: typtype of data type "any" appears to be invalid
> This is fixed in my changes to pg_dump, though I didn't expect you'd be
> able to hit them in released versions and so hadn't been planning to
> break it out.
Oh, this was with HEAD; I've not checked it in released versions.
regards, tom lane
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Stephen Frost <sfrost@snowman.net> writes: > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > >> pg_dump: WARNING: typtype of data type "any" appears to be invalid > > > This is fixed in my changes to pg_dump, though I didn't expect you'd be > > able to hit them in released versions and so hadn't been planning to > > break it out. > > Oh, this was with HEAD; I've not checked it in released versions. Using your "-n '*'", I suspect you'd be able to hit it in released versions also. I think the real question is if "-n '*'" should still exclude 'pg_catalog'. Fixing the issue with defined pseudo types is wonderful, but aren't you going to end up with a dump you can't restore, regardless? Thanks! Stephen
Stephen Frost <sfrost@snowman.net> writes:
> I think the real question is if "-n '*'" should still exclude
> 'pg_catalog'. Fixing the issue with defined pseudo types is wonderful,
> but aren't you going to end up with a dump you can't restore,
> regardless?
Yeah, perhaps so. The thread on -general has also produced the
information that pg_dump -t '*' tries to dump system catalogs as if
they were user tables, which is another pretty useless bit of behavior.
So maybe we should drop the hunk you've got there (which frankly seems a
bit of a kluge) and instead hot-wire things so that stuff in pg_catalog
is excluded even if it would otherwise match the inclusion lists.
regards, tom lane
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Stephen Frost <sfrost@snowman.net> writes: > > I think the real question is if "-n '*'" should still exclude > > 'pg_catalog'. Fixing the issue with defined pseudo types is wonderful, > > but aren't you going to end up with a dump you can't restore, > > regardless? > > Yeah, perhaps so. The thread on -general has also produced the > information that pg_dump -t '*' tries to dump system catalogs as if > they were user tables, which is another pretty useless bit of behavior. Indeed. > So maybe we should drop the hunk you've got there (which frankly seems a > bit of a kluge) and instead hot-wire things so that stuff in pg_catalog > is excluded even if it would otherwise match the inclusion lists. An idealistic viewpoint might be that we should provide a way to actually create defined pseudo-types and then make pg_dump work with them, but I have a hard time seeing why that would be worth the effort. One might also argue that we should have a way of dealing with every type of object which exists and defined psuedo-types seem to be the only thing left out. I agree that it seems like the best idea is to just hot-wire pg_dump to exclude pg_catalog, though I'm inclined to suggest that we just exclude it from pattern matches. We know that objects sometimes end up in pg_catalog which aren't really supposed to be there and there might be other reasons to want to dump it out, so having 'pg_dump -n pg_catalog' still do its best to dump out what's been asked for seems reasonable. Thanks! Stephen
Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: > > I think the real question is if "-n '*'" should still exclude > > 'pg_catalog'. Fixing the issue with defined pseudo types is wonderful, > > but aren't you going to end up with a dump you can't restore, > > regardless? > > Yeah, perhaps so. The thread on -general has also produced the > information that pg_dump -t '*' tries to dump system catalogs as if > they were user tables, which is another pretty useless bit of behavior. > So maybe we should drop the hunk you've got there (which frankly seems a > bit of a kluge) and instead hot-wire things so that stuff in pg_catalog > is excluded even if it would otherwise match the inclusion lists. Not sure that's reasonable. We have at least one extension in contrib that creates objects in pg_catalog. ISTM that's enough precedent that more could be created in the future. (Now of course extensions get special treatment anyway, but my point is that there's no prohibition against creating objects in pg_catalog.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> So maybe we should drop the hunk you've got there (which frankly seems a
>> bit of a kluge) and instead hot-wire things so that stuff in pg_catalog
>> is excluded even if it would otherwise match the inclusion lists.
> Not sure that's reasonable. We have at least one extension in contrib
> that creates objects in pg_catalog. ISTM that's enough precedent that
> more could be created in the future. (Now of course extensions get
> special treatment anyway, but my point is that there's no prohibition
> against creating objects in pg_catalog.)
True, and given the lack of prior complaints, it might be better to
leave well enough alone here. What the -general thread was actually
suggesting is that pg_dump needs a way to forcibly omit blobs; the
question about behavior of the pattern-match switches was a sideshow.
regards, tom lane