| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: multi-master pgbench? |
| Date: | 2012-08-22 02:02:56 |
| Message-ID: | 20120822.110256.984954144765860635.t-ishii@sraoss.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> I do not intended to implement such a feature. As I wrote in the
>> subject line, I intended to enhance pgbench for "multi-master"
>> configuration. IMO, any node on multi-master configuration should
>> accept *any* queries, not only read queries but write queries. So bare
>> PostgreSQL streaming replication configuration cannot be a
>> multi-master configuration and will not be a target of the new
>> pgbench.
>
> Well, you're being shortsighted then, because such a feature will barely
> have hit the git repository before somebody wants to use it differently.
> I can easily imagine wanting to stress a master plus some hot-standby
> slaves, for instance; and that would absolutely require being able to
> direct different subsets of the test scripts to different hosts.
I don't see any practical way to implement such a tool because there's
always a chance to try to retrieve non existing data from hot-standby
because of replication delay.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Wang, Chaoyong | 2012-08-22 02:52:04 | Re: problem when optimizing the window aggregation |
| Previous Message | Tom Lane | 2012-08-22 01:51:14 | Re: multi-master pgbench? |