From: | Herouth Maoz <herouth(at)unicell(dot)co(dot)il> |
---|---|
To: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Maintaining a materialized view only on a replica |
Date: | 2012-09-05 12:08:09 |
Message-ID: | C8B94C63-118B-401D-BA6D-BE98768D301B@unicell.co.il |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
It's not an issue with the replication software. The reason the parts of the transaction are written out of order is that the original system that writes them in the first place makes no guarantees as to the order of writing.
So basically my question is whether a trigger that runs a full aggregate SQL query on the table that triggered it, joining with another table, checking the rows returned and doing the insert in the second table only when the data is complete is feasible, because that's basically what I need to do.
Herouth
On 05/09/2012, at 00:52, Craig Ringer wrote:
> Subject changed to describe the problem. Reply in-line.
>
> On 09/04/2012 07:57 PM, Herouth Maoz wrote:
>
>> The issue is that when an insert or an update is fired, I can't say
>> whether all the segments of the same transaction have been written yet,
>> and if only some of them were written, there is no guarantee on the
>> order in which they are written.
>
> Does Slony-I provide stronger guarantees? If your replication doesn't guarantee ordering then you're going to have a very hard time doing this.
>
>> Is this
>> feasible at all? How would you achieve it?
>
> I'd try to find a replication system that guaranteed ordering if at all possible.
>
> --
> Craig Ringer
--
חרות מעוז
יוניסל פתרונות סלולריים מתקדמים
☎ 03-5181717 שלוחה 742
From | Date | Subject | |
---|---|---|---|
Next Message | Dipti Bharvirkar | 2012-09-05 12:14:19 | Re: Error stopping postgresql service on a standby server. |
Previous Message | Achilleas Mantzios | 2012-09-05 09:40:17 | Re: "Too far out of the mainstream" |