Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> [ pokes around... ] The code I was thinking of is convert_tuples_by_name
> >> in access/common/tupconvert.c. There's a bit of an API mismatch in that
> >> it wants to wrap the mapping array in a TupleConversionMap struct; but
> >>
Alvaro Herrera writes:
> Tom Lane wrote:
>> [ pokes around... ] The code I was thinking of is convert_tuples_by_name
>> in access/common/tupconvert.c. There's a bit of an API mismatch in that
>> it wants to wrap the mapping array in a TupleConversionMap struct; but
>> maybe we could refactor tup
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Hmm. The bespoke code for constructing the attno map bothers me;
> >> surely there is existing code that does that? If not, it'd still
> >> make more sense to factor it out, I think, because there will be
> >> other needs for it i
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hmm. The bespoke code for constructing the attno map bothers me;
>> surely there is existing code that does that? If not, it'd still
>> make more sense to factor it out, I think, because there will be
>> other needs for it in future.
> There isn't any
Tom Lane wrote:
> Alvaro Herrera writes:
> > Alvaro Herrera wrote:
> >> Here's a first attempt at fixing this. It makes the test pass, but I
> >> have the feeling that more complex ones might need more work.
>
> > Here's another one with three main differences:
>
> Hmm. The bespoke code for co
Alvaro Herrera writes:
> Alvaro Herrera wrote:
>> Here's a first attempt at fixing this. It makes the test pass, but I
>> have the feeling that more complex ones might need more work.
> Here's another one with three main differences:
Hmm. The bespoke code for constructing the attno map bothers
Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > We could probably fix the specific issue being seen here by passing the
> > expression tree through a suitable attno remapping,
>
> Here's a first attempt at fixing this. It makes the test pass, but I
> have the feeling that more complex ones might n
Tom Lane wrote:
> We could probably fix the specific issue being seen here by passing the
> expression tree through a suitable attno remapping,
Here's a first attempt at fixing this. It makes the test pass, but I
have the feeling that more complex ones might need more work. Have to
leave for a
Tom Lane wrote:
> A little bit of "git bisect"-ing later, the blame is pinned on
>
> commit 9550e8348b7965715789089555bb5a3fda8c269c
> Author: Alvaro Herrera
> Date: Fri Apr 3 17:33:05 2015 -0300
>
> Transform ALTER TABLE/SET TYPE/USING expr during parse analysis
>
> This lets la
I wrote:
> Hah:
> regression=# create table p(f1 int);
> CREATE TABLE
> regression=# create table c1(extra smallint) inherits(p);
> CREATE TABLE
> regression=# alter table p add column f2 int;
> ALTER TABLE
> regression=# insert into c1 values(1,2,3);
> INSERT 0 1
> regression=# alter table p alte
Justin Pryzby writes:
> On Tue, Jan 03, 2017 at 03:35:34PM -0500, Tom Lane wrote:
>> Right. So I bet that if you check the attnum of pmsumpacketlatency_000 in
>> eric_umts_rnc_utrancell_metrics, you'll find it's different from that in
>> eric_umts_rnc_utrancell_201701, and that the attribute havi
On Tue, Jan 03, 2017 at 03:35:34PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote:
> >> I'm wondering if this represents some sort of out-of-sync condition
> >> between the table and its child tables. We can't actually tell from
> >> th
Justin Pryzby writes:
> On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote:
>> I'm wondering if this represents some sort of out-of-sync condition
>> between the table and its child tables. We can't actually tell from
>> this trace which table is being processed. Could you try, from this
>
On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > (gdb) bt
> > #3 0x0059d5ce in ATRewriteTable (tab=,
> > OIDNewHeap=, lockmode=) at
> > tablecmds.c:4152
>
> I'm wondering if this represents some sort of out-of-sync condition
> between the table and
I wrote:
> I'm wondering if this represents some sort of out-of-sync condition
> between the table and its child tables.
Hah:
regression=# create table p(f1 int);
CREATE TABLE
regression=# create table c1(extra smallint) inherits(p);
CREATE TABLE
regression=# alter table p add column f2 int;
ALTE
Justin Pryzby writes:
> (gdb) bt
> #0 errfinish (dummy=0) at elog.c:414
> #1 0x005d0e30 in ExecEvalScalarVar (exprstate=,
> econtext=, isNull=, isDone= optimized out>) at execQual.c:655
> #2 0x005d0c3c in ExecMakeFunctionResultNoSets (fcache=0x21f18a0,
> econtext=0x2199e80, is
On Tue, Jan 03, 2017 at 02:50:21PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
> >> 2. Even better would be a stack trace for the call to errfinish,
> >> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backe
Justin Pryzby writes:
> On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
>> 2. Even better would be a stack trace for the call to errfinish,
>> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
Thanks, but we need the whole call stack, or at least the firs
On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
> 3. It's pretty hard to see how you'd reach any of these places for an
> ALTER COLUMN TYPE on a simple table. Has the table got rules, triggers,
> default values? Could we see "\d+" output for it?
I really meant to do \d+..
On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> I can cause the error at will on the existing table,
>
> That's good news, at least.
>
> 1. Please trigger it with "\set VERBOSITY verbose" enabled, so we can see
> the exact source location --- there are a
Justin Pryzby writes:
I can cause the error at will on the existing table,
That's good news, at least.
1. Please trigger it with "\set VERBOSITY verbose" enabled, so we can see
the exact source location --- there are a couple of instances of that
text.
2. Even better would be a stack trace
On Tue, Jan 03, 2017 at 01:40:50PM -0500, Robert Haas wrote:
> On Tue, Jan 3, 2017 at 11:59 AM, Justin Pryzby wrote:
> > On Tue, Jan 03, 2017 at 11:45:33AM -0500, Robert Haas wrote:
> >> > ts=# begin; drop view umts_eric_ch_switch_view,
> >> > eric_umts_rnc_utrancell_view, umts_eric_cell_integrit
On Tue, Jan 3, 2017 at 11:59 AM, Justin Pryzby wrote:
> On Tue, Jan 03, 2017 at 11:45:33AM -0500, Robert Haas wrote:
>> > ts=# begin; drop view umts_eric_ch_switch_view,
>> > eric_umts_rnc_utrancell_view, umts_eric_cell_integrity_view; ALTER TABLE
>> > eric_umts_rnc_utrancell_metrics ALTER COLUM
On Tue, Jan 03, 2017 at 11:45:33AM -0500, Robert Haas wrote:
> > ts=# begin; drop view umts_eric_ch_switch_view,
> > eric_umts_rnc_utrancell_view, umts_eric_cell_integrity_view; ALTER TABLE
> > eric_umts_rnc_utrancell_metrics ALTER COLUMN PMSUMPACKETLATENCY_000 TYPE
> > BIGINT USING PMSUMPACKETL
On Mon, Jan 2, 2017 at 7:32 PM, Justin Pryzby wrote:
> On Wed, Oct 12, 2016 at 10:25:05AM -0500, Justin Pryzby wrote:
>> > I don't have a clear recollection how I solved this in July; possibly by
>> > restoring the (historic, partition) table from backup.
>> >
>> > Last week again again just now (
On Wed, Oct 12, 2016 at 10:25:05AM -0500, Justin Pryzby wrote:
> > I don't have a clear recollection how I solved this in July; possibly by
> > restoring the (historic, partition) table from backup.
> >
> > Last week again again just now (both under 9.6), a colleague found that he
> > was
> > abl
I originally sent to psql-general some months ago, but it appears it was never
delivered (perhaps I wasn't properly subscribed?).
Failed to alter table eric_umts_rnc_utrancell_metrics: ERROR: attribute 361
has wrong type
DETAIL: Table has type integer, but query expects smallint.
We've seen th
27 matches
Mail list logo
