Quinn David Weaver | 1 Oct 02:09 2014

PostgreSQL 9.4 support?

Apologies if this has been answered elsewhere; my searches of the list
archives, docs, and web at large didn't turn up anything. What is the
status of PostgreSQL 9.4 (beta, obviously) support in Slony?

Thanks,
Quinn
Jeff Frost | 1 Oct 00:18 2014

2.1.4 can't update pg_class as superuser

Seeing this error from finishTableAfterCopy:

PGRES_FATAL_ERROR ERROR:  permission denied for relation pg_class
CONTEXT:  SQL statement "update pg_catalog.pg_class set relhasindex ='t' where oid = i_oid"

slony 2.1.4 connecting to postgresql 9.2.9 as the slony user which is a postgresql superuser.

ccom=# select * from pg_authid where rolname = 'slony';
-[ RECORD 1 ]--+------------------------------------
rolname        | slony
rolsuper       | t
rolinherit     | t
rolcreaterole  | t
rolcreatedb    | t
rolcatupdate   | t
rolcanlogin    | t
rolreplication | f
rolconnlimit   | -1
rolpassword    | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
rolvaliduntil  |

Anybody have any ideas?
Ger Timmens | 22 Sep 16:58 2014

Re: Slony ignoring cleanup_interval?

> Message: 1
> Date: Fri, 19 Sep 2014 16:55:47 -0400
> From: Steve Singer <ssinger@...>
> Subject: Re: [Slony1-general] Slony ignoring cleanup_interval?
> To: Kristopher <kristopherwilson@...>,
> 	slony1-general@...
> Message-ID: <541C9853.3000307@...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 09/19/2014 01:50 PM, Kristopher wrote:
>> I have the following setup in my conf file:
>>
>> cleanup_interval="5 seconds"
>> sync_interval=1000
>>
>> cluster_name='dbcluster01'
>> conn_info='...'
>>
>> And, via the log, it looks like slony is picking up on the 5 second
>> cleanup interval:
>>
>> 2014-09-15 09:31:40 EDT CONFIG main: String option pid_file = [NULL]
>> 2014-09-15 09:31:40 EDT CONFIG main: String option archive_dir = [NULL]
>> 2014-09-15 09:31:40 EDT CONFIG main: String option sql_on_connection =
>> [NULL]
>> 2014-09-15 09:31:40 EDT CONFIG main: String option lag_interval = [NULL]
>> 2014-09-15 09:31:40 EDT CONFIG main: String option command_on_logarchive
>> = [NULL]
>> 2014-09-15 09:31:40 EDT CONFIG main: String option syslog_facility = LOCAL0
>> 2014-09-15 09:31:40 EDT CONFIG main: String option syslog_ident = slon
(Continue reading)

Diego Puertas | 22 Sep 16:34 2014

Compiling Slony 1.2.23 for Postgres 9.3.4

Hello All,

As part of a migration process from Postgres 8.1 to 9.3 I'm trying to compile Slony 1.2.23 for Postgres 9.3.4
on an Ubuntu 14.04 box.

The development package has been installed:
	postgresql-server-dev-9.3

The configure command runs OK:
	./configure --with-pgsharedir='/usr/share/postgresql

But when I run make, it breaks and complaints it can't find a library called pstrdup. This is the output of the
make command:

