> I just tested slony cvs head, and found that creation from scratch
> (using the unmodified slony scripts) will work ok, but joining will fail
> with the bug reported repeatedly from enablenode_int inserting into
> sl_confirm (illegal default for con_timestamp). Since I didn't test
> 1.1.1, this might not apply to that version, don't know so far, don't
> have the time to test right now.
This is not, and never has been, a bug in Slony-I.
It IS a bug in your system configuration, in that your environment is
using a timezone incompatible with PostgreSQL.
"Fixing" Slony-I so that it is less likely to report this problem merely
masks the true problem which will persist until you fix TZ/PGTZ in your
environment.
You can expect, based on the incorrect configuration of timezone
information on your system, that you will sporadically encounter problems
(unrelated to Slony-I) where transactions will fail due to this incorrect
configuration.
I am reluctant to go to heroic extremes to prevent people from "shooting
themselves in the foot." People who can't get their system configuration
set up correctly ought to wonder if it's a wise idea to add the risks of
further "moving parts" such as replication to their environment.
> Second, there's still not a viable alternative how to store path
> information without admin nodes. I'm running out of time now, so I'll
> continue that way, we'll have to make sure that in our fork listens are
> generated from enabled nodes only (AFAICS usual slonik work will never
> leave un-enabled nodes, so nobody should ever notice).
There never was a real proposal presented, so there hasn't been anything
to consider.
I'm a bit disagreeable about it; if my impressions are correct that this
is about coming up with a place to stow the "admin conninfo" information,
I think pgadmin should stow it in its own additional table, therefore
making the new data completely invisible and irrelevant to slon/slonik. I
haven't heard any reasons to consider that wrong.
Nobody else has publicly presented any sort of agreement on this, which
pretty forcibly establishes that there is not any agreement at this time
as to how this ought to be handled.
I am certainly not going to patch either stable or experimental releases
based on such a lack of agreement.
