Re: BDR Alter table failing

From: Will McCormick <wmccormick(at)gmail(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: BDR Alter table failing
Date: 2016-04-27 15:25:17
Message-ID: CA+jgkY6_yyeNGYb5ZJ2_DBTp7heLb5nSzjoCzgWG9LEA+Hh+Rw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

But this is the exact column definition that exists on the table when I
execute the statement ....

It's like it does not check the pre-existing state of the column. Our code
is expecting a column already exists error but this error predicates that.

On Wed, Apr 27, 2016 at 10:21 AM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 04/27/2016 07:13 AM, Will McCormick wrote:
>
>> Why does this not work? From what I read only default values should
>> cause issue. I'm on release 9.4.4:
>>
>>
>> bms=# ALTER TABLE trap ALTER COLUMN trap_timestamp TYPE TIMESTAMP WITH
>> TIME ZONE;
>> ERROR: ALTER TABLE ... ALTER COLUMN TYPE may only affect UNLOGGED or
>> TEMPORARY
>> tables when BDR is active; trap is a regular table
>>
>
> http://bdr-project.org/docs/stable/ddl-replication-statements.html
>
> 8.2.3. DDL statements with restrictions
>
> ALTER TABLE
>
> Generally ALTER TABLE commands are allowed. There are a however
> several sub-commands that are not supported, mainly those that perform a
> full-table re-write.
>
> ...
>
> ALTER COLUMN ... TYPE - changing a column's type is not supported. Chaning
> a column in a way that doesn't require table rewrites may be suppported at
> some point.
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Will McCormick 2016-04-27 15:35:36 Re: BDR Alter table failing
Previous Message Karl Czajkowski 2016-04-27 15:15:55 Re: Slow join over three tables