I just implemented eRServer for one of my clients and found many problems
with it.

1.	It crashes when using ï¿½ers_addtableï¿½ to add big tables. The problem is
that it used pg_dump ï¿½d then tried to read the whole output in memory. I
fixed it by reading one row at a time and inserting it to slave.
2.	ï¿½ers_addslaveï¿½ crashes when creating table schema if one rows on the
master were dropped. Apparently, when a row was dropped, the ï¿½attnameï¿½ in
ï¿½pg_attributeï¿½ table was changed to ï¿½ï¿½ï¿½ï¿½pg.dropped.#ï¿½ï¿½ï¿½ï¿½..ï¿½ and the type of
the column became ï¿½-ï¿½. That made the ï¿½create tableï¿½ sql statement for slave
wrong. I fixed this problem by excluding those kind of columns.
3.	There was no index created on ï¿½_ers_uniqï¿½ on slave side. It took minutes
per transaction to delete on huge tables. After I found the problem and
created index on the column, it only took about 5 milliseconds to delete.
4.	To handle columns with default and nextval, eRServer expected to see
nextval('"sequence_name"'::text) and used double quote to extract sequence
names. But postgres also allow nextval('sequence_name'::text) without double
quotes. The fix was easy.
5.	eRServer.pm failed because DBI could not handle columns with types such
as ï¿½text[]ï¿½ but Pg module should work.


Hope those will be fixed in the next version. I can also provide my fixes if
needed.

John Li














I just implemented eRServer for one of my clients and found many
problems with it. 
 

It
     crashes when using “ers_addtable” to add big tables. The problem is that
     it used pg_dump –d then tried to read the whole output in memory. I fixed
     it by reading one row at a time and inserting it to slave.
“ers_addslave”
     crashes when creating table schema if one rows on the master were dropped.
     Apparently, when a row was dropped, the “attname” in “pg_attribute” table
     was changed to “………pg.dropped.#…………..” and the type of the column became “-“.
     That made the “create table” sql statement for slave wrong. I fixed this
     problem by excluding those kind of columns.
There
     was no index created on “_ers_uniq” on slave side. It took minutes per
     transaction to delete on huge tables. After I found the problem and
     created index on the column, it only took about 5 milliseconds to delete.
To
     handle columns with default and nextval, eRServer expected to see nextval('"sequence_name"'::text)
     and used double quote to extract sequence names. But postgres also allow nextval('sequence_name'::text)
     without double quotes. The fix was easy.
eRServer.pm
     failed because DBI could not handle columns with types such as “text[]”
     but Pg module should work.

 
 
Hope those will be fixed in the next
version. I can also provide my fixes if needed.
 
John
Li
Mon, 16 Feb 2004 10:16:39 -0800
"John Li" <john.li@earthlink.net>
Replication eRServer problems
John Li wrote:
> I just implemented eRServer for one of my clients and found many
> problems with it.

We do not maintain erserver.  You need to talk to the people that you 
got it from, for example here:

http://gborg.postgresql.org/project/erserver/projdisplay.php


Mon, 16 Feb 2004 21:07:53 +0100
Peter Eisentraut <peter_e@gmx.net>
Re: Replication eRServer problems
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

On Mon, 16 Feb 2004, John Li wrote:

> I just implemented eRServer for one of my clients and found many problems
> with it.

TDMSoft has patched eRServer a bit:

http://www.tdmsoft.com/tr/PostgreSQL/download/

Maybe these could help to solve your problems.

Regards,
- -- 
Devrim GUNDUZ	       
devrim@gunduz.org				devrim.gunduz@linux.org.tr 
			http://www.TDMSoft.com
			http://www.gunduz.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAMTg4tl86P3SPfQ4RAmF9AJ0Uk2JMUnhFFPTSAxiquRINniGJvQCgy++N
mzPIrxh0hPuGvbnBSxJErcw=
=cD6P
-----END PGP SIGNATURE-----


Mon, 16 Feb 2004 23:37:56 +0200 (EET)
Devrim GUNDUZ <devrim@gunduz.org>
Re: Replication eRServer problems
On Mon, Feb 16, 2004 at 10:16:39AM -0800, John Li wrote:
> I just implemented eRServer for one of my clients and found many problems
> with it.

Yep.  There's a list dedicated to it, by the way, available through
the gborg site.

> 1.	It crashes when using ?ers_addtable? to add big tables. The problem is
> that it used pg_dump ?d then tried to read the whole output in memory. I
> fixed it by reading one row at a time and inserting it to slave.

The setup scripts are pretty buggy.

> 3.	There was no index created on ?_ers_uniq? on slave side. It took minutes
> per transaction to delete on huge tables. After I found the problem and
> created index on the column, it only took about 5 milliseconds to delete.

This is a new report.  Thanks.

> Hope those will be fixed in the next version. I can also provide my fixes if
> needed.

I'm interested in seeing patches, for sure.  I'll be applying some
things this weekend, so I'll test for the cases you mention and hit
you up for patches once I'm done.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well. 
		--Dennis Ritchie

Thu, 19 Feb 2004 12:21:20 -0500
Andrew Sullivan <ajs@crankycanuck.ca>
Re: Replication eRServer problems