gcc -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../..
-DPGSHARE="\"/usr/share/postgresql\"" -DPG_VERSION_MAJOR=9 slonik.o dbutil.o parser.o 
../parsestatements/scanner.o -L/usr/lib/ -L/usr/lib/postgresql/9.3/lib/ -lpq 
-Wl,-rpath,/usr/lib/ -lpgport  -o slonik
/usr/lib//libpgport.a(wait_error.o): In function `wait_result_to_str':
(.text+0x110): undefined reference to `pstrdup'

It looks like this problem is referred to on a bug report from May 2013, and it's due to the fact that Postgres
9.3 introduced a new library, libpgcommon. I've tried to link this library by adding the following line at
the end of config/acx_libpq.m4 :
	LIBS="$LIBS -lpgcommon"

But the result is the same.

Did you find this problem before? How did you solve it?

(Continue reading)

Kristopher | 19 Sep 19:50 2014
Picon

Slony ignoring cleanup_interval?

I have the following setup in my conf file:

cleanup_interval="5 seconds"
sync_interval=1000

cluster_name='dbcluster01'
conn_info='...'

And, via the log, it looks like slony is picking up on the 5 second cleanup interval:

2014-09-15 09:31:40 EDT CONFIG main: String option pid_file = [NULL]
2014-09-15 09:31:40 EDT CONFIG main: String option archive_dir = [NULL]
2014-09-15 09:31:40 EDT CONFIG main: String option sql_on_connection = [NULL]
2014-09-15 09:31:40 EDT CONFIG main: String option lag_interval = [NULL]
2014-09-15 09:31:40 EDT CONFIG main: String option command_on_logarchive = [NULL]
2014-09-15 09:31:40 EDT CONFIG main: String option syslog_facility = LOCAL0
2014-09-15 09:31:40 EDT CONFIG main: String option syslog_ident = slon
2014-09-15 09:31:40 EDT CONFIG main: String option cleanup_interval = 5 seconds

However, it only actually runs cleanup about every 10 minutes (the default):

NOTICE:  Slony-I: log switch to sl_log_1 complete - truncate sl_log_2
CONTEXT:  PL/pgSQL function _dbcluster01.cleanupevent(interval) line 94 at assignment
2014-09-18 06:28:40 EDT INFO   cleanupThread:    0.368 seconds for cleanupEvent()
NOTICE:  Slony-I: Logswitch to sl_log_2 initiated
CONTEXT:  SQL statement "SELECT "_dbcluster01".logswitch_start()"
PL/pgSQL function _dbcluster01.cleanupevent(interval) line 96 at PERFORM
2014-09-18 06:39:27 EDT INFO   cleanupThread:    0.018 seconds for cleanupEvent()
NOTICE:  Slony-I: log switch to sl_log_2 complete - truncate sl_log_1
CONTEXT:  PL/pgSQL function _dbcluster01.cleanupevent(interval) line 94 at assignment
2014-09-18 06:51:10 EDT INFO   cleanupThread:    0.106 seconds for cleanupEvent()
2014-09-18 06:51:10 EDT INFO   cleanupThread:    0.006 seconds for vacuuming
NOTICE:  Slony-I: Logswitch to sl_log_1 initiated
CONTEXT:  SQL statement "SELECT "_dbcluster01".logswitch_start()"
PL/pgSQL function _dbcluster01.cleanupevent(interval) line 96 at PERFORM
2014-09-18 07:01:52 EDT INFO   cleanupThread:    0.016 seconds for cleanupEvent()
NOTICE:  Slony-I: log switch to sl_log_1 complete - truncate sl_log_2
CONTEXT:  PL/pgSQL function _dbcluster01.cleanupevent(interval) line 94 at assignment
2014-09-18 07:13:33 EDT INFO   cleanupThread:    0.110 seconds for cleanupEvent()
NOTICE:  Slony-I: Logswitch to sl_log_2 initiated
CONTEXT:  SQL statement "SELECT "_dbcluster01".logswitch_start()"
PL/pgSQL function _dbcluster01.cleanupevent(interval) line 96 at PERFORM
2014-09-18 07:24:46 EDT INFO   cleanupThread:    0.014 seconds for cleanupEvent()
2014-09-18 07:24:46 EDT INFO   cleanupThread:    0.006 seconds for vacuuming
NOTICE:  Slony-I: log switch to sl_log_2 complete - truncate sl_log_1
CONTEXT:  PL/pgSQL function _dbcluster01.cleanupevent(interval) line 94 at assignment
2014-09-18 07:36:17 EDT INFO   cleanupThread:    0.114 seconds for cleanupEvent()
NOTICE:  Slony-I: Logswitch to sl_log_1 initiated
CONTEXT:  SQL statement "SELECT "_dbcluster01".logswitch_start()"
PL/pgSQL function _dbcluster01.cleanupevent(interval) line 96 at PERFORM
2014-09-18 07:47:31 EDT INFO   cleanupThread:    0.018 seconds for cleanupEvent()

In order to perform the upgrade to the latest version, it says I need to set this interval low to clear up any data in the log tables, but I'm stuck trying to get that to happen.

Any ideas? 


Kristopher

_______________________________________________
Slony1-general mailing list
Slony1-general@...
http://lists.slony.info/mailman/listinfo/slony1-general
umang singh | 28 Aug 20:58 2014
Picon

Unavailability of a node and time outs

Hi All,

The slony documentation mentions that Slony-I is a system designed for use at data centers and backup sites, where the normal mode of operation is that all nodes are available. 

I am using slony to replicate the database between 2 nodes.In case the node housing the master database is unavailable, does slony running on the node running the slave database timeout trying to connect to the master database or will it try to attempt connecting to the master database indefinitely?

When the mode housing the master DB is down, I am getting repeated "could not connect to server: No route to host" logs on the slave node and it is not entirely clear whether slony is generating this log or whether it is because of some other psql command.

Regards,
Umang
_______________________________________________
Slony1-general mailing list
Slony1-general@...
http://lists.slony.info/mailman/listinfo/slony1-general
Sandeep Thakkar | 25 Aug 09:27 2014

Slony1-2.2.3 sources fails to compile on Linux against PG9.4

Hi

While building Slony1-2.2.3 tarball on Linux against PG9.4, I observed that the configure failed for the following reason:-

--
configure:5703: checking for pgport
configure:5729: gcc -o conftest -g -O2   -I/mnt/hgfs/pginstaller/server/staging/linux-x64/include/postgresql/server/  -L/mnt/hgfs/pginstaller/server/staging/linux-x64/lib/ conftest.c  -lpgcommon >&5
configure:5729: $? = 0
configure:5731: result: yes
configure:5763: gcc -o conftest -g -O2   -I/mnt/hgfs/pginstaller/server/staging/linux-x64/include/postgresql/server/  -L/mnt/hgfs/pginstaller/server/staging/linux-x64/lib/ conftest.c  -lpgport  -lpgcommon >&5
/mnt/hgfs/pginstaller/server/staging/linux-x64/lib//libpgcommon.a(exec.o): In function `resolve_symlinks':
exec.c:(.text+0x1a6): undefined reference to `last_dir_separator'
exec.c:(.text+0x1f5): undefined reference to `strlcpy'
exec.c:(.text+0x219): undefined reference to `join_path_components'
exec.c:(.text+0x221): undefined reference to `canonicalize_path'
/mnt/hgfs/pginstaller/server/staging/linux-x64/lib//libpgcommon.a(exec.o): In function `find_my_exec':
exec.c:(.text+0x36d): undefined reference to `first_dir_separator'
exec.c:(.text+0x38c): undefined reference to `join_path_components'
exec.c:(.text+0x394): undefined reference to `canonicalize_path'
exec.c:(.text+0x474): undefined reference to `first_path_var_separator'
exec.c:(.text+0x4c3): undefined reference to `join_path_components'
exec.c:(.text+0x4d1): undefined reference to `join_path_components'
exec.c:(.text+0x4d9): undefined reference to `canonicalize_path'
exec.c:(.text+0x552): undefined reference to `join_path_components'
/mnt/hgfs/pginstaller/server/staging/linux-x64/lib//libpgcommon.a(exec.o): In function `set_pglocale_pgservice':
exec.c:(.text+0x620): undefined reference to `get_etc_path'
exec.c:(.text+0x641): undefined reference to `canonicalize_path'
/mnt/hgfs/pginstaller/server/staging/linux-x64/lib//libpgcommon.a(exec.o): In function `find_other_exec':
exec.c:(.text+0x6c1): undefined reference to `last_dir_separator'
exec.c:(.text+0x6cc): undefined reference to `canonicalize_path'
collect2: ld returned 1 exit status
--

