Tom Lane t...@sss.pgh.pa.us wrote:
I don't understand the SSI code well enough to tell if this is
sufficient or not, so I hope you guys will take a closer look at
the issue when you have time.
I will definitely give it a look. Right now we have a perfect
storm of time demands due to some
Dan Ports d...@csail.mit.edu writes:
On Wed, Oct 19, 2011 at 04:36:41PM -0400, Tom Lane wrote:
(2) as things stand, xact A need not be running in serializable mode ---
if B is serializable, does *that* break any assumptions?
[taking these in opposite order]
Yes, I think that's going to be a
Dan Ports wrote:
I think it would be fairly sensible to push some of this into
ProcArray, actually. The commit sequence numbers just involve
assigning/incrementing a global counter when taking a snapshot and
finishing a transaction -- that's not too much work, doesn't
require any
On Thu, Oct 20, 2011 at 07:33:59AM -0500, Kevin Grittner wrote:
Dan Ports wrote:
The part that's harder is building the list of potential conflicts
that's used to identify safe snapshots for r/o transactions. That
(currently) has to happen atomically taking the snapshot.
That's not
Is it really necessary for GetSerializableTransactionSnapshotInt to
acquire an empty SERIALIZABLEXACT before it acquires a snapshot?
If so, why? The proposed synchronized-snapshots feature will mean
that the allegedly-new snapshot actually was taken some time before,
so it seems to me that either
Tom Lane t...@sss.pgh.pa.us wrote:
Is it really necessary for GetSerializableTransactionSnapshotInt
to acquire an empty SERIALIZABLEXACT before it acquires a
snapshot? If so, why? The proposed synchronized-snapshots
feature will mean that the allegedly-new snapshot actually was
taken some
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
If the intent is that each serializable transaction sharing
the snapshot is a separate logical transaction, it *might* hold --
I think the rules have to be that the snapshot provided to a
serializable transaction must be provided by an active
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Is it really necessary for GetSerializableTransactionSnapshotInt
to acquire an empty SERIALIZABLEXACT before it acquires a
snapshot? If so, why? The proposed synchronized-snapshots
feature will mean that
On Wed, Oct 19, 2011 at 12:56:58PM -0400, Tom Lane wrote:
Is it really necessary for GetSerializableTransactionSnapshotInt to
acquire an empty SERIALIZABLEXACT before it acquires a snapshot?
If so, why?
*That* isn't necessary, no. It is necessary, however, to acquire the
snapshot while
Dan Ports d...@csail.mit.edu writes:
On Wed, Oct 19, 2011 at 12:56:58PM -0400, Tom Lane wrote:
The proposed synchronized-snapshots feature will mean
that the allegedly-new snapshot actually was taken some time before,
so it seems to me that either this is not necessary or we cannot use
a
On Wed, Oct 19, 2011 at 04:36:41PM -0400, Tom Lane wrote:
No, the intention of the synchronized-snapshots feature is just to be
able to start multiple transactions using exactly the same snapshot.
They're independent after that. The aspect of it that is worrying me
is that if xact A starts,
Dan Ports d...@csail.mit.edu wrote:
the sxact's lastCommitBeforeSnapshot needs to match the snapshot,
SxactGlobalXmin needs to be set to the correct value, etc. That's
why the call to GetSnapshotData happens from where it does
Oh, right. I knew I was forgetting something. What if that was
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Dan Ports d...@csail.mit.edu wrote:
the sxact's lastCommitBeforeSnapshot needs to match the snapshot,
SxactGlobalXmin needs to be set to the correct value, etc. That's
why the call to GetSnapshotData happens from where it does
Oh, right. I
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Dan Ports d...@csail.mit.edu wrote:
the sxact's lastCommitBeforeSnapshot needs to match the
snapshot, SxactGlobalXmin needs to be set to the correct value,
etc. That's why the call to GetSnapshotData happens
On Wed, Oct 19, 2011 at 05:04:52PM -0400, Tom Lane wrote:
I wonder whether it would be prudent to set the synchronized-snapshots
patch aside until you've finished that work (assuming you're actively
working on it). It's evidently going to require some nontrivial changes
in predicate.c, and I
I think it would be fairly sensible to push some of this into
ProcArray, actually. The commit sequence numbers just involve assigning/
incrementing a global counter when taking a snapshot and finishing a
transaction -- that's not too much work, doesn't require any additional
locking beyond
16 matches
Mail list logo
