pgpool 2.5b2 released

Tatsuo Ishii wrote:

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:
http://pgfoundry.org/projects/pgpool/

Wow, that is great! I know Jan was waiting for this.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

From: "Tatsuo Ishii" <t-ishii@sra.co.jp>

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!

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.

Julian Scarfe

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

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?

Others are much better place to answer this, but my understanding is that
Slony does not do so:

http://gborg.postgresql.org/project/slony1/genpage.php?howto_overview
"What Slony-I is not:

Slony-I is not a network management system. Slony-I does not have any
functionality within it to detect a node failure, or automatically promote a
node to a master or other data origin. Slony-I is not multi-master; it's
not
a connection broker, and it doesn't make you coffee and toast in the
morning."

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

Since pgpool has this capability, how about including a hook that allows a
script to be run when pgpool detects a problem with the master? That would
allow action to be taken to investigate further and, if required, switchover
or failover and promote the slave to master.

Julian Scarfe

On 2/2/2005 11:57 AM, Bruce Momjian wrote:

Tatsuo Ishii wrote:

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:
http://pgfoundry.org/projects/pgpool/

Wow, that is great! I know Jan was waiting for this.

This is incredible! I definitely did wait for this and some people at
the Solutions Linux here in Paris did ask about it. Too bad that I
didn't read this earlier, it would have made their day.

Thank you Tatsuo. I will check this out when I'm back home.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

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

Since pgpool has this capability, how about including a hook that allows a
script to be run when pgpool detects a problem with the master? That would
allow action to be taken to investigate further and, if required, switchover
or failover and promote the slave to master.

Because it is not the place of a connection management software
to failover. Failover should happen only if:

1. You have a specific set of criteria that is matched via a network/system
management software.

2. You do it yourself.

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

Sincerely,

Joshua D. Drake

Julian Scarfe

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

From: "Joshua D. Drake" <jd@commandprompt.com>

Since pgpool has this capability, how about including a hook that allows

a

script to be run when pgpool detects a problem with the master? That

would

allow action to be taken to investigate further and, if required,

switchover

or failover and promote the slave to master.

Because it is not the place of a connection management software
to failover. Failover should happen only if:

1. You have a specific set of criteria that is matched via a

network/system

management software.

2. You do it yourself.

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.

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

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

After takin a swig o' Arrakan spice grog, julian@avbrief.com ("Julian Scarfe") belched out:

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.

_There_ lies the one change that is needed. Given that, some outside
'oracle' can be used to decide if it's appropriate to do a FAILOVER.

It's quite important for this not to be deeply embedded in pgpool...
--
let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/slony.html
PALINDROME spelled backwards is EMORDNILAP.

Hello,

Command Prompt develops a lot of web based applications.
One of the problems with the web is you can't really
pre determine a lot of tasks because of the statelessness.

It would be nice if you could tell pgpool to perform certain
queries on initialization of a new connection. This would
allow web based applications to take advantange of several
nice features including:

cursors for more than just the single session
global variables
preloaded indexes for performance in ram

etc...

Thoughts?

Sincerely,

Joshua D. Drake

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

After takin a swig o' Arrakan spice grog, julian@avbrief.com ("Julian

Scarfe") belched out:

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.

_There_ lies the one change that is needed. Given that, some outside
'oracle' can be used to decide if it's appropriate to do a FAILOVER.

It's quite important for this not to be deeply embedded in pgpool...

I think we have a consensus on that. So what's the most sensible mechanism
for the "shout". Since I posted my original question, I realized that
pgpool notes a failure of either master or slave in its log. Would we want
something more proactive?

Julian

Tatsuo Ishii wrote:

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.

First of all, thanks so much Tatsuo for such a great project!

This is incredible! I definitely did wait for this and some people at
the Solutions Linux here in Paris did ask about it. Too bad that I
didn't read this earlier, it would have made their day.

Don't worry!

On Feb 2nd, when we saw both Tatsuo did move his pgpool to pgfoundry, I
downloaded the tarball, and played all the night with it, so on Feb 3rd
(yep, last day, too bad), I gave back the info all the day on it to the
people with the kind of problems pgpool and/or slony can resolve.

Cheers,

--
Jean-Paul Argudo
www.PostgreSQLFr.org

# julian@avbrief.com / 2005-02-06 09:34:53 -0000:

Since I posted my original question, I realized that pgpool notes a
failure of either master or slave in its log. Would we want something
more proactive?

snmp?

--
If you cc me or remove the list(s) completely I'll most likely ignore
your message. see http://www.eyrie.org./~eagle/faqs/questions.html

Hello,

Command Prompt develops a lot of web based applications.
One of the problems with the web is you can't really
pre determine a lot of tasks because of the statelessness.

It would be nice if you could tell pgpool to perform certain
queries on initialization of a new connection. This would
allow web based applications to take advantange of several
nice features including:

cursors for more than just the single session
global variables
preloaded indexes for performance in ram

Yes, I thought about that too. Probably we need two kinds of
initializations:

1) initilization for each new connection (as you requested)

2) initilization for each new client connection

I think pgpool could do both of them since it has already done series
of queries in closing client connections.
--
Tatsuo Ishii

"TI" == Tatsuo Ishii <t-ishii@sra.co.jp> writes:

TI> Yes, I thought about that too. Probably we need two kinds of
TI> initializations:

TI> 1) initilization for each new connection (as you requested)

TI> 2) initilization for each new client connection

I think this latter one is important. Take the case where I do some
"set FOO BAR" values to alter the query (eg, statement timeout or
sequence scan disable) which should be reset on new client connection
when it re-uses a backend connection.

Or is this magically handled already?

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

"TI" == Tatsuo Ishii <t-ishii@sra.co.jp> writes:

TI> Yes, I thought about that too. Probably we need two kinds of
TI> initializations:

TI> 1) initilization for each new connection (as you requested)

TI> 2) initilization for each new client connection

I think this latter one is important. Take the case where I do some
"set FOO BAR" values to alter the query (eg, statement timeout or
sequence scan disable) which should be reset on new client connection
when it re-uses a backend connection.

Or is this magically handled already?

Yes. pgpool issues "RESET ALL" at the end of each client
connection. See "reset_query_list" directive.
--
Tatsuo Ishii

Roman Neuhauser wrote:

# julian@avbrief.com / 2005-02-06 09:34:53 -0000:

Since I posted my original question, I realized that pgpool notes a
failure of either master or slave in its log. Would we want something
more proactive?

snmp?

Send out a NOTIFY that can be LISTENed for.

--
Richard Huxton
Archonet Ltd