On 23 October 2011 03:15, Tom Lane wrote:
> Thom Brown 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
Thom Brown 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, you'd more or l
On 23 October 2011 00:25, Tom Lane wrote:
> Joachim Wieland 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.
Can I ask why it doe
Joachim Wieland 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 pgsql-hackers mail
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
Florian Pflug 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 something and commi
On Oct19, 2011, at 19:49 , Kevin Grittner wrote:
> Robert Haas wrote:
>> Tom Lane wrote:
>>> Florian Pflug 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
Robert Haas wrote:
> Tom Lane wrote:
>> Florian Pflug 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 connection has
>>> to import the snapshot without
On Wed, Oct 19, 2011 at 1:02 PM, Tom Lane wrote:
> Florian Pflug 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
Florian Pflug 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
>> property?
>
On Oct19, 2011, at 18:17 , Tom Lane wrote:
> Joachim Wieland 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
On 19.10.2011 19:17, Tom Lane wrote:
Joachim Wieland 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 ta
Joachim Wieland 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, repeatedly, until yo
On Tue, Oct 18, 2011 at 6:22 PM, Tom Lane 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 name on it ea
Simon Riggs 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 according to t
On Mon, Oct 3, 2011 at 7:09 AM, Marko Tiikkaja
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, Joachim Wieland wrot
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
Hi Marko,
On Wed, Sep 28, 2011 at 2:29 AM, Marko Tiikkaja
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 snapshot. If that's
> the
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 snapsh
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
> > > coul
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
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
hi
On Tue, Aug 16, 2011 at 9:54 PM, Jeff Davis 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 it
would caus
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 surpri
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
On Tue, Aug 16, 2011 at 8:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane 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
>>>
Robert Haas writes:
> On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane 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 option attached to the BEGIN,
On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane wrote:
> Jim Nasby 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 t
Jim Nasby 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 BEGIN
> l
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 COMMI
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.
Ag
On Aug 15, 2011, at 5:46 PM, Joachim Wieland wrote:
> On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby 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
On Tue, Aug 16, 2011 at 10:43 AM, Alvaro Herrera
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 wrote:
>
>> > Also see what Robert wrote about proxies in between that keep track
>> > of the transaction state. Con
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 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 would they kno
On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland wrote:
> On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby 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
On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby 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 testing
> to en
On Aug 15, 2011, at 6:23 AM, Joachim Wieland wrote:
> On Mon, Aug 15, 2011 at 3:47 AM, Heikki Linnakangas
> 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 fa
Simon Riggs wrote:
> Joachim Wieland 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:
http://www.postgresql.org/docs/9
On Mon, Aug 15, 2011 at 3:51 AM, Heikki Linnakangas
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 function,
> you've already acqui
On Mon, Aug 15, 2011 at 6:41 AM, Florian Weimer 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, the comm
On Mon, Aug 15, 2011 at 3:47 AM, Heikki Linnakangas
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 identifier.
>
> So what if th
* 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 Weimer
BFK edv-consulting GmbH http://www.bfk.de/
K
On Aug 15, 2011, at 9:40 AM, Simon Riggs wrote:
> On Mon, Aug 15, 2011 at 2:31 AM, Joachim Wieland 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
On Monday, August 15, 2011 08:40:34 Simon Riggs wrote:
> On Mon, Aug 15, 2011 at 2:31 AM, Joachim Wieland wrote:
> > In short, this is how it works:
> >
> > SELECT pg_export_snapshot();
> > pg_export_snapshot
> >
> > 03A1-1
> > (1 row)
> >
> >
> > (and then in a diffe
On 15.08.2011 10:40, Simon Riggs wrote:
On Mon, Aug 15, 2011 at 2:31 AM, Joachim Wieland 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 RE
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
On Mon, Aug 15, 2011 at 2:31 AM, Joachim Wieland 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 (SNAPSHOT =
Markus Wanner wrote:
> On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland
> 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 ha
Hi Joachim,
On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland
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
to run it as a d
Hi Markus,
On Fri, Feb 5, 2010 at 6:29 PM, Markus Wanner wrote:
>
> So, let's first concentrate on the intended use case: allowing parallel
> pg_dump. To me it seems like a pragmatic and quick solution, however, I'm
> not sure if requiring superuser privileges is acceptable.
http://www.postgresq
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
wrote:
The attached patch implements the idea of Heikki / Simon published in
http://archives.postgresql.org/pgsql-hackers/20
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 curr
Dnia 2010-01-09 o godz. 20:37 Markus Wanner 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 poolers could use th
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 s
On Fri, Jan 8, 2010 at 7:36 PM, Joachim Wieland 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 (pgsql-hackers@postgresql.org)
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 used anywhere it doesn't give immediate benefit, it
is however a p
70 matches
Mail list logo
