Fujii Masao írta:
Thanks for your reply!
On Fri, May 14, 2010 at 10:33 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
In your design, the transaction commit on the master waits for its XID
to be read from the XLOG_XACT_COMMIT record and replied by the standby.
Right? This design seems
On Wed, May 19, 2010 at 5:41 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
Isn't reading the same WAL twice (by walreceiver and startup process)
inefficient?
Yes, and I didn't implement that because it's inefficient.
So I'd like to propose to use LSN instead of XID since LSN can
be easily
Fujii Masao írta:
On Wed, May 19, 2010 at 5:41 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
Isn't reading the same WAL twice (by walreceiver and startup process)
inefficient?
Yes, and I didn't implement that because it's inefficient.
So I'd like to propose to use LSN
On Wed, May 19, 2010 at 9:58 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
In the patch, PQputCopyData() checks the newly-introduced pg_conn field
duplexCopy. Instead, how about checking the existing field replication?
I didn't see there was such a new field. (looking...) I can see now,
it
Thanks for your reply!
On Fri, May 14, 2010 at 10:33 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
In your design, the transaction commit on the master waits for its XID
to be read from the XLOG_XACT_COMMIT record and replied by the standby.
Right? This design seems not to be extensible to #2
On Sat, May 15, 2010 at 4:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
BTW, What I'd like to see as a very first patch first is to change the
current poll loops in walreceiver and walsender to, well, not poll.
That's a requirement for synchronous replication, is very
On 18/05/10 07:41, Fujii Masao wrote:
On Sat, May 15, 2010 at 4:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
BTW, What I'd like to see as a very first patch first is to change the
current poll loops in walreceiver and walsender to, well, not poll.
That's a requirement
On Fri, 2010-05-14 at 15:15 -0400, Robert Haas wrote:
On Fri, May 14, 2010 at 9:33 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
If min_sync_replication_clients == 0, then the replication is async.
If min_sync_replication_clients == max_wal_senders then the
replication is fully
BTW, What I'd like to see as a very first patch first is to change the
current poll loops in walreceiver and walsender to, well, not poll.
That's a requirement for synchronous replication, is very useful on its
own, and requires a some design and implementation effort to get right.
It would be
2010/4/29 Boszormenyi Zoltan z...@cybertec.at:
attached is a patch that does $SUBJECT, we are submitting it for 9.1.
I have updated it to today's CVS after the wal_level GUC went in.
I'm planning to create the synchronous replication patch for 9.0, too.
My design is outlined in the wiki. Let's
Fujii Masao írta:
2010/4/29 Boszormenyi Zoltan z...@cybertec.at:
attached is a patch that does $SUBJECT, we are submitting it for 9.1.
I have updated it to today's CVS after the wal_level GUC went in.
I'm planning to create the synchronous replication patch for 9.0, too.
My design
On Fri, May 14, 2010 at 9:33 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
If min_sync_replication_clients == 0, then the replication is async.
If min_sync_replication_clients == max_wal_senders then the
replication is fully synchronous.
If 0 min_sync_replication_clients max_wal_senders
Robert Haas írta:
On Fri, May 14, 2010 at 9:33 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
If min_sync_replication_clients == 0, then the replication is async.
If min_sync_replication_clients == max_wal_senders then the
replication is fully synchronous.
If 0
Hi,
Bruce Momjian írta:
Please add it to the next commit-fest:
https://commitfest.postgresql.org/action/commitfest_view/inprogress
it was already added two days ago:
https://commitfest.postgresql.org/action/patch_view?id=297
Best regards,
Zoltán Böszörményi
--
Bible has answers
Please add it to the next commit-fest:
https://commitfest.postgresql.org/action/commitfest_view/inprogress
---
z...@cybertec.at wrote:
Resending, my ISP lost my mail yesterday. :-(
15 matches
Mail list logo
