From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | koktos632(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16437: The dump is stored with error in creating VIEW statement. |
Date: | 2020-05-14 17:18:51 |
Message-ID: | 6545.1589476731@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> pg_restore: creating VIEW "ctrader.sentiment_summary_600"
> pg_restore: while PROCESSING TOC:
> pg_restore: from TOC entry 252; 1259 25769 VIEW sentiment_summary_600
> quotefeeder
> pg_restore: error: could not execute query: ERROR: column
> "_materialized_hypertable_2.Volume" must appear in the GROUP BY clause or be
> used in an aggregate function
Hm. I suppose that this view is valid in the source database because
"Time" and/or "m_tickerId" are the primary key of
_materialized_hypertable_2, and the restore is failing because pg_dump
didn't restore the primary key constraint first. But it should know
to do that, and you haven't provided nearly enough information to track
down why it didn't.
Can you provide a self-contained test case that fails like this?
We probably don't need to see any data, just the database
object declarations.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-05-14 19:23:23 | Re: BUG #16437: The dump is stored with error in creating VIEW statement. |
Previous Message | PG Bug reporting form | 2020-05-14 16:21:25 | BUG #16437: The dump is stored with error in creating VIEW statement. |