Summary: | slony doesn't escape varchar fields properly, making it impossible to replicate varchar or bytea columns in some cases | ||
---|---|---|---|
Product: | Slony-I | Reporter: | Grzegorz Jaskiewicz <gj> |
Component: | slon | Assignee: | Slony Bugs List <slony1-bugs> |
Status: | ASSIGNED --- | ||
Severity: | normal | CC: | slony1-bugs |
Priority: | medium | ||
Version: | devel | ||
Hardware: | PC | ||
OS: | Linux |
Description
Grzegorz Jaskiewicz
2008-10-13 09:15:44 UTC
Followup question: What are the encodings of the two databases (e.g. - origin + subscriber)? My suspicion is that either: a) Both use UTF-8, but the origin is on PostgreSQL 7.4 or 8.0, which had problems with its handling of Unicode encoding validation, or b) The origin is using SQL-ASCII or similar, and the subscriber is using Unicode/UTF-8. If either of those speculations are in fact the case, then this may NOT be a bug; Slony-I does not promise to do inter-encoding translations. Question to consider: Should the slon verify that it uses a single common encoding on all DB connections? We intend to address this in a different way, by ensuring that slon processes are using the same client encoding on all databases. Changing importance to "normal". This can be avoided by using alter user slony set client_encoding to <common-encoding>; on all servers in the Slony cluster and NOT having any of the databases use server_encoding SQL_ASCII (which is discouraged anyway). We still want to fix it, but since this is a completely new feature, we won't implement it before 2.1. |