Hello,
It turns out that partitioning has nothing to do with this.
abi2=> create table _tmp_test_loop_ref (id int4, refid int4, primary key (id));
CREATE TABLE
abi2=> alter table _tmp_test_loop_ref add constraint fk_loop_ref foreign key (refid) references _tmp_test_loop_ref(id) on update cascade on delete restrict;
ALTER TABLE
abi2=> insert into _tmp_test_loop_ref values (2,null);
INSERT 0 1
abi2=> insert into _tmp_test_loop_ref values (1,2);
INSERT 0 1
abi2=> alter table _tmp_test_loop_ref add pi smallint default 0;
ALTER TABLE
abi2=> begin; delete from _tmp_test_loop_ref where id=1;
BEGIN
server closed the connection unexpectedlyThis probably means the server terminated abnormallybefore or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
Sorry for coming again...
G
On 11/5/18 9:16 PM, Tom Lane wrote:
"Ing. Gianluca Alberici" <alberici@abinetworks.biz> writes:
Actually it is a strange behavior, look at this:
abi2=> begin;
BEGIN
abi2=>*delete from _abi_main_pof_t where poftid=1843635; server closed the
connection unexpectedly This probably means the server terminated
abnormally before or while processing the request. The connection to
the server was lost. Attempting reset: Failed. !> \q*
Is it possible that you've done ALTER TABLE ADD COLUMN on _abi_main_pof_t
or any other table touched by this query? If so, I bet this is explained
by that expand_tuple bug.
regards, tom lane
