Simon Riggs 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 transportable, we can
> use the
On Fri, Oct 21, 2011 at 4:36 PM, Tom Lane 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 main use-case
Robert Haas writes:
> On Fri, Oct 21, 2011 at 11:36 AM, 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
On Fri, Oct 21, 2011 at 2:06 PM, Florian Pflug wrote:
> On Oct21, 2011, at 19:47 , Robert Haas wrote:
>> On Fri, Oct 21, 2011 at 1:40 PM, Florian Pflug wrote:
>>> AFAIR, the performance hit we'd take by making the vacuum cutoff point
>>> (i.e. GetOldestXmin()) global instead of database-local has
Florian Pflug 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 find an en
On Oct21, 2011, at 19:47 , Robert Haas wrote:
> On Fri, Oct 21, 2011 at 1:40 PM, Florian Pflug 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 c
On 10/21/2011 01:06 PM, Tom Lane wrote:
Andrew Dunstan 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,
On Fri, Oct 21, 2011 at 1:40 PM, Florian Pflug 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 that I cur
On Oct21, 2011, at 19:09 , Tom Lane wrote:
> Florian Pflug 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 o
On Fri, Oct 21, 2011 at 11:36 AM, Tom Lane 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 one of the mai
Florian Pflug 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
>> usage.
Andrew Dunstan 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 the mai
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, name
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 i
I've thought of another nasty problem for the sync-snapshots patch.
Consider the following sequence of events:
1. Transaction A, which is about to export a snapshot, is running in
database X.
2. Transaction B is making some changes in database Y.
3. A takes and exports a snapshot showing B's xi
15 matches
Mail list logo
