From: | Soni M <diptatapa(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Postgres Bug <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: pg_dump with disable trigger |
Date: | 2018-04-11 00:32:22 |
Message-ID: | CAAMgDXnvw-ZeCxQ-mECCEF3vdox22haHGzg0oh2AEZnGhqP4gA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Apr 11, 2018 at 6:46 AM, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Tue, Apr 10, 2018 at 4:17 PM, Soni M <diptatapa(at)gmail(dot)com> wrote:
>
>> Hello All,
>>
>> I think I found bug on pg_dump 9.6.8.
>> The bug arise when using pg_dump with --disable-trigger option.
>> The command just :
>> pg_dump -f /tmp/test_disable_trigger.sql -a -b --disable-triggers -t
>> some_table some_database
>> On the resulted script, it simply did
>>
>> ALTER TABLE public.some_table DISABLE TRIGGER ALL;
>> COPY command
>> ALTER TABLE public.some_table ENABLE TRIGGER ALL;
>>
>> This become a problem, when the destination table already has Disabled
>> user triggers, it gets enabled by the dump script.
>>
>
> I would classify this as a limitation of the concept as opposed to a
> bug. I was going to say a bit more but I'm not that fluent with disabled
> triggers mode in dump/restore setups. I would advise using pg_restore and
> leaving the disable triggers option of the pg_dump command. It lacks
> sufficient information to write an appropriate script for an unknown target
> server.
>
> If you have issues with pg_restore those would be more easily be deemed as
> bugs.
>
> FWIW we have a "SET LOCAL" command that results in GUC variables being
> restored to their state post-transaction; we'd need a similar command for
> pg_dump to work properly.
>
> It also altered another kind of trigger like Triggers firing on replica
>> only, get altered to ordinary triggers.
>>
>
> This seems like a bug - though I'm not going to be confirming the
> behavior and you haven't provided evidence.
>
>
This happen when copying slony log table.
Before restore :
Table
"_consprod_replication.sl_log_1"
Indexes:
"PartInd_consprod_replication_sl_log_1-node-2" btree (log_txid) WHERE
log_origin = 2
"sl_log_1_idx1" btree (log_origin, log_txid, log_actionseq)
Triggers firing on replica only:
apply_trigger BEFORE INSERT ON _consprod_replication.sl_log_1 FOR EACH
ROW EXECUTE PROCEDURE
_consprod_replication.logapply('_consprod_replication')
And after restore :
Table
"_consprod_replication.sl_log_1"
Indexes:
"PartInd_consprod_replication_sl_log_1-node-2" btree (log_txid) WHERE
log_origin = 2
"sl_log_1_idx1" btree (log_origin, log_txid, log_actionseq)
Triggers:
apply_trigger BEFORE INSERT ON _consprod_replication.sl_log_1 FOR EACH
ROW EXECUTE PROCEDURE
_consprod_replication.logapply('_consprod_replication')
> David J.
>
>
--
Regards,
Soni Maula Harriz
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-04-11 03:13:35 | Re: power() function in Windows: "value out of range: underflow" |
Previous Message | Huong Dangminh | 2018-04-10 23:46:49 | RE: power() function in Windows: "value out of range: underflow" |