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
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
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
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,
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo