| From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
|---|---|
| To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
| Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Synchronization levels in SR |
| Date: | 2010-09-06 12:53:07 |
| Message-ID: | 87wrqz58zw.fsf@hi-media-techno.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
> Sorry for answering such an old mail, but what is the purpose of
> a transaction level synchronous behaviour if async transactions
> can be held back by a sync transaction?
I don't understand why it would be the case (sync holding back async
transactions) — it's been proposed that walsender could periodically
feed back to the master the current WAL position received, synced and
applied.
So you can register your sync transaction to wait (and block) until
walsender sees a synced WAL position after your own (including it) and
another transaction can wait until walsender sees a received WAL
position after its own, for example. Of course, meanwhile, any async
transaction would just commit without caring about slaves.
Not implementing it nor thinking about how to implement it, it seems
simple enough :)
Regards,
--
dim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2010-09-06 13:03:44 | Re: Synchronous replication - patch status inquiry |
| Previous Message | Magnus Hagander | 2010-09-06 07:57:20 | Re: Windows Tools |