pgpool 2.5b2 released

[Tatsuo Ishii]

Pgpool 2.5b2 supports "master slave mode" which can cope with
master/slave replication softwares such as Slony-I. In this mode
pgpool sends non SELECT queries to master only. SELECTs are load
balanced by pgpool.

Other features of 2.5b2 include:
- ability to add timestamp to each log entry
- control to whether cache connection info or not

pgpool 2.5b2 is available at:
[url]http://pgfoundry.org/projects/pgpool/[/url]

Enjoy,
--
Tatsuo Ishii

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [email]majordomo@postgresql.org[/email] so that your
message can get through to the mailing list cleanly

[Tatsuo Ishii]

> > Pgpool 2.5b2 supports "master slave mode" which can cope with

> > master/slave replication softwares such as Slony-I. In this mode
> > pgpool sends non SELECT queries to master only. SELECTs are load
> > balanced by pgpool.

>
> Sounds good!

Thanks. Yesterday I have put offcial release of pgpool 2.5 on
pgfoundry.org. The news release has not come up yet on the top page of
pgfoundry.org for some reason I don't know, but I hope it will appear
soon.

pgpool 2.5 has the capabilty to perform periodical health checking to
PostgreSQL.

> Does it attempt any interaction with Slony when it detects a failure of the
> master? It would seem a pity to have pgpool watching the pair to detect
> failure but having to have a separate watcher process to tell Slony to
> failover.

If pgpool detects PostgreSQL failure, Slony should detect it as well,
no?
--
Tatsuo Ishii

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [email]majordomo@postgresql.org[/email] so that your
message can get through to the mailing list cleanly

[Tatsuo Ishii]

> I'm not suggesting that it's the place of pgpool to *force* a failover. I

> am suggesting that one of the criteria that is likely to be useful is the
> inability to connect to the master, and that's something that pgpool,
> apparently, detects. It seems unnecessary to use completely different
> failure-detection mechanisms for the purpose of failover to those used for
> the connection management.
>
> So all I'm looking for is a way for pgpool to shout if it detects a failure.
> That could initiate the investigation of the other criteria required for
> failover.

It's pretty easy. See main.c:failover_handler() for more details.
--
Tatsuo Ishii

> > The last thing in the world you need is to fail over to a slave because
> > somebody accidently tripped over a network cord.

>
> In our application, that's *exactly* what we need. We have a database that
> receives data in a fairly continuous stream. If the datastream cannot be
> written to the database, the database becomes worse than useless quite
> rapidly. We need the ability to switchover or failover to another node as
> master as soon as possible, to allow the datastream to be written to the
> other node. We'll rebuild the "failed" master later, if necessary. But if
> the failover doesn't happen promptly, we might as well rebuild the whole
> cluster.
>
> Julian Scarfe
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> [url]http://www.postgresql.org/docs/faq[/url]
>

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

[url]http://www.postgresql.org/docs/faq[/url]