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.
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
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
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
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,
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
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,
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
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
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
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
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
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
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
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,
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
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
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 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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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 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
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
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)
* 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
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
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,
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
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:
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
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
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
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
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
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
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
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
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
67 matches
Mail list logo