On 28 April 2016 at 02:47, Will McCormick wrote:
> So if I wanted to extend a column from 100 characters to 255 characters is
> this permitted? The fact that I'm not making a change and the BDR kicked me
> out makes me skeptical.
>
Off the top of my head I'm not sure and would need to test. Ther
If you change the length of a character varying, it should work. I'm almost
sure I have done that before on my BDR cluster.
It may work as long as it does not require a full table rewrite. I think, the
length change for a character varying won't need a full table rewrite, as the
length is only
So if I wanted to extend a column from 100 characters to 255 characters is
this permitted? The fact that I'm not making a change and the BDR kicked me
out makes me skeptical.
On Wed, Apr 27, 2016 at 11:56 AM, Craig Ringer
wrote:
> On 27 April 2016 at 23:43, Alvaro Aguayo Garcia-Rada <
> aagu...@
On 27 April 2016 at 23:43, Alvaro Aguayo Garcia-Rada <
aagu...@opensysperu.com> wrote:
> Based on my experience, I can say BDR does not performs pre-DDL checks.
> For example, if you try to CREATE TABLE with the name of an existing table,
> BDR will acquire lock anyway, and then will fail when exe
Based on my experience, I can say BDR does not performs pre-DDL checks. For
example, if you try to CREATE TABLE with the name of an existing table, BDR
will acquire lock anyway, and then will fail when executing the DDL statement
on the first node, because the table already exists.
In your case
I guess the only viable option would be to the check explicitly ourselves.
On Wed, Apr 27, 2016 at 11:25 AM, Will McCormick
wrote:
> 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
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
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 UNLOGG
Why does this not work:
Hi All,
And sorry about that damn thumb pad! Premature send!
On Wed, Apr 27, 2016 at 10:15 AM, Adrian Klaver
wrote:
> On 04/27/2016 07:11 AM, Will McCormick wrote:
>
>> Why does this not work:
>>
>>
> Because it is NULL :)?
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
On 04/27/2016 07:11 AM, Will McCormick wrote:
Why does this not work:
Because it is NULL :)?
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-genera
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
12 matches
Mail list logo
