Re: snapshot replication with pg_dump - Mailing list pgsql-hackers

From Paul Silveira
Subject Re: snapshot replication with pg_dump
Date
Msg-id 5908347.post@talk.nabble.com
Whole thread Raw
In response to Re: snapshot replication with pg_dump  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Can you do that if you have functions tied to the table?  Also would that be
in a transaction?  I need to allow seamless usability to the data while I'm
doing this snapshot.  Not sure the -c option (Clean Drop schema) would work
here.  I want to only drop a table and not the entire db so that I'm not
moving data that doesn't need to be moved.

The goal is to only shapshot data in tables that has changed.  I would like
to wrap that in a transaction.  

-Paul






Martijn van Oosterhout wrote:
> 
> On Mon, Aug 21, 2006 at 06:40:22AM -0700, Paul Silveira wrote:
>> 
>> Yes the needs are simple.  I was also thinking about using DBI.  The most
>> important thing to me is that everything is kept in a transaction so that
>> users can still read the data while I'm snapshotting it at the same time. 
>> If my transaction is isolated from all the reads happening, then it
>> shouldn't matter how long it takes for me to move the data over (granted,
>> that will increase latency, but in this project that's not really too
>> sensitive) and it will be transparent to the end users.  
> 
> Looks to me like the -c option to pg_dump should do what you want.
> 
> <snip>
> 
> Have a nice day,
> -- 
> Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
>> From each according to his ability. To each according to his ability to
>> litigate.
> 
> 

-- 
View this message in context: http://www.nabble.com/snapshot-replication-with-pg_dump-tf2090351.html#a5908347
Sent from the PostgreSQL - hackers forum at Nabble.com.



pgsql-hackers by date:

Previous
From: mark@mark.mielke.cc
Date:
Subject: Re: PostgreSQL on 64 bit Linux
Next
From: Martijn van Oosterhout
Date:
Subject: Re: PostgreSQL on 64 bit Linux