Tom Lane 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 recently-passed
Dan Ports 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 problem. Th
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
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 addit
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 ProcArra
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
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Dan Ports 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
"Kevin Grittner" writes:
> Dan Ports 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. W
Dan Ports 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
captured as par
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 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 synchronized s
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 Seri
"Kevin Grittner" writes:
> Tom Lane 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
"Kevin Grittner" 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 serializable
transactio
Tom Lane 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 time before,
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
16 matches
Mail list logo
