Fri May 13 13:23:36 PDT 2005
- Previous message: [Slony1-general] Re: BUG: [SLONY1] Table updates via plperl triggers fail to replicate (ID: 1293) (comment)
- Next message: [Slony1-general] Re: BUG: [SLONY1] Table updates via plperl triggers fail to replicate (ID: 1293) (comment)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 5/13/2005 6:38 AM, Hannu Krosing wrote: > On N, 2005-05-12 at 16:56 -0400, Jan Wieck wrote: >> Are you saying that using a plperl function you can reproducably manage >> to get your origin and subscribers to have different content while at >> the same time sl_log_1 is empty? >> >> If that is the case, I would be highly interested in a self contained >> test case. > > I think that this depends on the order of firing the triggers. - if the > trigger fires after slony's trigger and updates the same row, then it > seems quite logical that replication of later changes is not noticed by > slony. > The Slony-I log trigger is an AFTER trigger. Only BEFORE triggers can modify NEW. Everything that tries to modify a tuple once stored has to issue another query, thereby creating new row versions and firing the log trigger again. I still have to see a test case where plperl succeeds in confusing the trigger manager so much that it forgets to fire AR triggers. That would be the only way how what Sven claims could have happened. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck at Yahoo.com #
- Previous message: [Slony1-general] Re: BUG: [SLONY1] Table updates via plperl triggers fail to replicate (ID: 1293) (comment)
- Next message: [Slony1-general] Re: BUG: [SLONY1] Table updates via plperl triggers fail to replicate (ID: 1293) (comment)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list