DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=AuupdtqTMfBH29IIInxpJ3guepa8i6IMBBOjKNv+ROWllsEYVdlo1F3daXvsrchm3kRomGpF9v8/zMEZHancyee0FU6DSvje0bNejokbalSqp5CQFe+OUnwPoeFBow4/rVGvRYQUlxwsHIgstR9zXDUzGhvs7WaiEPGfgTrIWzM=
Message-ID: <b42b73150707271127q7c42d09cuafb263eefe193b84@mail.gmail.com>
Date: Fri, 27 Jul 2007 14:27:00 -0400
From: "Merlin Moncure" <mmoncure@gmail.com>
To: "Michael Dengler" <michael.dengler@gmail.com>
Subject: Re: How to use a trigger to write rows to a remote server
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, pgsql-performance@postgresql.org
In-Reply-To: <e8733d090707180930t12f701edn728cdc486f035cd5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e8733d090707180636q45bb5d16vff3e79c2d60d2e83@mail.gmail.com>
	<18352.1184770316@sss.pgh.pa.us>
	<e8733d090707180930t12f701edn728cdc486f035cd5@mail.gmail.com>

On 7/18/07, Michael Dengler <michael.dengler@gmail.com> wrote:
> Hmm..I was hoping to avoid personal insults....
>
> Anyway, Nuts or not...what I am attempting is to simply have row from one
> table inserted into another servers DB I don't see it as replication
> because:

I think you took Tom's comments the wrong way.  He is suggesting you
are nuts to attempt trigger based data transfer to remote server when
there are two clearly better options, slony and dblink.  You took as a
personal insult which was just some frank (and frankly good) advice...

Slony is in fact the _solution_ to the problem of transferring data
between servers with triggers.  If your tables are well designed and
you are reasonably proficient with stored procedures, and you
requirements of transfer are very specific and not extremely time
sensitive, a poll based system over dblink is also a good solution.

> a) The destination table will have a trigger that modifies the arriving data
> to fit its table scheme.
> b) It is not critical that the data be synchronous (ie a lost row on the
> destination DB is not a big deal)
> c) I see as more of a provision of data to the destination DB NOT A
> REPLICATION OF DATA.

based on this you may want to rig dblink/poll.  3rd option is pitr
shipping to warm standby, depending on your requirements.

> Essentially the remote server just wants to know when some record arrives at
> the source server and wants to know some of the info contained in the new
> record.
>
> And yes it may be that I know little about the myriad of problems involved
> with replication...but I do know how to carry on a civil, adult
> conversation....maybe we can have a knowledge exchange.

now that's a bit dramatic :-)

merlin