Is this something that will be fixed, or is it 'not supported'?



JP Fletcher wrote:
> Hi,
>
>
> I'm able to reproduce this condition repeatedly.  The scenario is as 
> follows:
>
> Set1 has origin on node8143, which is data provider to node8141, which 
> in turn is provider to node8194 :
>
> 8143 --> 8141 --> 8194
>
>
> I add set2, which has origin on node8143.  I then subscribe node8194 
> to node8143 directly.
>                                  This breaks node8194 immediately.  
> The slon logs for node 8194 show:
>
> 2007-09-19 19:42:01 UTC ERROR  remoteWorkerThread_8143: "declare LOG 
> cursor for select     log_origin, log_xid, log_tableid,     
> log_actionseq, log_cmdtype,     octet_length(log_cmddata),     case 
> when octet_length(log_cmddata) <= 8192         then 
> log_cmddata         else null end from "_cluster".sl_log_1 where 
> log_origin = 8143 and (  order by log_actionseq; " PGRES_FATAL_ERROR 
> ERROR:  syntax error at or near "order" at character 283
> 2007-09-19 19:42:01 UTC ERROR  remoteWorkerThread_8143: "close LOG; " 
> PGRES_FATAL_ERROR ERROR:  current transaction is aborted, commands 
> ignored until end of transaction block
>
>
>
> JP
>
> Christopher Browne wrote:
>> JP Fletcher <jpfletch at ca.afilias.info> writes:
>>
>>  
>>> Hi,
>>>
>>> My 1.2.11 cluster abruptly stopped working, with the following error
>>> message present in the pg logs of the origin:
>>>
>>> 2007-09-13 20:29:06.358 UTC [1679750] cluster slony 10.1.2.133 ERROR:
>>> syntax error at or near "order" at character 283
>>> 2007-09-13 20:29:06.358 UTC [1679750] cluster slony 10.1.2.133
>>> STATEMENT:  declare LOG cursor for select     log_origin, log_xid,
>>> log_tableid,     log_actionseq, log_cmdtype,
>>> octet_length(log_cmddata),     case when octet_length(log_cmddata) <=
>>> 8192         then log_cmddata         else null end from
>>> "_cluster".sl_log_1 where log_origin = 8143 and (  order by
>>> log_actionseq;
>>>
>>>
>>> I had been changing some subscriptions around,  with no evidence of
>>> failure.  Apart from that, the cluster wasn't doing anything...
>>>     
>>
>> Hmm.  This sounds a whole lot like:
>>
>> <http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226>
>>
>> That was supposedly fixed about two years ago.
>>   
>
>


-- 
JP Fletcher
Database Administrator
Afilias Canada
voice: 416.646.3304 ext. 4123
fax: 416.646.3305
mobile: 416.561.4763
jpfletch at ca.afilias.info