Josh Harrison joshques at gmail.com
Tue Dec 18 07:01:28 PST 2007
On Dec 18, 2007 9:38 AM, Christopher Browne <cbbrowne at ca.afilias.info>
wrote:

> "Josh Harrison" <joshques at gmail.com> writes:
> > Im replicating a database from postrges 7.4(master) to 8.1(slave). This
> is a test database of size 6GB. I see all the tables in the slave
> replication set are being
> > locked and Im not able to access them.
> > Is this the behavior or did I do something wrong here?
> > I thought slony allows the query to be queried when the replication is
> in progress? So you cant query the slave during the replication?
>
> You are seeing the intended behaviour.
>
> Data is loaded, initially, as one rather large transaction.  (This has
> always been the case.)  The result of that is that the initial set of
> data is not visible until the subscription completes.
>
> In 1.1 and earlier, the tables were not completely locked; locks were
> acquired as work was done, which would progress things up to,
> eventually, exclusive locks on the tables in order to add in triggers.
> Unfortunately, this sometimes permitted deadlocks.  So in 1.2, the
> locks are immediately escalated to table locks right from the start.
>
> It's not really in any sense "worse" than before; you never could have
> had access to data in the tables.
> --

Thanks. So is this the case anytime the slaves are replicating ie., you cant
query the slaves when they are replicating the data anytime whether
initially to catch up with the bulk data or later even for small data
updates/inserts?

Also I came across another problem now. When the slave is replicating the
data, it stopped since there was no disk space. So now I deleted some other
unnecassary database in that disk and the disk has space now. But it will
not resume te replication. Is that common. When i checked the salve's log it
says
......
......
2007-12-18 09:54:42 EST DEBUG2 remoteWorkerThread_1: all tables for set 1
found on subscriber
2007-12-18 09:54:42 EST DEBUG2 remoteWorkerThread_1: copy table
"public"."a_method"
2007-12-18 09:54:42 EST DEBUG3 remoteWorkerThread_1: table
"public"."a_method" does not require Slony-I serial key
2007-12-18 09:54:42 EST ERROR  remoteWorkerThread_1: "select
"_slony_rmrs".setAddTable_int(1, 2,
 '"public"."a_method"', 'a_method_pk', 'a_method table'); "
PGRES_FATAL_ERROR ERRO
R:  Slony-I: setAddTable_int: table id 2 has already been assigned!
2007-12-18 09:54:42 EST WARN   remoteWorkerThread_1: data copy for set 1
failed - sleep 60 seconds.

Before the 'no disk space' problem it had copied some tables's data..say the
first few tables. So how can I make it resume the replication from where it
stopped?

This is the slony slave's log message when the error happened
2007-12-18 08:54:08 EST ERROR  remoteWorkerThread_1: "select
"_slony_rmrs".finishTableAfterCopy(
6); analyze "public"."c_var"; " PGRES_FATAL_ERROR ERROR:  could not write
block 4807
55 of relation 1663/44356/48354: No space left on device
CONTEXT:  SQL statement "reindex table "public"."c_var""
PL/pgSQL function "finishtableaftercopy" line 26 at execute statement
2007-12-18 08:54:08 EST WARN   remoteWorkerThread_1: data copy for set 1
failed - sleep 15 seconds

Thanks
josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20071218/=
c5693353/attachment-0001.htm


More information about the Slony1-general mailing list