$ nm -oA server/staging/linux-x64/lib/libpg* | grep last_dir_separator
server/staging/linux-x64/lib/libpgcommon.a:exec.o:                 U last_dir_separator
server/staging/linux-x64/lib/libpgport.a:path.o:0000000000000070 T last_dir_separator

So, I'm wondering why do we see undefined symbol even though pgport lib is  included in the linking 


--
Sandeep Thakkar

_______________________________________________
Slony1-general mailing list
Slony1-general@...
http://lists.slony.info/mailman/listinfo/slony1-general
Venkata Balaji N | 23 Aug 11:30 2014
Picon

Slony-I Upgrade

Hello All,

We are upgrading our existing Slony-I installations across our production servers.

We are upgrading from version 2.0.3 to version 2.2.3.

We will have our Applications down for an other scheduled activity

Below is our upgrade procedure -
  • Install Slony-I-2.2.3 on all the nodes
  • Issue SLONIK_UPDATE_NODES -c <config file>  from any of the nodes (we do it from our master node)
  • Start the slon processes for all the nodes
Will this be OK to upgrade from 2.0.3 to 2.2.3 ?

Please help us know if we have to do anything else.

Regards,
VBN


_______________________________________________
Slony1-general mailing list
Slony1-general@...
http://lists.slony.info/mailman/listinfo/slony1-general
Venkata Balaji N | 22 Aug 11:30 2014
Picon

