Re: [HACKERS] synchronized snapshots

2011-10-23 Thread Thom Brown
On 23 October 2011 03:15, Tom Lane t...@sss.pgh.pa.us wrote: Thom Brown t...@linux.com writes: Can I ask why it doesn't return the same snapshot ID each time? Surely it can't change since you can only export the snapshot of a serializable or repeatable read transaction? No, that's incorrect.

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-22 Thread Simon Riggs
On Fri, Oct 21, 2011 at 4:36 PM, Tom Lane t...@sss.pgh.pa.us wrote: I can see a few alternatives, none of them very pleasant: 1. Restrict exported snapshots to be loaded only by transactions running in the same database as the exporter.  This would fix the problem, but it cuts out one of the

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-22 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: 1 *and* 4 please. Given the lack of enthusiasm I'm not going to do anything about #4 now. Somebody else can add it later. So, unless explicitly requested, an exported snapshot is limited to just one database. If explicitly requested to be

Re: [HACKERS] synchronized snapshots

2011-10-22 Thread Tom Lane
Joachim Wieland j...@mcknight.de writes: [ synchronized snapshots patch ] Applied with, um, rather extensive editorialization. I'm not convinced that the SSI case is bulletproof yet, but it'll be easier to test with the code committed. regards, tom lane -- Sent via

Re: [HACKERS] synchronized snapshots

2011-10-22 Thread Thom Brown
On 23 October 2011 00:25, Tom Lane t...@sss.pgh.pa.us wrote: Joachim Wieland j...@mcknight.de writes: [ synchronized snapshots patch ] Applied with, um, rather extensive editorialization. I'm not convinced that the SSI case is bulletproof yet, but it'll be easier to test with the code

Re: [HACKERS] synchronized snapshots

2011-10-22 Thread Tom Lane
Thom Brown t...@linux.com writes: Can I ask why it doesn't return the same snapshot ID each time? Surely it can't change since you can only export the snapshot of a serializable or repeatable read transaction? No, that's incorrect. You can export from a READ COMMITTED transaction; indeed,

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Florian Pflug
On Oct21, 2011, at 17:36 , Tom Lane wrote: 1. Restrict exported snapshots to be loaded only by transactions running in the same database as the exporter. This would fix the problem, but it cuts out one of the main use-cases for sync snapshots, namely getting cluster-wide-consistent dumps in

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Andrew Dunstan
On 10/21/2011 12:05 PM, Florian Pflug wrote: On Oct21, 2011, at 17:36 , Tom Lane wrote: 1. Restrict exported snapshots to be loaded only by transactions running in the same database as the exporter. This would fix the problem, but it cuts out one of the main use-cases for sync snapshots,

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: On 10/21/2011 12:05 PM, Florian Pflug wrote: On Oct21, 2011, at 17:36 , Tom Lane wrote: 1. Restrict exported snapshots to be loaded only by transactions running in the same database as the exporter. This would fix the problem, but it cuts out one of

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Tom Lane
Florian Pflug f...@phlo.org writes: On Oct21, 2011, at 17:36 , Tom Lane wrote: 3. Remove the optimization that lets GetOldestXmin ignore XIDs outside the current database. This sounds bad, but OTOH I don't think there's ever been any proof that this optimization is worth much in real-world

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Robert Haas
On Fri, Oct 21, 2011 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote: I've thought of another nasty problem for the sync-snapshots patch. 1. Restrict exported snapshots to be loaded only by transactions running in the same database as the exporter.  This would fix the problem, but it cuts out

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Florian Pflug
On Oct21, 2011, at 19:09 , Tom Lane wrote: Florian Pflug f...@phlo.org writes: On Oct21, 2011, at 17:36 , Tom Lane wrote: 3. Remove the optimization that lets GetOldestXmin ignore XIDs outside the current database. This sounds bad, but OTOH I don't think there's ever been any proof that this

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Robert Haas
On Fri, Oct 21, 2011 at 1:40 PM, Florian Pflug f...@phlo.org wrote: AFAIR, the performance hit we'd take by making the vacuum cutoff point (i.e. GetOldestXmin()) global instead of database-local has been repeatedly used in the past as an against against cross-database queries. I have to admit

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Andrew Dunstan
On 10/21/2011 01:06 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: On 10/21/2011 12:05 PM, Florian Pflug wrote: On Oct21, 2011, at 17:36 , Tom Lane wrote: 1. Restrict exported snapshots to be loaded only by transactions running in the same database as the exporter. This

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Florian Pflug
On Oct21, 2011, at 19:47 , Robert Haas wrote: On Fri, Oct 21, 2011 at 1:40 PM, Florian Pflug f...@phlo.org wrote: AFAIR, the performance hit we'd take by making the vacuum cutoff point (i.e. GetOldestXmin()) global instead of database-local has been repeatedly used in the past as an against

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Tom Lane
Florian Pflug f...@phlo.org writes: AFAIR, the performance hit we'd take by making the vacuum cutoff point (i.e. GetOldestXmin()) global instead of database-local has been repeatedly used in the past as an against against cross-database queries. I have to admit that I currently cannot seem to

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Robert Haas
On Fri, Oct 21, 2011 at 2:06 PM, Florian Pflug f...@phlo.org wrote: On Oct21, 2011, at 19:47 , Robert Haas wrote: On Fri, Oct 21, 2011 at 1:40 PM, Florian Pflug f...@phlo.org wrote: AFAIR, the performance hit we'd take by making the vacuum cutoff point (i.e. GetOldestXmin()) global instead of

Re: [HACKERS] Synchronized snapshots versus multiple databases

2011-10-21 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Fri, Oct 21, 2011 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote: 1. Restrict exported snapshots to be loaded only by transactions running in the same database as the exporter.  This would fix the problem, but it cuts out one of the main use-cases

Re: [HACKERS] synchronized snapshots

2011-10-19 Thread Tom Lane
Joachim Wieland j...@mcknight.de writes: [ synchronized-snapshots patch ] Looking through this code, it strikes me that SET TRANSACTION SNAPSHOT is fundamentally incompatible with SERIALIZABLE READ ONLY DEFERRABLE mode. That mode assumes that you should be able to just take a new snapshot,

Re: [HACKERS] synchronized snapshots

2011-10-19 Thread Heikki Linnakangas
On 19.10.2011 19:17, Tom Lane wrote: Joachim Wielandj...@mcknight.de writes: [ synchronized-snapshots patch ] Looking through this code, it strikes me that SET TRANSACTION SNAPSHOT is fundamentally incompatible with SERIALIZABLE READ ONLY DEFERRABLE mode. That mode assumes that you should

Re: [HACKERS] synchronized snapshots

2011-10-19 Thread Florian Pflug
On Oct19, 2011, at 18:17 , Tom Lane wrote: Joachim Wieland j...@mcknight.de writes: [ synchronized-snapshots patch ] Looking through this code, it strikes me that SET TRANSACTION SNAPSHOT is fundamentally incompatible with SERIALIZABLE READ ONLY DEFERRABLE mode. That mode assumes that you

Re: [HACKERS] synchronized snapshots

2011-10-19 Thread Tom Lane
Florian Pflug f...@phlo.org writes: On Oct19, 2011, at 18:17 , Tom Lane wrote: AFAICS we should just throw an error if SET TRANSACTION SNAPSHOT is done in a transaction with those properties. Has anyone got another interpretation? Would it be better to silently ignore the DEFERRABLE

Re: [HACKERS] synchronized snapshots

2011-10-19 Thread Robert Haas
On Wed, Oct 19, 2011 at 1:02 PM, Tom Lane t...@sss.pgh.pa.us wrote: Florian Pflug f...@phlo.org writes: On Oct19, 2011, at 18:17 , Tom Lane wrote: AFAICS we should just throw an error if SET TRANSACTION SNAPSHOT is done in a transaction with those properties.  Has anyone got another

Re: [HACKERS] synchronized snapshots

2011-10-19 Thread Kevin Grittner
Robert Haas robertmh...@gmail.com wrote: Tom Lane t...@sss.pgh.pa.us wrote: Florian Pflug f...@phlo.org writes: This allows a deferrable snapshot to be used on a second connection (by e.g. pg_dump), and still be marked as DEFERRABLE. If we throw an error unconditionally, the second

Re: [HACKERS] synchronized snapshots

2011-10-19 Thread Florian Pflug
On Oct19, 2011, at 19:49 , Kevin Grittner wrote: Robert Haas robertmh...@gmail.com wrote: Tom Lane t...@sss.pgh.pa.us wrote: Florian Pflug f...@phlo.org writes: This allows a deferrable snapshot to be used on a second connection (by e.g. pg_dump), and still be marked as DEFERRABLE. If we

Re: [HACKERS] synchronized snapshots

2011-10-19 Thread Kevin Grittner
Florian Pflug f...@phlo.org wrote: Oh, cool. I thought the opt-out only works for explicitly DEFERRABLE transactions. Basically, if there is no serializable read-write transaction active which overlaps the read-only transaction and also overlaps a serializable transaction which wrote

Re: [HACKERS] synchronized snapshots

2011-10-18 Thread Simon Riggs
On Mon, Oct 3, 2011 at 7:09 AM, Marko Tiikkaja marko.tiikk...@2ndquadrant.com wrote: On 2011-09-28 15:25, Joachim Wieland wrote: Yes, that's the desired behaviour, the patch add this paragraph to the documentation already: I can't believe I missed that.  My apologies. On 2011-09-29 05:16,

Re: [HACKERS] synchronized snapshots

2011-10-18 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: On Mon, Oct 3, 2011 at 7:09 AM, Marko Tiikkaja Thanks, this one looks good to me.  Going to mark this patch as ready for committer. I don't see any tests with this patch, so I personally won't be the committer on this just yet. I've already taken it

Re: [HACKERS] synchronized snapshots

2011-10-18 Thread Simon Riggs
On Tue, Oct 18, 2011 at 6:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: I'm also concerned that we are adding this to the BEGIN statement as the only option. Huh?  The last version of the patch has it only as SET TRANSACTION SNAPSHOT, which I think is the right way. Sorry Tom, didn't see your

Re: [HACKERS] synchronized snapshots

2011-10-03 Thread Marko Tiikkaja
On 2011-09-28 15:25, Joachim Wieland wrote: Yes, that's the desired behaviour, the patch add this paragraph to the documentation already: I can't believe I missed that. My apologies. On 2011-09-29 05:16, Joachim Wieland wrote: The attached patch addresses the reported issues. Thanks, this

Re: [HACKERS] synchronized snapshots

2011-09-28 Thread Marko Tiikkaja
Hi Joachim, On 14/09/2011 05:37, Joachim Wieland wrote: Here is a new version of this patch In a sequence such as this: BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; INSERT INTO foo VALUES (-1); SELECT pg_export_snapshot(); the row added to foo is not visible in the exported

Re: [HACKERS] synchronized snapshots

2011-09-28 Thread Joachim Wieland
Hi Marko, On Wed, Sep 28, 2011 at 2:29 AM, Marko Tiikkaja marko.tiikk...@2ndquadrant.com wrote: In a sequence such as this:  BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;  INSERT INTO foo VALUES (-1);  SELECT pg_export_snapshot(); the row added to foo is not visible in the exported

Re: [HACKERS] synchronized snapshots

2011-08-24 Thread Peter Eisentraut
On lör, 2011-08-20 at 09:56 -0400, Bruce Momjian wrote: Peter Eisentraut wrote: On tis, 2011-08-16 at 20:35 -0400, Tom Lane wrote: In fact, now that I think about it, setting the transaction snapshot from a utility statement would be functionally useful because then you could take

Re: [HACKERS] synchronized snapshots

2011-08-20 Thread Bruce Momjian
Peter Eisentraut wrote: On tis, 2011-08-16 at 20:35 -0400, Tom Lane wrote: In fact, now that I think about it, setting the transaction snapshot from a utility statement would be functionally useful because then you could take locks beforehand. Another issue is that in some client

Re: [HACKERS] synchronized snapshots

