Heikki Linnakangas wrote:
> I'll commit this too..
Thanks much for staying up past midnight to get these into beta3!
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08.07.2011 00:33, Heikki Linnakangas wrote:
On 08.07.2011 00:21, Dan Ports wrote:
We should also apply the attached patch, which corrects a minor issue
with the conditions for flagging transactions that could potentially
make a snapshot unsafe.
There's a small window wherein a transaction is
On 08.07.2011 00:21, Dan Ports wrote:
We should also apply the attached patch, which corrects a minor issue
with the conditions for flagging transactions that could potentially
make a snapshot unsafe.
There's a small window wherein a transaction is committed but not yet
on the finished list, and
Dan Ports wrote:
> We should also apply the attached patch, which corrects a minor
> issue with the conditions for flagging transactions that could
> potentially make a snapshot unsafe.
>
> There's a small window wherein a transaction is committed but not
> yet on the finished list, and we should
We should also apply the attached patch, which corrects a minor issue
with the conditions for flagging transactions that could potentially
make a snapshot unsafe.
There's a small window wherein a transaction is committed but not yet
on the finished list, and we shouldn't flag it as a potential con
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Kevin and Dan also pointed out that a 2PC transaction can stay
>> in prepared state for a long time, and we could optimize that by
>> setting prepareSeqNo only at the final COMMIT PREPARED. I
>> objected to that, for the reason that it's currently v
On Thu, Jul 07, 2011 at 04:48:55PM -0400, Tom Lane wrote:
> Seems to me there's a more fundamental reason not to do that, which is
> that once you've done PREPARE it is no longer legitimate to decide to
> roll back the transaction to get out of a "dangerous" structure --- ie,
> you have to target o
Heikki Linnakangas writes:
> Kevin and Dan also pointed out that a 2PC transaction can stay in
> prepared state for a long time, and we could optimize that by setting
> prepareSeqNo only at the final COMMIT PREPARED. I objected to that, for
> the reason that it's currently very convenient for t
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Just so everybody's clear --- this isn't making beta3, if it's not
>> going to get committed today.
> Yeah, Heikki let me know that off-list. I thought the last mention
> on the -hackers list of a cutoff date for that was the 11th. Did I
> misunde
On 07.07.2011 21:50, Heikki Linnakangas wrote:
On 07.07.2011 19:41, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 05.07.2011 20:03, Kevin Grittner wrote:
In reviewing the 2PC changes mentioned in a separate post, both
Dan and I realized that these were dependent on the assumption
that SSI
Tom Lane wrote:
> Just so everybody's clear --- this isn't making beta3, if it's not
> going to get committed today.
Yeah, Heikki let me know that off-list. I thought the last mention
on the -hackers list of a cutoff date for that was the 11th. Did I
misunderstand or was there some later cha
"Kevin Grittner" writes:
> Heikki Linnakangas wrote:
>> That yields a much smaller patch (attached). How does this look to
>> you, am I missing anything?
> Very clever. I'll need to study this and think about it. I'll try
> to post a response before I go to bed tonight. Hopefully Dan can
> w
Heikki Linnakangas wrote:
> Let's have two sequence numbers for each transaction: prepareSeqNo
> and commitSeqNo. prepareSeqNo is assigned when a transaction is
> prepared (in PreCommit_CheckForSerializableConflicts), and
> commitSeqNo is assigned when it's committed (in
> ReleasePredicateLocks)
On 07.07.2011 19:41, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 05.07.2011 20:03, Kevin Grittner wrote:
In reviewing the 2PC changes mentioned in a separate post, both
Dan and I realized that these were dependent on the assumption
that SSI's commitSeqNo is assigned in the order in whic
Heikki Linnakangas wrote:
> On 05.07.2011 20:03, Kevin Grittner wrote:
>> In reviewing the 2PC changes mentioned in a separate post, both
>> Dan and I realized that these were dependent on the assumption
>> that SSI's commitSeqNo is assigned in the order in which the
>> transactions became visible
On 05.07.2011 20:03, Kevin Grittner wrote:
In reviewing the 2PC changes mentioned in a separate post, both Dan
and I realized that these were dependent on the assumption that
SSI's commitSeqNo is assigned in the order in which the transactions
became visible.
This comment in the patch actually
On Tue, Jul 05, 2011 at 01:15:13PM -0500, Kevin Grittner wrote:
> Heikki Linnakangas wrote:
>
> > Hmm, I think it would be simpler to decide that instead of
> > SerializableXactHashLock, you must hold ProcArrayLock to access
> > LastSxactCommitSeqNo, and move the assignment of commitSeqNo to
Tom Lane wrote:
> Isn't SSI *already* forcing a new acquisition of an LWLock during
> commits of read-only transactions that aren't using SSI?
During COMMIT PREPARED there is one. We could avoid that by storing
the transaction isolation level in the persistent data for a
prepared statement, b
Robert Haas wrote:
> On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
> wrote:
>>> It'd be better to push some functionality into the procarray
>>> code.
>>
>> That's easily done if we don't mind taking out a ProcArrayLock
>> during completion of a transaction which has no XID, if only long
>> enou
Robert Haas writes:
> On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
> wrote:
>> That's easily done if we don't mind taking out a ProcArrayLock
>> during completion of a transaction which has no XID, if only long
>> enough to increment a uint64 in shared memory, and then stash the
>> value -- som
On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
wrote:
>> It'd be better to push some functionality into the procarray code.
>
> That's easily done if we don't mind taking out a ProcArrayLock
> during completion of a transaction which has no XID, if only long
> enough to increment a uint64 in share
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Hmm, I think it would be simpler to decide that instead of
>> SerializableXactHashLock, you must hold ProcArrayLock to access
>> LastSxactCommitSeqNo, and move the assignment of commitSeqNo to
>> ProcArrayTransaction(). It's probably easiest to m
Heikki Linnakangas writes:
> Hmm, I think it would be simpler to decide that instead of
> SerializableXactHashLock, you must hold ProcArrayLock to access
> LastSxactCommitSeqNo, and move the assignment of commitSeqNo to
> ProcArrayTransaction(). It's probably easiest to move
> LastSxactCommitS
Heikki Linnakangas wrote:
> Hmm, I think it would be simpler to decide that instead of
> SerializableXactHashLock, you must hold ProcArrayLock to access
> LastSxactCommitSeqNo, and move the assignment of commitSeqNo to
> ProcArrayTransaction(). It's probably easiest to move
> LastSxactCommit
On 05.07.2011 20:03, Kevin Grittner wrote:
In reviewing the 2PC changes mentioned in a separate post, both Dan
and I realized that these were dependent on the assumption that
SSI's commitSeqNo is assigned in the order in which the transactions
became visible. There is a race condition such that
In reviewing the 2PC changes mentioned in a separate post, both Dan
and I realized that these were dependent on the assumption that
SSI's commitSeqNo is assigned in the order in which the transactions
became visible. There is a race condition such that this is not
necessarily true. It is a very n
26 matches
Mail list logo
