Slony1 PostgreSQL Replication - Slony-I 1.1.5 Released

Author

Slony-I 1.1.5 Released

Chris Browne

2006-01-26, 5:00 pm

At long last, here is version 1.1.5, which now supports PostgreSQL version 8.1.

This has been run thru the Release Checklist

There are two tarballs: slony1-1.1.5.tar.bz2 and prebuilt docs:
slony1-docs-1.1.5-docs.tar.bz2 [see <http://slony.info/ for URLs...]
http://developer.postgresql.org/~wi...1-1.1.5.tar.bz2
http://developer.postgresql.org/~wi....5-docs.tar.bz2

The sources include the "new generation" test scripts, which make
running a set of tests easier; see tests/README for more details.

There are a few pointedly tasty improvements in store:

1. Compatibility with 8.1. There was a sort of "interlock" that
abused pg_listener in order to make sure that each node was being
managed by one and only one slon process. Functionality of
Async_Unlisten() changed in 8.1, so we had to change strategy to
use a new custom table to manage this.

2. Improved SUBSCRIBE SET performance. Indices are temporarily
detached during the COPY statements, and then reattached and
reindexed, which, in principle, should mean that subscribing a set
should even be a bit faster than restoring from pg_dump (with
Slony-I all the indices are regenerated together, so there should
be benefits from the data already being in cache).

3. The New Generation test scripts have been added in, which should
make it easier to run tests.

4. TRUNCATE is used to clear out tables at subscription time, if
possible.

5. Man pages for slon, slonik, as well as all the slonik commands
can now be generated. (It's unclear if this will necessarily be
widely packaged straight off.)

6. There is official Debian packaging under way, in the
"experimental" area.

7. A fairly large number of minor bugs that have been reported have
been fixed.
--
output = ("cbbrowne" "@" "acm.org")
http://cbbrowne.com/info/linuxdistributions.html
"What is the purpose of a person acquiring perfect French
pronunciation if they have nothing of value to say in any language?"
-- Walter Ong

Jacques Caron

2006-01-27, 7:24 am

Hi all,

Of course, bug fixes always come in after the release is published :-/

At 20:42 26/01/2006, Chris Browne wrote:
> 2. Improved SUBSCRIBE SET performance. Indices are temporarily
> detached during the COPY statements, and then reattached and
> reindexed, which, in principle, should mean that subscribing a set
> should even be a bit faster than restoring from pg_dump (with
> Slony-I all the indices are regenerated together, so there should
> be benefits from the data already being in cache).

[...]

> 4. TRUNCATE is used to clear out tables at subscription time, if
> possible.

There is an issue with these two: if TRUNCATE fails (because there's
a foreign key referencing that table), then the index creation is not
deferred (the exception rolls back any changes in prepareTableForCopy)
.

Proposed fix (put the truncate-else-delete in a nested BEGIN block):

--- src/backend/slony1_funcs.v80.sql.orig Fri Jan 6 18:07:46 2006
+++ src/backend/slony1_funcs.v80.sql Fri Jan 27 11:32:13 2006
@@ -47,17 +47,20 @@
-- ----
update pg_class set relhasindex = ''f'' where oid = v_tab_oid;

- -- ----
- -- Try using truncate to empty the table and fallback to
- -- delete on error.
- -- ----
- execute ''truncate '' || @NAMESPACE@. slon_quote_input(v_t
ab_fqname);
- raise notice ''truncate of % succeeded'', v_tab_fqname;
- return 1;
- exception when others then
- raise notice ''truncate of % failed - doing delete'',
v_tab_fqname;
- execute ''delete from only '' ||
@NAMESPACE@. slon_quote_input(v_t
ab_fqname);
- return 0;
+ begin
+ -- ----
+ -- Try using truncate to empty the table and fallback to
+ -- delete on error.
+ -- ----
+ execute ''truncate '' ||
@NAMESPACE@. slon_quote_input(v_t
ab_fqname);
+ raise notice ''truncate of % succeeded'', v_tab_fqname;
+ return 1;
+ exception
+ when others then
+ raise notice ''truncate of % failed - doing
delete'', v_tab_fqname;
+ execute ''delete from only '' ||
@NAMESPACE@. slon_quote_input(v_t
ab_fqname);
+ return 0;
+ end;
end;
' language plpgsql;

This is against 1.1.5-rc3, but I think it should work against the
release as well.

Also TRUNCATE is only used for PostgreSQL 8.0+, apparently.

I have another issue at the moment with a supposedly duplicate key in
the updates just after the copy_set is done, I'll post when I have
more info (and hopefully a fix).

Jacques.

Christopher Browne

2006-01-29, 8:24 pm

Jacques Caron wrote:

>Hi all,
>
>Of course, bug fixes always come in after the release is published :-/
>
>At 20:42 26/01/2006, Chris Browne wrote:
>
>
>
>[...]
>
>
>
>
>There is an issue with these two: if TRUNCATE fails (because there's
>a foreign key referencing that table), then the index creation is not
>deferred (the exception rolls back any changes in prepareTableForCopy)
.
>
>Proposed fix (put the truncate-else-delete in a nested BEGIN block):
>
>--- src/backend/slony1_funcs.v80.sql.orig Fri Jan 6 18:07:46 2006
>+++ src/backend/slony1_funcs.v80.sql Fri Jan 27 11:32:13 2006
>@@ -47,17 +47,20 @@
> -- ----
> update pg_class set relhasindex = ''f'' where oid = v_tab_oid;
>
>- -- ----
>- -- Try using truncate to empty the table and fallback to
>- -- delete on error.
>- -- ----
>- execute ''truncate '' || @NAMESPACE@. slon_quote_input(v_t
ab_fqname);
>- raise notice ''truncate of % succeeded'', v_tab_fqname;
>- return 1;
>- exception when others then
>- raise notice ''truncate of % failed - doing delete'',
>v_tab_fqname;
>- execute ''delete from only '' ||
>@NAMESPACE@. slon_quote_input(v_t
ab_fqname);
>- return 0;
>+ begin
>+ -- ----
>+ -- Try using truncate to empty the table and fallback to
>+ -- delete on error.
>+ -- ----
>+ execute ''truncate '' ||
>@NAMESPACE@. slon_quote_input(v_t
ab_fqname);
>+ raise notice ''truncate of % succeeded'', v_tab_fqname;
>+ return 1;
>+ exception
>+ when others then
>+ raise notice ''truncate of % failed - doing
>delete'', v_tab_fqname;
>+ execute ''delete from only '' ||
>@NAMESPACE@. slon_quote_input(v_t
ab_fqname);
>+ return 0;
>+ end;
> end;
> ' language plpgsql;
>
>This is against 1.1.5-rc3, but I think it should work against the
>release as well.
>
>
That code hadn't changed between RC3 and the release, so yes, that ought
to work.

I don't want to seem overly grumpy about this, but we have been
releasing release candidates since early December. There was a month
and a half of release candidates; was there some special reason not to
have mentioned this *before* we released 1.1.5?

I'm much much grumpier about the paucity of test reports; despite
repeated solicitations, apparently nobody much cares about whether
Slony-I can be claimed to be supportable on Solaris. Virtually all of
the test reports were from people internal to Afilias, and there are
plenty of platforms that we conspicuously *don't* care about, and won't
be testing.

>Also TRUNCATE is only used for PostgreSQL 8.0+, apparently.
>
>
Yes, it's only as of 8.x that we have subtransactions so that we can
*attempt* the truncate and actually have a recovery if that fails.

>I have another issue at the moment with a supposedly duplicate key in
>the updates just after the copy_set is done, I'll post when I have
>more info (and hopefully a fix).
>
>
>
Fixes are good... Repeatable test cases are also very good...

Sponsored Links