Обсуждение: FailedAssertion("!OidIsValid(def->collOid)", File: "view.c", Line: 89)

Hi everyone,

The following statements result in an assertion error on the latest
trunk version (c01ac6d):

CREATE TABLE t0(c0 TEXT COLLATE "POSIX");
CREATE VIEW v0(c0) AS (SELECT (t0.c0 COLLATE "C")::INT FROM t0); --
FailedAssertion("!OidIsValid(def->collOid)", File: "view.c", Line: 89)

When building without assertions, the CREATE VIEW statement results in
an error instead:

ERROR: collations are not supported by type integer

Best,
Manuel

Full stack trace:

TRAP: FailedAssertion("!OidIsValid(def->collOid)", File: "view.c", Line: 89)
postgres: postgres testdb [local] CREATE
VIEW(ExceptionalCondition+0x76)[0x563c55747066]
postgres: postgres testdb [local] CREATE VIEW(DefineView+0x4cb)[0x563c55487cdb]
postgres: postgres testdb [local] CREATE VIEW(+0x41cebc)[0x563c5561febc]
postgres: postgres testdb [local] CREATE
VIEW(standard_ProcessUtility+0x148)[0x563c5561e9f8]
postgres: postgres testdb [local] CREATE VIEW(+0x418a64)[0x563c5561ba64]
postgres: postgres testdb [local] CREATE VIEW(+0x41961b)[0x563c5561c61b]
postgres: postgres testdb [local] CREATE VIEW(PortalRun+0x17a)[0x563c5561d45a]
postgres: postgres testdb [local] CREATE VIEW(+0x415fed)[0x563c55618fed]
postgres: postgres testdb [local] CREATE
VIEW(PostgresMain+0x14ef)[0x563c5561a8cf]
postgres: postgres testdb [local] CREATE VIEW(+0x38d8d4)[0x563c555908d4]
postgres: postgres testdb [local] CREATE
VIEW(PostmasterMain+0xe01)[0x563c555917f1]
postgres: postgres testdb [local] CREATE VIEW(main+0x4b8)[0x563c552b9058]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f80170ddb6b]
postgres: postgres testdb [local] CREATE VIEW(_start+0x2a)[0x563c552b90fa]

On Mon, Dec 2, 2019 at 12:32 PM Manuel Rigger <rigger.manuel@gmail.com> wrote:
> CREATE TABLE t0(c0 TEXT COLLATE "POSIX");
> CREATE VIEW v0(c0) AS (SELECT (t0.c0 COLLATE "C")::INT FROM t0); --
> FailedAssertion("!OidIsValid(def->collOid)", File: "view.c", Line: 89)
>
> When building without assertions, the CREATE VIEW statement results in
> an error instead:
>
> ERROR: collations are not supported by type integer

I think the options are to add a check and ereport() instead of an
assertion, or just remove the assertion and let BuildDescForRelation()
report the error as it does in non-assert builds.  I think the latter
is better, since it seems well established that BuildDescForRelation()
will complain about that via its call to GetColumnDefCollation().
Here's a patch to do that.

> TRAP: FailedAssertion("!OidIsValid(def->collOid)", File: "view.c", Line: 89)
> postgres: postgres testdb [local] CREATE
> VIEW(ExceptionalCondition+0x76)[0x563c55747066]
> postgres: postgres testdb [local] CREATE VIEW(DefineView+0x4cb)[0x563c55487cdb]
> ...

I'm loving these new back traces.

Hi,

Thanks for the fix. Will this patch be merged soon?

Best,
Manuel


On Mon, Dec 2, 2019 at 2:21 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Mon, Dec 2, 2019 at 12:32 PM Manuel Rigger <rigger.manuel@gmail.com> wrote:
> > CREATE TABLE t0(c0 TEXT COLLATE "POSIX");
> > CREATE VIEW v0(c0) AS (SELECT (t0.c0 COLLATE "C")::INT FROM t0); --
> > FailedAssertion("!OidIsValid(def->collOid)", File: "view.c", Line: 89)
> >
> > When building without assertions, the CREATE VIEW statement results in
> > an error instead:
> >
> > ERROR: collations are not supported by type integer
>
> I think the options are to add a check and ereport() instead of an
> assertion, or just remove the assertion and let BuildDescForRelation()
> report the error as it does in non-assert builds.  I think the latter
> is better, since it seems well established that BuildDescForRelation()
> will complain about that via its call to GetColumnDefCollation().
> Here's a patch to do that.
>
> > TRAP: FailedAssertion("!OidIsValid(def->collOid)", File: "view.c", Line: 89)
> > postgres: postgres testdb [local] CREATE
> > VIEW(ExceptionalCondition+0x76)[0x563c55747066]
> > postgres: postgres testdb [local] CREATE VIEW(DefineView+0x4cb)[0x563c55487cdb]
> > ...
>
> I'm loving these new back traces.

On 2019-Dec-02, Thomas Munro wrote:

> On Mon, Dec 2, 2019 at 12:32 PM Manuel Rigger <rigger.manuel@gmail.com> wrote:
> > CREATE TABLE t0(c0 TEXT COLLATE "POSIX");
> > CREATE VIEW v0(c0) AS (SELECT (t0.c0 COLLATE "C")::INT FROM t0); --
> > FailedAssertion("!OidIsValid(def->collOid)", File: "view.c", Line: 89)
> >
> > When building without assertions, the CREATE VIEW statement results in
> > an error instead:
> >
> > ERROR: collations are not supported by type integer
> 
> I think the options are to add a check and ereport() instead of an
> assertion, or just remove the assertion and let BuildDescForRelation()
> report the error as it does in non-assert builds.  I think the latter
> is better, since it seems well established that BuildDescForRelation()
> will complain about that via its call to GetColumnDefCollation().
> Here's a patch to do that.

This has not been applied yet AFAICS.  Thomas, are you getting to this
one soon?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Wed, Jun 3, 2020 at 9:30 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2019-Dec-02, Thomas Munro wrote:
> > On Mon, Dec 2, 2019 at 12:32 PM Manuel Rigger <rigger.manuel@gmail.com> wrote:
> > > CREATE TABLE t0(c0 TEXT COLLATE "POSIX");
> > > CREATE VIEW v0(c0) AS (SELECT (t0.c0 COLLATE "C")::INT FROM t0); --
> > > FailedAssertion("!OidIsValid(def->collOid)", File: "view.c", Line: 89)
> > >
> > > When building without assertions, the CREATE VIEW statement results in
> > > an error instead:
> > >
> > > ERROR: collations are not supported by type integer
> >
> > I think the options are to add a check and ereport() instead of an
> > assertion, or just remove the assertion and let BuildDescForRelation()
> > report the error as it does in non-assert builds.  I think the latter
> > is better, since it seems well established that BuildDescForRelation()
> > will complain about that via its call to GetColumnDefCollation().
> > Here's a patch to do that.
>
> This has not been applied yet AFAICS.  Thomas, are you getting to this
> one soon?

Thanks for the reminder.  Will do.