On Fri, Mar 20, 2015 at 04:43:42PM -0400, Bruce Momjian wrote:
On Sat, Nov 8, 2014 at 09:53:18PM +0100, Álvaro Hernández Tortosa wrote:
On 07/11/14 22:02, Greg Sabino Mullane wrote:
Kevin Grittner wrote:
I think most people have always assumed that
BEGIN starts the transaction and
On 24/03/15 20:56, Bruce Momjian wrote:
On Fri, Mar 20, 2015 at 04:43:42PM -0400, Bruce Momjian wrote:
On Sat, Nov 8, 2014 at 09:53:18PM +0100, Álvaro Hernández Tortosa wrote:
On 07/11/14 22:02, Greg Sabino Mullane wrote:
Kevin Grittner wrote:
I think most people have always assumed that
On Sat, Nov 8, 2014 at 09:53:18PM +0100, Álvaro Hernández Tortosa wrote:
On 07/11/14 22:02, Greg Sabino Mullane wrote:
Kevin Grittner wrote:
I think most people have always assumed that
BEGIN starts the transaction and that is the point at
which the snapshot is obtained.
But there is so
On 06/11/14 15:00, Kevin Grittner wrote:
Álvaro Hernández Tortosa a...@8kdata.com wrote:
There has been two comments which seem to state that changing this
may introduce some performance problems and some limitations when you
need to take out some locks. I still believe, however, that
On 07/11/14 22:02, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Kevin Grittner wrote:
I think most people have always assumed that
BEGIN starts the transaction and that is the point at
which the snapshot is obtained.
But there is so much evidence to the
On Wed, Nov 5, 2014 at 7:17 PM, Álvaro Hernández Tortosa a...@8kdata.com
wrote:
Given a transaction started with BEGIN (REPEATABLE READ |
SERIALIZABLE), if a concurrent session commits some data before *any*
query
within the first transaction, that committed data is seen by the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Kevin Grittner wrote:
I think most people have always assumed that
BEGIN starts the transaction and that is the point at
which the snapshot is obtained.
But there is so much evidence to the contrary. Not only does the
*name* of the
On 06/11/14 02:06, Jim Nasby wrote:
On 11/5/14, 6:04 PM, Álvaro Hernández Tortosa wrote:
On 05/11/14 17:46, Jim Nasby wrote:
On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote:
Should we improve then the docs stating this more clearly? Any
objection to do this?
If we go that route
Álvaro Hernández Tortosa a...@8kdata.com wrote:
There has been two comments which seem to state that changing this
may introduce some performance problems and some limitations when you
need to take out some locks. I still believe, however, that current
behavior is confusing for the user.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Kevin Grittner wrote:
(wording change suggestion)
| sees a snapshot as of the start of the first query within the
| transaction, not as of the start of the current query within the
| transaction.
Would that have prevented the confusion
Greg Sabino Mullane g...@turnstep.com wrote:
Kevin Grittner wrote:
(wording change suggestion)
| sees a snapshot as of the start of the first query within the
| transaction, not as of the start of the current query within the
| transaction.
Would that have prevented the confusion here?
I
Kevin Grittner kgri...@ymail.com writes:
Why? This fix might not deal with the bigger issues that I
discussed, like that the later-to-start and
later-to-acquire-a-snapshot transaction might logically be first in
the apparent order of execution. You can't fix that without a
lot of blocking
On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote:
Should we improve then the docs stating this more clearly? Any objection
to do this?
If we go that route we should also mention that now() will no longer be doing
what you probably hope it would (AFAIK it's driven by BEGIN and not the
Jim Nasby jim.na...@bluetreble.com wrote:
If we go that route we should also mention that now() will no
longer be doing what you probably hope it would (AFAIK it's
driven by BEGIN and not the first snapshot).
There is also the fact that pg_stat_activity shows a connection as
being idle in
On Mon, Nov 3, 2014 at 2:14 PM, Álvaro Hernández Tortosa a...@8kdata.com
wrote:
Given a transaction started with BEGIN (REPEATABLE READ |
SERIALIZABLE), if a concurrent session commits some data before *any* query
within the first transaction, that committed data is seen by the
On 05/11/14 17:46, Jim Nasby wrote:
On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote:
Should we improve then the docs stating this more clearly? Any
objection to do this?
If we go that route we should also mention that now() will no longer
be doing what you probably hope it would
On 06/11/14 00:42, Robert Haas wrote:
On Mon, Nov 3, 2014 at 2:14 PM, Álvaro Hernández Tortosa a...@8kdata.com
wrote:
Given a transaction started with BEGIN (REPEATABLE READ |
SERIALIZABLE), if a concurrent session commits some data before *any* query
within the first transaction,
On 11/5/14, 6:04 PM, Álvaro Hernández Tortosa wrote:
On 05/11/14 17:46, Jim Nasby wrote:
On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote:
Should we improve then the docs stating this more clearly? Any objection
to do this?
If we go that route we should also mention that now() will
Jim Nasby jim.na...@bluetreble.com writes:
Hmm... we do have transaction_timestamp(); perhaps we could leave that as the
time BEGIN executed and shift everything else to use the snapshot time.
It's not possible to take a timestamp that *exactly* matches the snapshot
time. We could rearrange
On 11/04/2014 07:31 AM, Álvaro Hernández Tortosa wrote:
Thank you for your comment, Tom. However I think this behavior, as
seen from a user perspective, it's not the expected one.
That may be the case, but I think it's the SQL-standard behaviour, so we
can't really mess with it.
The spec
On 04/11/14 09:07, Craig Ringer wrote:
On 11/04/2014 07:31 AM, Álvaro Hernández Tortosa wrote:
Thank you for your comment, Tom. However I think this behavior, as
seen from a user perspective, it's not the expected one.
That may be the case, but I think it's the SQL-standard behaviour, so
Hi!
Given a transaction started with BEGIN (REPEATABLE READ |
SERIALIZABLE), if a concurrent session commits some data before *any*
query within the first transaction, that committed data is seen by the
transaction. This is not what I'd expect. Specifically, the
documentation
=?ISO-8859-1?Q?=C1lvaro_Hern=E1ndez_Tortosa?= a...@8kdata.com writes:
IMHO, from a user perspective the transaction begins when the BEGIN
command is issued. If I really want to see a frozen view of the
database before any real SELECT, I have to issue another query like
SELECT 1. This
On 03/11/14 22:19, Tom Lane wrote:
=?ISO-8859-1?Q?=C1lvaro_Hern=E1ndez_Tortosa?= a...@8kdata.com writes:
IMHO, from a user perspective the transaction begins when the BEGIN
command is issued. If I really want to see a frozen view of the
database before any real SELECT, I have to issue
24 matches
Mail list logo
