Andreas Pflug pgadmin
Sat Oct 1 09:11:31 PDT 2005
cbbrowne at ca.afilias.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


More information about the Slony1-general mailing list