Sat Oct 1 04:28:29 PDT 2005
- Previous message: [Slony1-general] Re: [pgadmin-hackers] Ready for beta yet?
- Next message: [Slony1-general] Ready for beta yet?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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.
- Previous message: [Slony1-general] Re: [pgadmin-hackers] Ready for beta yet?
- Next message: [Slony1-general] Ready for beta yet?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list