My last email was written before reading this. A few episodes of 24 occurred between writing and sending that email.
Added slony1-hackers, but didn't remove pgsql-hackers. Feel free to exclude pgsql lists, as this branch of conversation seems to be more Slony related than Postgres. On Sun, May 26, 2013 at 10:59 PM, Christopher Browne <cbbro...@gmail.com>wrote: > > In Slony 2.1, the issue re-emerged because the ordering of the "action id" > values was lost; the query had previously been implicitly forcing them into > order; we had to add an "ORDER BY" clause, to make the "compressor" work > again. > > http://git.postgresql.org/gitweb/?p=slony1-engine.git;a=blobdiff;f=src/slon/remote_worker.c;h=b1f48043f8e25b4a74a392b0dbceeae8f3e18c27;hp=7fbf67c16f97cb7c3f209cf3be903ea52c4490a9;hb=c4ac435308a78a2db63bf267d401d842c169e87d;hpb=d4612aab78bac5a9836e3e2425c403878f7091c8 > > Commit log says it was fixed between 2.1.2, but from the Slony logs at the time, the version in use was 2.1.2. So > Joking about "640K" aside, it doesn't seem reasonable to expect a truly > enormous query as is generated by the broken forms of this logic to turn > out happily. I'd rather fix Slony (as done in the above patch). > Yes, by all means, fix the application, but that doesn't preclude the argument that the database should be a bit more smarter and efficient, especially if it is easy to do. Best regards, -- Gurjeet Singh http://gurjeet.singh.im/ EnterpriseDB Inc.
