From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Clemens Eisserer <linuxhippy(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Do "after update" trigger block the current transaction? |
Date: | 2013-03-26 14:00:26 |
Message-ID: | 5151A9FA.8040407@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 26/03/13 13:24, Clemens Eisserer wrote:
> Hi Richard,
>
>>> Will triggers (after
>>> update specifically) cause the execution of SQL-commands to pause
>>> until the trigger-function has returned (at statement execution time
>>> or commit)?
>>
>> The trigger will block. If it didn't then it couldn't abort the transaction
>> if it needed to.
>
> Thanks for the clarification.
>
>> Why not use one of the established trigger-based replication solutions?
>
> Because the "other" database which I would like to keep in sync is a
> MySQL db. Furthermore I do not need a 1:1 replica, but instead just
> update a few columns in different tables there.
>
> My inital plan was to add a timestamp-column which is updated at every
> Update and to poll for changes every 5-10s. However, the word
> "polling" seems to cause an allergic reaction for some poeple ;)
Might be worth looking at PgQ - a queueing system underlying Londiste.
That would handle tracking the changes in PostgreSQL leaving you to just
handle the MySQL end. Timestamps will do the job as long as you are
careful to allow enough slack to deal with clock updates.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Clemens Eisserer | 2013-03-26 14:27:26 | Re: Do "after update" trigger block the current transaction? |
Previous Message | Merlin Moncure | 2013-03-26 13:28:17 | Re: effective_io_concurrency on Windows |