Re: [Postgres-xc-general] ERROR: Failed to get pooled connections

[Vladimir S. <vst...@gm...>]

On Wed, Oct 24, 2012 at 11:18:59PM +0300, Andrei Martsinchyk wrote:

>    That is the reason to buy latest IPhone. Some servers run for years
>    without even reboot. Usually people are replacing servers only if
>    they really need to do that.

What about security patches for kernel? For years without reboot? And
it is not only reason to upgrade kernel. As for replacing, Yes it true,
but this moment inevitably come when new software eats more resources
while number of users increases, but I never hear somebody says it is
scaling process.

>    Nobody upgrades daily. I think it is not a lot of trouble to
>    recreate cluster once per few years.

Once per few years You can built totally new system on brand-new technology.
Cluster scalability imply possibility to scale it at any moment for example
(but not only) when new customers or partners come with new demand for fast
paced company with increasing load. It is by design. It is exactly what for the
scalable cluster exists: you can scale (expand) existing system instead of
building new one.


>    Why it doubles hardware park, multiple components may share same hardware.

As usual here it is far from reality. It is not common approach acceptable for
most companies. What You talking about looks like an approach for clouds or any
other service providers where hardware may be shared by their customers.

>    HA solution means extra complexity either it external or internal.

But it makes difference. External should be built and managed by users,
while internal is complete and transparent solution provided by authors.
With mysql cluster there are nothing to do with HA for users at all, it
just already "exists".

>    There are people out there who do not want that complexity, they
>    are happy with just performance scalability. They could use XC as

Will they happy with data lost and down time? Who they are?

>    one of those solutions. Everybody wins.  If XC integrates one
>    approach it will lose flexibility in this area.

and gain much more users.

>    I did not quite understand what you mean here. There are a lot of
>    important for system design things along all the hardware and
>    software stack. The more is known to developers the better result
>    will be. One may design database on XC if he does know anything
>    about it at all, with pure SQL, and the database will work. But
>    much better result can be achieved if database is designed
>    consciously.  Number of nodes does not matter for distribution
>    planning, btw.

Again: all of this is not about transparency. You are talking perhaps about
installing single application on fresh XC. But what if You install third party
application on existing XC already running multiply applications? What if those
databases distributed in different ways. What if because of this You can not
use all nodes for new application? In this case You must rewrite all "CREATE
TABLE" statements to distribute tables to concrete nodes by concrete way. In
this case developer doesn't help and it is not what named "transparency."


***************************
###  Vladimir Stavrinov
###  vst...@gm...
***************************