Re: [Slony1-general] Ready for beta yet?

cbbrowne(at)ca(dot)afilias(dot)info wrote:
>>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.

You're kidding. I'll certainly *not* modify the timezone of the server,
which is set correctly. The server *is* located in the MESZ timezone,
but I certainly wouldn't expect pgsql to be able to interpret all
possible variations of time strings timeofday() might emit. Using a
function that returns timestamp directly and thus not needing to convert
won't break anything, just improve things.

>
> I am reluctant to go to heroic extremes

Hu? So using now() instead of timeofday()::timestamp is heroic?

>
> There never was a real proposal presented, so there hasn't been anything
> to consider.

It is posted...
>
> 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.

I'm not really against it; this was partially proposed beginning this
year. Still, as I already mentioned, it is necessary to have this table
propagated to all nodes, just as any other node information. So if you
invent a helper table that's replicated automatically as sl_node and
sl_path, ok.

Regards,
Andreas