Re: plperl function fails to "fire" Slony trigger
От | Jan Wieck |
---|---|
Тема | Re: plperl function fails to "fire" Slony trigger |
Дата | |
Msg-id | 42694179.1030806@Yahoo.com обсуждение исходный текст |
Ответ на | Re: plperl function fails to "fire" Slony trigger (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: plperl function fails to "fire" Slony trigger
|
Список | pgsql-general |
On 4/22/2005 2:08 PM, Tom Lane wrote: > Sven Willenberger <sven@dmv.com> writes: >> We have a replication set up between 2 servers using Slony; both are >> runnind PostgreSQL 8.0.1. The issue is that when updates/inserts are >> made to a replicated table, the replication does not occur; apparently >> this is due to spi_exec somehow not allowing/causing the slony trigger >> function to fire. > > Yuck :-(. The only idea that comes to mind is that 8.0 changed the > timing of trigger firing --- the triggers are probably firing while your > function still has control, whereas in earlier releases they'd only fire > after it returns. Could this be breaking some assumption Slony makes > about the order of operations? > > regards, tom lane Slony triggers are AFTER ROW triggers. All they do is one SPI_execp() to insert the log row. The only way that could possibly be suppressed is by bypassing the executor and doing direct heap_ access. So how does plperl manage that? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-general по дате отправления: