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 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