2011-08-17 Thread Peter Eisentraut
On tis, 2011-08-16 at 20:35 -0400, Tom Lane wrote: In fact, now that I think about it, setting the transaction snapshot from a utility statement would be functionally useful because then you could take locks beforehand. Another issue is that in some client interfaces, BEGIN and COMMIT are

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Robert Haas
On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland j...@mcknight.de wrote: On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby j...@nasby.net wrote: I suspect that all the other cases of BEGIN failing would be syntax errors, so you would immediately know in testing that something was wrong. A missing

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Alvaro Herrera
Excerpts from Robert Haas's message of mar ago 16 09:59:04 -0400 2011: On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland j...@mcknight.de wrote: Also see what Robert wrote about proxies in between that keep track of the transaction state. Consider they see a BEGIN query that fails. How

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Robert Haas
On Tue, Aug 16, 2011 at 10:43 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Robert Haas's message of mar ago 16 09:59:04 -0400 2011: On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland j...@mcknight.de wrote: Also see what Robert wrote about proxies in between that keep

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Jim Nasby
On Aug 15, 2011, at 5:46 PM, Joachim Wieland wrote: On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby j...@nasby.net wrote: I suspect that all the other cases of BEGIN failing would be syntax errors, so you would immediately know in testing that something was wrong. A missing file is definitely

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Jeff Davis
On Tue, 2011-08-16 at 11:01 -0500, Jim Nasby wrote: Also, an invalid transaction seems to be the result of least surprise... if you cared enough to begin a transaction, you're going to expect that either everything between that and the COMMIT succeeds or fails, not something in-between.

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Jim Nasby
On Aug 16, 2011, at 5:40 PM, Jeff Davis wrote: On Tue, 2011-08-16 at 11:01 -0500, Jim Nasby wrote: Also, an invalid transaction seems to be the result of least surprise... if you cared enough to begin a transaction, you're going to expect that either everything between that and the COMMIT

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Tom Lane
Jim Nasby j...@nasby.net writes: Well, it appears we have a larger problem, as Robert pointed out that trying to start a writable transaction on a hot standby leaves you not in a transaction (which I feel is a problem). So IMHO the right thing to do here is make it so that runtime errors in

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Robert Haas
On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jim Nasby j...@nasby.net writes: Well, it appears we have a larger problem, as Robert pointed out that trying to start a writable transaction on a hot standby leaves you not in a transaction (which I feel is a problem). So

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane t...@sss.pgh.pa.us wrote: I think we'd be far better off to maintain the position that a failed BEGIN does not start a transaction, under any circumstances. Also agreed. To do that, we cannot have this new

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Robert Haas
On Tue, Aug 16, 2011 at 8:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane t...@sss.pgh.pa.us wrote: I think we'd be far better off to maintain the position that a failed BEGIN does not start a transaction, under any

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Jeff Davis
On Tue, 2011-08-16 at 20:35 -0400, Tom Lane wrote: I'm not convinced by the above argument, because it requires that you pretend there's a significant difference between syntax errors and run time errors (whatever those are). After a syntax error like COMMMIT the transaction will remain inside

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Jeff Davis
On Tue, 2011-08-16 at 21:08 -0400, Robert Haas wrote: attaching it to BEGIN feels natural to me. My only objection is that people have different expectations about whether the session will remain in a transaction block when they encounter an error. So, it's hard to make this work without

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Robert Haas
On Tue, Aug 16, 2011 at 9:54 PM, Jeff Davis pg...@j-davis.com wrote: If we did add another toplevel command, what would we call it? SET TRANSACTION SNAPSHOT perhaps? Hmm, that's not bad, but I think we'd have to partially reserve TRANSACTION to make it work, which doesn't seem worth the pain

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Simon Riggs
On Mon, Aug 15, 2011 at 2:31 AM, Joachim Wieland j...@mcknight.de wrote: In short, this is how it works: SELECT pg_export_snapshot();  pg_export_snapshot  03A1-1 (1 row) (and then in a different session) BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Heikki Linnakangas
On 15.08.2011 04:31, Joachim Wieland wrote: The one thing that it does not implement is leaving the transaction in an aborted state if the BEGIN TRANSACTION command failed for an invalid snapshot identifier. So what if the snapshot is invalid, the SNAPSHOT clause silently ignored? That sounds

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Heikki Linnakangas
On 15.08.2011 10:40, Simon Riggs wrote: On Mon, Aug 15, 2011 at 2:31 AM, Joachim Wielandj...@mcknight.de wrote: In short, this is how it works: SELECT pg_export_snapshot(); pg_export_snapshot 03A1-1 (1 row) (and then in a different session) BEGIN TRANSACTION

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Andres Freund
On Monday, August 15, 2011 08:40:34 Simon Riggs wrote: On Mon, Aug 15, 2011 at 2:31 AM, Joachim Wieland j...@mcknight.de wrote: In short, this is how it works: SELECT pg_export_snapshot(); pg_export_snapshot 03A1-1 (1 row) (and then in a different

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread PostgreSQL - Hans-Jürgen Schönig
On Aug 15, 2011, at 9:40 AM, Simon Riggs wrote: On Mon, Aug 15, 2011 at 2:31 AM, Joachim Wieland j...@mcknight.de wrote: In short, this is how it works: SELECT pg_export_snapshot(); pg_export_snapshot 03A1-1 (1 row) (and then in a different session)

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Florian Weimer
* Simon Riggs: I don't see the need to change the BEGIN command, which is SQL Standard. We don't normally do that. Some language bindings treat BEGIN specially, so it might be difficult to use this feature. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Joachim Wieland
On Mon, Aug 15, 2011 at 3:47 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 15.08.2011 04:31, Joachim Wieland wrote: The one thing that it does not implement is leaving the transaction in an aborted state if the BEGIN TRANSACTION command failed for an invalid snapshot

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Joachim Wieland
On Mon, Aug 15, 2011 at 6:41 AM, Florian Weimer fwei...@bfk.de wrote: * Simon Riggs: I don't see the need to change the BEGIN command, which is SQL Standard. We don't normally do that. Some language bindings treat BEGIN specially, so it might be difficult to use this feature. It's true,

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Robert Haas
On Mon, Aug 15, 2011 at 3:51 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: It would be nice a symmetry, but you'd need a limitation that pg_import_snapshot() must be the first thing you do in the session. And it might be hard to enforce that, as once you get control into the

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Kevin Grittner
Simon Riggs si...@2ndquadrant.com wrote: Joachim Wieland j...@mcknight.de wrote: BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ (SNAPSHOT = '03A1-1'); I don't see the need to change the BEGIN command, which is SQL Standard. No, it's not standard. To quote from our docs at:

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Jim Nasby
On Aug 15, 2011, at 6:23 AM, Joachim Wieland wrote: On Mon, Aug 15, 2011 at 3:47 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 15.08.2011 04:31, Joachim Wieland wrote: The one thing that it does not implement is leaving the transaction in an aborted state if the BEGIN

Re: [HACKERS] synchronized snapshots

2011-08-15 Thread Joachim Wieland
On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby j...@nasby.net wrote: I suspect that all the other cases of BEGIN failing would be syntax errors, so you would immediately know in testing that something was wrong. A missing file is definitely not a syntax error, so we can't really depend on user

Re: [HACKERS] synchronized snapshots

2010-02-10 Thread Markus Wanner
Hi Joachim, On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland j...@mcknight.de wrote: http://www.postgresql.org/docs/8.4/static/backup-dump.html already states about pg_dump: In particular, it must have read access to all tables that you want to back up, so in practice you almost always have

Re: [HACKERS] synchronized snapshots

2010-02-10 Thread Heikki Linnakangas
Markus Wanner wrote: On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland j...@mcknight.de wrote: http://www.postgresql.org/docs/8.4/static/backup-dump.html already states about pg_dump: In particular, it must have read access to all tables that you want to back up, so in practice you almost

Re: [HACKERS] synchronized snapshots

2010-02-05 Thread Markus Wanner
Hello Joachim, a little daughter eats lots of spare cycles - among other things. Sorry it took that long to review. On Fri, 8 Jan 2010 20:36:44 +0100, Joachim Wieland j...@mcknight.de wrote: The attached patch implements the idea of Heikki / Simon published in

Re: [HACKERS] synchronized snapshots

2010-01-10 Thread Simon Riggs
On Fri, 2010-01-08 at 20:36 +0100, Joachim Wieland wrote: The attached patch implements the idea of Heikki / Simon published in http://archives.postgresql.org/pgsql-hackers/2009-11/msg00271.php Since nobody objected to the idea in general, I have implemented it. As this is not currently

Re: [HACKERS] synchronized snapshots

2010-01-09 Thread Markus Wanner
Hi Joachim Wieland wrote: Since nobody objected to the idea in general, I have implemented it. Great! I hope to get some spare cycles within the next few days to review it. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] synchronized snapshots

2010-01-09 Thread Marcin Mańk
Dnia 2010-01-09 o godz. 20:37 Markus Wanner mar...@bluegap.ch napisał (a): Hi Joachim Wieland wrote: Since nobody objected to the idea in general, I have implemented it. How cool it would be if we could synchronize snapshots between the master and the (sr) standby? The connection

Re: [HACKERS] synchronized snapshots

2010-01-08 Thread Greg Stark
On Fri, Jan 8, 2010 at 7:36 PM, Joachim Wieland j...@mcknight.de wrote:  * If all four pg_synchronize_snapshot_taken() calls return true and the If we must have a timeout I think you should throw an error if the timeout expires. -- greg -- Sent via pgsql-hackers mailing list