[Pgcluster-general] pgreplicate misinterpretes success messages from all cluster dbs ?

Fri Oct 26 07:02:27 UTC 2007

Hi all,

me again, this time with another interesting problem:

We attempted to install a simple cluster:
1 replicator
2 cluster dbs

This behavior occured to me twice today in comparable but idfferent
setups:
Setup 1 included three machines, with pgcluster 1.7.0rc7 patch applied
to postgresql 8.2.4. The database files and binaries were in non
standard locations, we had basically no root access. System was a Debian
Etch (64bit) with 16GByte main memory and two dual core (64 bit) Intel
CPUs.

Setup 2 included two machines, with pgcluster 1.7.0rc7 patch applied to
postgresql 8.2.4. The database files and binaries were in debian standrd
ocations, we have root access. System is a Debian Etch (64bit) with
unknown amount of main memory and (I think) 2 AMD 64 bit CPUs

While the databases in setup 1 had the following problem from the very
beginning, I was at least able to create as well as drop a database
(just for kicks) on our system 2 until it stopped working. The only
difference is, setup 1 never showed me any EOF messages but simply
stopped working. (I could attempt to cut the important parts from the
logfiles and the tcpdumps from setup 1, if it helps.) Now here is the
problem:
- Start Cluster DB 1
- Start Cluster DB 2
- Start the pgreplicate
- Start a psql connection to any one of the two dbs directly
- Attempt to create a tablespace (or later on a database)
- psql hangs and waits for a reply
- The pgreplicate replicates the sql command
- The backends do their work
- You can see the results being sent to pgreplicate
- pgreplicate sends the same sql command over and over again to the
cluster dbs which now return errors, since the databases or tablespaces
have been created before
- psql still hangs and waits for a reply
- If you kill pgreplicate, psql returns with "command not allowed, since
cluster fell down ..."
- If you check both hosts directly, you can see that the create command
was successful, even the oids are the same

So what went wrong ? Do I have to setup rsync already ? I mean, I was
just tesing it out slowly. If I understood correctly, rsync is needed
once I want to restart a cluster DB in recovery mode and not a minute
earlier ?

I have attached plenty of log and config files.
If you guys are interested, I can send more logfiles and tcpdumps from
the first attempt with setup 1, but the behaviour and the logfiles were
basically the same. And the tcpdumps show the same messages the logfiles
written by the postmaster contain.

As always, thanks in advance :-)

Regards,
Holger

--
This e-mail and any attachments is confidential and solely intended for
the indicated addressee. If you are not the intended recipient or an
authorized person, please note, that any form of notice, disclosure,
reproduction or circulation of the contents of this mail is prohibited.
In this case, please immediately inform the sender of the e-mail an
destroy this e-mail. We use updated antivirus protection software. We do
not accept any responsibility for damages caused anyhow by viruses.

-
Diese Information ist ausschliesslich fuer den Adressaten bestimmt und kann 
vertraulich oder gesetzlich geschuetzte Informationen enthalten. Wenn Sie nicht 
der bestimmungsgemaesse Adressat sind, unterrichten Sie bitte den Absender und 
vernichten Sie diese Mail.
Anderen als dem bestimmungsgemaessen Adressaten ist es untersagt, diese E-Mail 
weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Wir 
verwenden aktuelle Virenschutzprogramme und Content-Filter.
Fuer Schaeden, die dem Empfaenger gleichwohl durch von uns zugesandte mit Viren 
befallene E-Mails entstehen, schliessen wir jede Haftung aus.
-         
This e-mail and any attachments is confidential and solely intended for the 
indicated addressee. If you are not the intended recipient or an authorized 
person, please note, that any form of notice, disclosure, reproduction or 
circulation of the contents of this mail is prohibited. In this case, please 
immediately inform the sender of the e-mail an destroy this e-mail. We use 
updated antivirus protection software. We do not accept any responsibility for 
damages caused anyhow by viruses.
-
catWorkX GmbH: Sitz der Gesellschaft in Hamburg, HRB: 71494, USt-IdNr.: 
DE201625856, Geschaeftsfuehrung: Dipl. Kfm. Andreas Girnuweit, Dipl.-Ing. Oliver 
Groht, Dr. Wolfgang Tank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi9-cluster.conf
Type: application/octet-stream
Size: 3140 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0012.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi9-pg_hba.conf
Type: application/octet-stream
Size: 3679 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0013.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi9-pgreplicate.conf
Type: application/octet-stream
Size: 4679 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0014.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi9-pgreplicate.log
Type: application/octet-stream
Size: 14504 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0015.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi9-pgreplicate.rid
Type: application/octet-stream
Size: 28 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0016.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi9-pgreplicate.sts
Type: application/octet-stream
Size: 1820 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0017.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi9-postgresql.conf
Type: application/octet-stream
Size: 15644 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0018.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi9-postgresql.log
Type: application/octet-stream
Size: 13095 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0019.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi12-cluster.conf
Type: application/octet-stream
Size: 3141 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0020.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi12-pg_hba.conf
Type: application/octet-stream
Size: 3679 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0021.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi12-posgresql.log
Type: application/octet-stream
Size: 14504 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0022.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debi12-postgresql.conf
Type: application/octet-stream
Size: 15644 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pgcluster-general/attachments/20071026/ed8c61fc/attachment-0023.obj 