On 10/26/2004 7:12 AM, Matthew Wild wrote:

> 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

Do you try this as a non-privileged PostgreSQL user? The DB user running 
slon and the slonik commands must be a true PostgreSQL superuser 
including catalog update permission (usecatupd=true).


Jan

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