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
BE
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 tr
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.
> >
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 contr
On 06/11/14 15:00, Kevin Grittner wrote:
Álvaro Hernández Tortosa 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 i
-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 t
On Wed, Nov 5, 2014 at 7:17 PM, Álvaro Hernández Tortosa
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
>>> tra
Kevin Grittner 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 -- that mo
Greg Sabino Mullane 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
-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 confus
Álvaro Hernández Tortosa 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. Sure, one op
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 we
Jim Nasby 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 the code so that we ask
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
On 06/11/14 00:42, Robert Haas wrote:
On Mon, Nov 3, 2014 at 2:14 PM, Álvaro Hernández Tortosa
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 d
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 (AF
On Mon, Nov 3, 2014 at 2:14 PM, Álvaro Hernández Tortosa
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
> transaction. Thi
Jim Nasby 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 transaction" as soon as
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
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
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 03/11/14 22:19, Tom Lane wrote:
=?ISO-8859-1?Q?=C1lvaro_Hern=E1ndez_Tortosa?= 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 li
=?ISO-8859-1?Q?=C1lvaro_Hern=E1ndez_Tortosa?= 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 seems odd
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 st
24 matches
Mail list logo