On Fri, 22 Oct 2004, Jan Wieck wrote:

> On 10/22/2004 2:24 PM, Christopher Browne wrote:
> 
> > Matthew Wild <M.Wild at rl.ac.uk> writes:
> > > On Fri, 22 Oct 2004, Ed L. wrote:
> > > 
> > > > On Friday October 22 2004 8:20, Matthew Wild wrote:
> > > > >
> > > > > I'm trying to get slony working on a Tru64 master running postgres
> > > > 7.3.7
> > > > > replicating to a Linux slave running postgres 7.4.5 and have been held
> > > > up
> > > > > by the threadsafe-libpq problem. Is there a patch available for 7.3.7?
> > > > > Would going to 7.4.5 help, or does that still need patching?
> > > > 
> > > > What specific indicators of a threadsafe-libpq problem are you seeing?
> > > > Can you post error message or the like so others can tell if they're
> > > > experiencing the same thing?
> > > > 
> > > 
> > > I get this continually repeating on the master node.
> > > 
> > > ERROR remoteListenThread_2: "select ev_origin, ev_seqno, ev_timestamp,
> > > ev_minxid, ev_maxxid, ev_xip, ev_t ype, ev_data1, ev_data2, ev_data3,
> > > ev_data4, ev_data5, ev_data6, ev_data7, ev_data8 from "_w
> > > dc_digisondes".sl_event e where (e.ev_origin = '2' and e.ev_seqno > '0')
> > > order by e.ev_origin, e.ev_seqno" - could not r eceive data from server:
> > > Successful
> > > 
> > > The slave is sitting there reporting nothing after this
> > > 
> > > CONFIG storeSubscribe: sub_set=1 sub_provider=1 sub_forward='f'
> > 
> > I have seen the following message on Solaris when there was a mismatch
> > vis-a-vis linking to the proper threaded libraries:
> > 
> > DEBUG1 remoteListenThread_1: connected to 'host=host004 dbname=pgbenchrep
> > user=postgres port=5432'
> > ERROR  remoteListenThread_1: "select ev_origin, ev_seqno, ev_timestamp,
> > ev_minxid, ev_maxxid, ev_xip,        ev_type,        ev_data1, ev_data2,
> > ev_data3, ev_data4,        ev_data5, ev_data6,        ev_data7, ev_data8
> > from "_pgbenchtest".sl_event e where (e.ev_origin = '1' and e.ev_seqno >
> > '1') order by e.ev_origin, e.ev_seqno" - could not receive data from server:
> > Operation now in progress
> > 
> > You sure seem to have hit the threading issue.
> > 
> > I'm not sure what the solution will be, but it's useful to at least
> > track down where the error lies...
> 
> Usually the threading issue manifests itself in an "error=0" message during
> copy_set(). An easy way to test if it is a configuration problem or a general
> slony issue is to run one of the src/ducttape tests.
> 
Well, I've tried running the ducctape/test_1_pgbench script and all I get 
is :

**** running 'gmake install' in src directory ... test_1_pgbench: !: not 
found
done
rm: /tmp/output.2970400: No such file or directory
**** remove old test databases
DROP DATABASE
ERROR:  DROP DATABASE: database "slony_test2" does not exist
dropdb: database removal failed
**** ignored
**** creating database for Node 1
CREATE DATABASE
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
'branches_pkey' for table 'branches'
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
'tellers_pkey' for table 'tellers'
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
'accounts_pkey' for table 'accounts'
creating tables...
10000 tuples done.
20000 tuples done.
30000 tuples done.
40000 tuples done.
50000 tuples done.
60000 tuples done.
70000 tuples done.
80000 tuples done.
90000 tuples done.
100000 tuples done.
vacuum...WARNING:  Skipping "pg_database" --- only table or database owner 
can VACUUM it
WARNING:  Skipping "pg_group" --- only table or database owner can VACUUM 
it
WARNING:  Skipping "pg_shadow" --- only table or database owner can VACUUM 
it
done.
**** pgbench is running in background with pid 2970450
**** sleeping 10 seconds to give pgbench time for rampup ... done

**********************************************************************
**** slony_test1 is now a standalone database with a running pgbench
**********************************************************************

**** initializing slony_test1 as Primary Node for Slony-I cluster T1
<stdin>:4: loading of file /usr/local/pgsql/share/xxid.v73.sql: 
PGRES_FATAL_ERROR ERROR:  current transaction is aborted, queries ignored 
until end of transaction block
ERROR:  current transaction is aborted, queries ignored until end of 
transaction block

I see nothing wrong with the xxid.v73.sql file, but then I'm not sure what 
I'm supposed to see. :-)

Matthew
-- 
Matthew Wild                       Tel.: +44 (0)1235 445173
M.Wild at rl.ac.uk                    URL http://www.wdc.rl.ac.uk/
World Data Centre - Solar-Terrestrial Physics, Chilton
Rutherford Appleton Laboratory, Chilton, Didcot, Oxon, OX11 0QX