Need help with a production issue

Hello Everyone,

We have a situation where  Slony schema on a slave node was accidentally dropped.

Is there any quick way around for this ?

We have a master replicating to 3 slaves and one of the slaves does not have the Slony schema.

- Can we just un-subscribe that slave and resubscribe back to catch up with the sync ?

In anyone faced such situation, please help us with this.

Regards,
VBN
_______________________________________________
Slony1-general mailing list
Slony1-general@...
http://lists.slony.info/mailman/listinfo/slony1-general
Jeff Frost | 19 Aug 05:23 2014

Re: undefined symbol: HeapTupleHeaderGetDatum

On Aug 18, 2014, at 5:23 PM, Brian Fehrle
<brianf@...> wrote:

> Hi All, 
> 
> I'm trying to get a slony 2.2.3 cluster up and running on postgres 9.3.5, and am running into the below error:
> 
> [postgres <at> localhost bin]$ ./init_cluster.sh ../etc/slony.cfg
> <stdin>:305: loading of file /usr/pgsql-9.3/share//slony1_base.2.2.3.sql: PGRES_FATAL_ERROR
ERROR:  could not load library "/usr/pgsql-9.3/lib/plpgsql.so": /usr/pgsql-9.3/lib/plpgsql.so:
undefined symbol: HeapTupleHeaderGetDatum
> ERROR:  could not load library "/usr/pgsql-9.3/lib/plpgsql.so": /usr/pgsql-9.3/lib/plpgsql.so:
undefined symbol: HeapTupleHeaderGetDatum
> 
> Some system info:
> cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 6.5 (Santiago)
> (64 bit)
> 
> rpm -qa | grep slony
> slony1-93-2.2.3-1.rhel6.x86_64
> 
> rpm -qa | grep postgres
> postgresql93-devel-9.3.5-1PGDG.rhel6.x86_64
> postgresql93-libs-9.3.5-1PGDG.rhel6.x86_64
> postgresql93-9.3.5-1PGDG.rhel6.x86_64
> postgresql93-contrib-9.3.5-1PGDG.rhel6.x86_64
> postgresql93-server-9.3.5-1PGDG.rhel6.x86_64
> 
> I'm suspecting it's an issue with plpgsql itself, but not quite sure yet, wondering if anyone has seen this
recently. 

Any chance you've got more than one set of postgresql packages installed?

What does:

ldconfig /usr/pgsql-9.3/lib/plpgsql.so

return?
Brian Fehrle | 19 Aug 02:23 2014

undefined symbol: HeapTupleHeaderGetDatum

Hi All, 

I'm trying to get a slony 2.2.3 cluster up and running on postgres 9.3.5, and am running into the below error:

[postgres <at> localhost bin]$ ./init_cluster.sh ../etc/slony.cfg
<stdin>:305: loading of file /usr/pgsql-9.3/share//slony1_base.2.2.3.sql: PGRES_FATAL_ERROR ERROR:  could not load library "/usr/pgsql-9.3/lib/plpgsql.so": /usr/pgsql-9.3/lib/plpgsql.so: undefined symbol: HeapTupleHeaderGetDatum
ERROR:  could not load library "/usr/pgsql-9.3/lib/plpgsql.so": /usr/pgsql-9.3/lib/plpgsql.so: undefined symbol: HeapTupleHeaderGetDatum

Some system info:
cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.5 (Santiago)
(64 bit)

rpm -qa | grep slony
slony1-93-2.2.3-1.rhel6.x86_64

rpm -qa | grep postgres
postgresql93-devel-9.3.5-1PGDG.rhel6.x86_64
postgresql93-libs-9.3.5-1PGDG.rhel6.x86_64
postgresql93-9.3.5-1PGDG.rhel6.x86_64
postgresql93-contrib-9.3.5-1PGDG.rhel6.x86_64
postgresql93-server-9.3.5-1PGDG.rhel6.x86_64

I'm suspecting it's an issue with plpgsql itself, but not quite sure yet, wondering if anyone has seen this recently. 

Thanks,
- Brian F
_______________________________________________
Slony1-general mailing list
Slony1-general@...
http://lists.slony.info/mailman/listinfo/slony1-general

Gmane