On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
> Heikki Linnakangas wrote:
> > IMHO it would be better to remove xmin from the lock key, and vacuum
> > away the old predicate locks when the corresponding tuple is vacuumed.
> > The xmin field is only required to handle the case tha
On Mon, Oct 07, 2013 at 12:26:37PM +0300, Heikki Linnakangas wrote:
> When updating a tuple, CheckTargetForConflictsIn() only marks a
> conflict if the transaction holding the predicate lock overlapped
> with the updating transaction.
Ah, this is the bit I was forgetting. (I really ought to have
r
On Fri, Feb 10, 2012 at 01:59:18PM -0500, Robert Haas wrote:
> I guess I'm not particularly excited by the idea of trying to make
> TRUNCATE MVCC-safe. I notice that the example involves the REPEATABLE
> READ isolation level, which is already known to be busted in a variety
> of ways; that's why w
Looking over the SSI 2PC code recently, I noticed that I overlooked a
case that could lead to non-serializable behavior after a crash.
When we PREPARE a serializable transaction, we store part of the
SERIALIZABLEXACT in the statefile (in addition to the list of SIREAD
locks). One of the pieces of
On Tue, Feb 14, 2012 at 10:04:15AM +0200, Heikki Linnakangas wrote:
> Perhaps it would be simpler to add the extra information to the commit
> records of the transactions that commit after the first transaction is
> prepared. In the commit record, you would include a list of prepared
> transacti
On Tue, Feb 14, 2012 at 09:27:58AM -0600, Kevin Grittner wrote:
> Heikki Linnakangas wrote:
> > On 14.02.2012 04:57, Dan Ports wrote:
> >> The easiest answer would be to just treat every prepared
> >> transaction found during recovery as though it had a conflict in
>
While mucking around in src/backend/utils/time/tqual.c today, I noticed
the following comment attached to HeapTupleSatisfiesNow:
* mao says 17 march 1993: the tests in this routine are correct;
* if you think they're not, you're wrong, and you should think
* about it again. i k
On Wed, Mar 07, 2012 at 07:46:32AM +, Simon Riggs wrote:
> There is much wisdom there and much wisdom in leaving ancient warnings
> as we find them.
The comment is a wise and insightful statement -- about a totally
different system than we have today.
> Are these the words you object to?
>
>
On Tue, Dec 07, 2010 at 10:14:24AM -0600, Kevin Grittner wrote:
> > Essentially, instead of adding dependencies as you go along and
> > abort once you hit a conflict, SERIALIZABLE READ ONLY DEFERRED
> > transactions would assume the worst case from the start and thus
> > be able to bypass the more
On Sat, Jan 08, 2011 at 10:20:22PM -0600, Kevin Grittner wrote:
> One thing that would help a lot besides code review is performance
> testing. I did some months ago and I know Dan booked time on MIT
> benchmarking systems and got good numbers, but with the refactoring
> it would be good to redo t
On Tue, Jan 11, 2011 at 12:34:44PM -0600, Kevin Grittner wrote:
> Agreed; but I am starting to get concerned about whether this
> particular area can be completed by the start of the CF. I might
> run a few days over on 2PC support. Unless ... Dan? Could you look
> into this while I chase down t
On Mon, Jan 17, 2011 at 09:58:44PM +0200, Heikki Linnakangas wrote:
> What does that comment about list of concurrent r/w transactions refer
> to? I don't see any list there. Does it refer to
> possibleUnsafeConflicts, which is above that comment?
Yes, that comment was supposed to be attached to
On Mon, Jan 17, 2011 at 06:52:09PM -0600, Kevin Grittner wrote:
> I think we still need the vxid. It shows in the pg_locks view, and
> we might possibly need it to find the right process to cancel once we
> have some way to do that. But there's no point with having the tag
> level anymore.
Oh, r
On Mon, Jan 17, 2011 at 07:20:20PM -0600, Kevin Grittner wrote:
> OK. I may need to bounce some questions off the list to resolve some
> of them. The biggest, in my mind, is whether MySerializableXact
> needs to be declared volatile. I don't have my head around the
> issues on that as well as I
Kevin's suggestion seems eminently reasonable to me and probably the
best approach one can do for SSI and hot standby. Pulling it off in
time for 9.1 would be a stretch; 9.2 seems quite doable.
It's worth noting that one way or another, the semantics of
SERIALIZABLE transactions on hot standby rep
> What I'm still not clear on is why that HS is different. Whatever rules
> apply on the master must also apply on the standby, immutably. Why is it
> we need to pass explicit snapshot information from master to standby? We
> don't do that, except at startup for normal HS. Why do we need that?
>
>
On Fri, Jan 21, 2011 at 08:44:59AM +0200, Heikki Linnakangas wrote:
> We have enough information in the standby to reconstruct all writes done
> in the master. I gather that's not enough, in order to roll back
> read-only transaction T3 on the standby which would see an anomaly, we'd
> also need
Thanks for working your way through this patch. I'm certainly well
aware that that's not a trivial task!
I'm suffering through a bout of insomnia, so I'll respond to some of
your high-level comments in hopes that serializability will help put me
to sleep (as it often does). I'll leave the more det
On Tue, Apr 09, 2013 at 07:49:51PM -0400, Robert Haas wrote:
> These locks are all SSI-related and they're all really hot. Lock 28
> is SerializableXactHashLock and lock 29 is
> SerializableFinishedListLock; both are acquired an order of magnitude
> more often than any non-SSI lock, and cause two
On Sat, Sep 08, 2012 at 11:34:56AM -0700, Jeff Davis wrote:
> If so, I think we need a documentation update. The serializable
> isolation level docs don't quite make it clear that serializability only
> applies to transactions that commit. It might not be obvious to a user
> that there's a differen
On Mon, Sep 10, 2012 at 10:44:57PM -0700, Jeff Davis wrote:
> For the archives, and for those not following the paper in detail, there
> is one situation in which SSI will abort a read-only transaction.
>
> When there are three transactions forming a dangerous pattern where T1
> (read-only) has a
I wasn't involved in this work but I do know a bit about it. Sadly, the
work on Postgres performance was cut down to under a page, complete
with the amazing offhand mention of "rewriting PostgreSQL's lock
manager". Here are a few more details...
The benchmarks in this paper are all about stressing
On Mon, Oct 04, 2010 at 01:13:36PM -0400, Robert Haas wrote:
> I believe the "one of only 16 global mutexes" comment is referring to
> NUM_LOCK_PARTITIONS (there's also NUM_BUFFER_PARTITIONS, but that
> wouldn't be relevant for row and table-level locks).
Yes -- my understanding is that they hit t
On Oct 4, 2010, at 11:06, Greg Stark wrote:
> I guess by "lock-free in the uncontended case" they mean the buffer
> cache manager is lock-free unless you're actually contending on the
> same buffer?
That refers to being able to acquire non-conflicting row/table locks without
needing an exclusiv
On Sat, Apr 16, 2011 at 11:26:34PM -0500, Kevin Grittner wrote:
> I have to say, I've been rather mystified by the difficulty
> attributed to running pgindent. During work on the SSI patch, I ran
> it about once every two weeks on files involved in the patch
Well, as a counterpoint: during work o
For background, the issue here is that there are three SSI calls that
get invoked even on non-serializable transactions:
- PredicateLockPageSplit/Combine, during B-tree page splits/combines
- PredicateLockTupleRowVersionLink, from heap_update
These have to update any matching SIREAD locks to m
On Sat, Apr 23, 2011 at 08:54:31AM -0500, Kevin Grittner wrote:
> Even though this didn't show any difference in Dan's performance
> tests, it seems like reasonable insurance against creating a new
> bottleneck in very high concurrency situations.
>
> Dan, do you have a patch for this, or should
On Wed, Apr 27, 2011 at 06:26:52PM +0100, Simon Riggs wrote:
> Reading the code, IIUC, we check for RW conflicts after each write but
> only if the writer is running a serializable transaction.
>
> Am I correct in thinking that there is zero impact of SSI if nobody is
> running a serializable tran
On Wed, Apr 27, 2011 at 02:59:19PM -0500, Kevin Grittner wrote:
> For correct serializable behavior in the face of concurrent DDL
> execution, I think that a request for a heavyweight ACCESS EXCLUSIVE
> lock might need to block until all SIREAD locks on the relation have
> been released. Pictur
On Thu, Apr 28, 2011 at 08:43:30AM +0100, Simon Riggs wrote:
> > We added a quick return which didn't need to check any locks at the
> > front of this routine which is taken if there are no active
> > serializable transactions on the cluster at the moment of update.
>
> Surprised to hear nobody me
On Thu, Apr 28, 2011 at 06:45:54PM +0200, Robert Haas wrote:
> Yeah, I think Dan's notes about memory ordering would be good to include.
I left it out initially because I didn't want to make things more
confusing. As far as memory ordering is concerned, this is the same
story as anything else that
On Tue, May 03, 2011 at 01:36:36PM +0900, Vlad Arkhipov wrote:
> Then I commited the both and the second one raised an exception:
> ERROR: could not serialize access due to read/write dependencies among
> transactions
> SQL state: 40001
>
> However the second transaction does not access the recor
While running some benchmarks to test SSI performance, I found a race
condition that's capable of causing a segfault. A patch is attached.
The bug is in CheckTargetForConflictsIn, which scans the list of SIREAD
locks on a lock target when it's modified. There's an optimization in
there where the w
On Thu, May 05, 2011 at 11:12:40PM -0400, Tom Lane wrote:
> Even if it's actually necessary to set up that data structure while
> holding XidGenLock, I would *really* like the call to not be exactly
> where it is.
Good question.
I don't believe it needs to be while XidGenLock is being held at all
On Fri, May 06, 2011 at 09:35:39PM -0400, Robert Haas wrote:
> Why does this HASH_FIND the applicable hash table entries and then
> HASH_REMOVE it as a separate step, instead of just HASH_REMOVE-ing it
> in one go?
For PredicateLockHash, we need to find the lock entry first so that we
can call SHM
On Fri, May 06, 2011 at 10:49:22PM -0400, Dan Ports wrote:
> Will update the patch.
Updated patch (in response to Robert's comments) attached.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend
On Sat, May 21, 2011 at 04:45:15PM -0400, Pavan Deolasee wrote:
> As a first step, it would be great if you can upload the slides on the
> conference website. To expect that the attendees would have understood the
> nitty-gritties of SSI just listening to the presentation is so unhuman :-)
I just
On Sat, May 21, 2011 at 03:09:12PM -0500, Kevin Grittner wrote:
> I went back to the example which persuaded me and took another look. On
> review I see that this didn't prove the point because there was a
> dangerous structure with T1 as a pivot which should have caused SSI to
> break the cycle.
I have thought about this quite a bit and am fairly certain we do not need
to track this linkage between row versions. One strong hint to this
is that all the work I've seen on multiversion serializability
theory defines a rw-conflict to be one transaction reading an object
and the other writing *t
On Tue, May 24, 2011 at 04:18:37AM -0500, Kevin Grittner wrote:
> These proofs show that
> there is no legitimate cycle which could cause an anomaly which the
> move from row-based to tuple-based logic will miss. They don't prove
> that the change will generate all the same serialization failures;
On Wed, Jun 01, 2011 at 05:09:09PM -0500, Kevin Grittner wrote:
> I won't be shocked if Dan can come up with a shorter proof, but I'm
> confident this one is solid.
Well, so happens I wrote a proof on the airplane today, before I saw
your mail. It's actually quite straightforward... (well, at leas
On Thu, Jun 02, 2011 at 01:01:05PM -0500, Kevin Grittner wrote:
> If we're going to put this into the README-SSI as the proof of the
> validity of this optimization, I'd like to have a footnote pointing
> to a paper describing the "first commit in the cycle" aspect of a
> dangerous structure. Got
On Sun, Jun 05, 2011 at 12:45:41PM -0500, Kevin Grittner wrote:
> Is this possible? If a transaction gets its snapshot while OID of N
> is assigned to relation X, can that transaction wind up seeing an OID
> of N as a reference to relation Y? If not, there aren't any false
> positives possible.
On Tue, Jun 07, 2011 at 07:45:43PM -0500, Kevin Grittner wrote:
> During testing of the SSI DDL changes I noticed that a REINDEX INDEX
> created a predicate lock on page 0 of the index.
Really? That surprises me, and I couldn't reproduce it just now.
Dan
--
Dan R. K. Ports MIT CSAI
On Tue, Jun 07, 2011 at 10:14:30PM -0400, Tom Lane wrote:
> Do you mean page zero, as in the metapage (for most index types), or do
> you mean the root page? If the former, how is that not an outright bug,
> since it corresponds to no data? If the latter, how is that not a
> serious performance p
On Wed, Jun 08, 2011 at 11:23:48AM +0300, Heikki Linnakangas wrote:
> AFAICS, the check for page lock is actually unnecessary. A page-level
> lock on a heap only occurs when tuple-level locks are promoted. It is
> just a coarser-grain representation of holding locks on all tuples on
> the page,
On Wed, Jun 08, 2011 at 05:48:26PM -0500, Kevin Grittner wrote:
> (1) Pass snapshot in to some predicate.c functions. The particular
> functions have yet to be determined, but certainly any which acquire
> predicate locks, and probably all which are guarded by the
> SkipSerialization() macro. Sk
On Wed, Jun 08, 2011 at 09:17:04PM -0500, Kevin Grittner wrote:
> A patch is attached which just covers the predicate lock acquisition,
> where a snapshot is available without too much pain. There are two
> functions which acquire predicate locks where a snapshot was not
> readily available: _bt_s
On Thu, Jun 09, 2011 at 07:06:18AM -0500, Kevin Grittner wrote:
> Sounds reasonable, but why did you pass the snapshot to the
> PredicateLockPage() call but not the PredicateLockRelation() call?
> Oversight?
Yep, just an oversight; long day yesterday. I'll fix the patch shortly
(unless you can ge
On Thu, Jun 09, 2011 at 01:30:27PM -0400, Dan Ports wrote:
> On Thu, Jun 09, 2011 at 07:06:18AM -0500, Kevin Grittner wrote:
> > Sounds reasonable, but why did you pass the snapshot to the
> > PredicateLockPage() call but not the PredicateLockRelation() call?
> > Oversig
On Fri, Jun 10, 2011 at 09:43:58PM +0300, Heikki Linnakangas wrote:
> > Do checks such as that argue for keeping the volatile flag, or do
> > you think we can drop it if we make those changes? (That would also
> > allow dropping a number of casts which exist just to avoid
> > warnings.)
>
> I bel
On Sat, Jun 11, 2011 at 01:38:31PM -0500, Kevin Grittner wrote:
> I'm not concerned about references covered by
> SerializableXactHashLock. I am more concerned about some of the
> tests for whether the (MySerializableXact == InvalidSerializableXact)
> checks and any other tests not covered by that
On Mon, Jun 13, 2011 at 10:22:19PM +0300, Heikki Linnakangas wrote:
> As far as I can tell it was for purely cosmetic reasons, to have lock
> and predicate lock lines together.
Yes, that is the only reason.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent
On Mon, Jun 13, 2011 at 03:33:24PM -0400, Tom Lane wrote:
> We can either change that now, or undo the
> unnecessary change in existing RM IDs. I vote for the latter.
Sounds good to me. I'd offer a patch, but it'd probably take you longer
to apply than to make the change yourself.
Dan
--
Dan R
The attached patch updates README-SSI. In addition to some minor edits,
changes include:
- add a section at the beginning that more clearly describes the SSI
rule and defines "dangerous structure" with a diagram. It describes
the optimizations we use about the relative commit times, and the
On Thu, Jun 16, 2011 at 04:39:09PM +0300, Heikki Linnakangas wrote:
> There's no mention on what T1 is. I believe it's supposed to be Tin, in
> the terminology used in the graph.
Yes, I changed the naming after I originally wrote it, and missed a
couple spots. T1 should be Tin.
> I don't see how
On Thu, Jun 16, 2011 at 11:49:48PM -0400, Robert Haas wrote:
> Does this mean that the open item "more SSI loose ends" can now be
> marked resolved?
I was just looking at it and contemplating moving it to the non-blockers
list. Of the five items:
- (1) and (4) are resolved
- (2) isn't an issue -
On Fri, Jun 17, 2011 at 12:32:46AM -0400, Robert Haas wrote:
> Perhaps it would be best to remove the general item and replace it
> with a list of more specific things that need doing - which might just
> mean #5.
Done.
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
-
On Sun, Jun 19, 2011 at 09:10:02PM -0400, Robert Haas wrote:
> Is this an open item for 9.1beta3?
Yes. I've put it on the list.
The SxactGlobalXmin and its refcount were getting out of sync with the
actual transaction state. This is timing-dependent but I can reproduce it
fairly reliably under co
While testing the fix for this one, I found another bug. Patches for
both are attached.
The first patch addresses this bug by re-adding SXACT_FLAG_ROLLED_BACK,
in a more limited form than its previous incarnation.
We need to be able to distinguish transactions that have already
called ReleasePred
On Tue, Jun 21, 2011 at 06:51:20PM -0400, Tom Lane wrote:
> I find this to be poor style, and would like to see if there's any
> support for getting rid of the "const" keywords.
I'm in favor of removing them too.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
I was looking at ExecSeqScan today and noticed that it invokes
PredicateLockRelation each time it's called, i.e. for each tuple
returned. Any reason we shouldn't skip that call if
rs_relpredicatelocked is already set, as in the attached patch?
That would save us a bit of overhead, since checking t
On Tue, Jun 21, 2011 at 03:01:48PM +0300, Heikki Linnakangas wrote:
> Thanks, committed.
Thanks.
> In the long term, I'm not sure this is the best way to handle this. It
> feels a bit silly to set the flag, release the SerializableXactHashLock,
> and reacquire it later to remove the transaction
On Wed, Jun 22, 2011 at 01:31:11AM -0400, Dan Ports wrote:
> Yes, I suspect it can be done better. The reason it's tricky is a lock
> ordering issue; part of releasing a SerializableXact has to be done
> while holding SerializableXactHashLock and part has to be done without
&g
On Wed, Jun 22, 2011 at 12:07:04PM +0300, Heikki Linnakangas wrote:
> Hmm, I wonder if we should move this logic to heapam.c. The optimization
> to acquire a relation lock straight away should apply to all heap scans,
> not only those coming from ExecSeqScan. The distinction is academic at
> the
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
On Tue, Jul 05, 2011 at 09:14:30PM +0300, Heikki Linnakangas wrote:
> I think that needs some explanation, why only those SxactIsCommitted()
> tests need to be replaced with SxactIsPrepared()?
Here is the specific problem this patch addresses:
If there's a dangerous structure T0 ---> T1 ---> T2,
On Wed, Jan 26, 2011 at 10:01:28AM -0600, Kevin Grittner wrote:
> In looking at it just now, I noticed that after trying it in a
> couple different places what was left in the repository was not the
> optimal version for code coverage. I've put this back to the
> version which did a better job, fo
On Wed, Jan 26, 2011 at 01:42:23PM -0600, Kevin Grittner wrote:
> Dan, do you still have access to that machine you were using for the
> DBT-2 runs? Could we get a coverage run with and without
> TEST_OLDSERXID defined?
Sure, I'll give it a shot (once I figure out how to enable coverage...)
Dan
On Wed, Jan 26, 2011 at 02:36:25PM -0600, Kevin Grittner wrote:
> Same benefit in terms of exercising more lines of code, but
> *without* exposing the uninitialized structure to other threads.
Won't this cause a deadlock because locks are being acquired out of
order?
Dan
--
Dan R. K. Ports
On Thu, Jan 27, 2011 at 09:18:23AM -0800, Jeff Davis wrote:
> On Tue, 2011-01-25 at 05:57 -0500, Dan Ports wrote:
> > This summary is right on. I would add one additional detail or
> > clarification to the last point, which is that rather than checking for
> > a cycle,
On Sun, Jan 30, 2011 at 04:01:56PM -0600, Kevin Grittner wrote:
> I'm wondering how this differs from what is discussed in Section 2.7
> ("Serialization Graph Testing") of Cahill's doctoral thesis. That
> discusses a technique for trying to avoid false positives by testing
> the full graph for cyc
On Tue, Feb 08, 2011 at 11:25:34AM +0200, Heikki Linnakangas wrote:
> On 08.02.2011 10:43, Kevin Grittner wrote:
> > I see that at least three BuildFarm critters don't have UINT64_MAX
> > defined.
>
> I guess we'll have to just #define it ourselves. Or could we just pick
> another magic value, do
On Tue, Feb 08, 2011 at 10:14:44AM -0600, Kevin Grittner wrote:
> I do have some concern that if this defaults to too low a number,
> those who try SSI without bumping it and restarting the postmaster
> will not like the performance under load very much. SSI performance
> would not be affected by
One other nit re. the predicate lock table size GUCs: the out-of-memory
case in RegisterPredicateLockingXid (predicate.c:1592 in my tree) gives
the hint to increase max_predicate_locks_per_transaction. I don't think
that's correct, since that GUC isn't used to size SerializableXidHash.
In fact, th
On Tue, Feb 08, 2011 at 04:04:39PM -0600, Kevin Grittner wrote:
> (2) The predicate lock and lock target initialization code was
> initially copied and modified from the code for heavyweight locks.
> The heavyweight lock code adds 10% to the calculated maximum size.
> So I wound up doing that fo
On Tue, Feb 08, 2011 at 09:09:48PM -0500, Robert Haas wrote:
> No way to fail is a tall order.
Well, no way to fail due to running out of shared memory in
RegisterPredicateLock/RegisterPredicateLockingXid, but that doesn't
have quite the same ring to it...
> If we don't allocate all the memory up
On Wed, Feb 16, 2011 at 10:13:35PM +, YAMAMOTO Takashi wrote:
> i got the following SEGV when runnning vacuum on a table.
> (the line numbers in predicate.c is different as i have local modifications.)
> oldlocktag.myTarget was NULL.
> it seems that TransferPredicateLocksToNewTarget sometimes u
On Mon, Feb 21, 2011 at 11:42:36PM +, YAMAMOTO Takashi wrote:
> i tested ede45e90dd1992bfd3e1e61ce87bad494b81f54d + ssi-multi-update-1.patch
> with my application and got the following assertion failure.
>
> #4 0x0827977e in CheckTargetForConflictsIn (targettag=0xbfbfce78)
> at predicate.c
On Tue, Feb 22, 2011 at 10:51:05AM -0600, Kevin Grittner wrote:
> Dan Ports wrote:
>
> > It looks like CheckTargetForConflictsIn is making the assumption
> > that the backend-local lock table is accurate, which was probably
> > even true at the time it was written.
>
On Tue, Feb 22, 2011 at 05:54:49PM -0600, Kevin Grittner wrote:
> I'm not sure it's safe to assume that the index page won't get
> reused before the local lock information is cleared. In the absence
> of a clear proof that it is safe, or some enforcement mechanism to
> ensure that it is, I don't t
An updated patch to address this issue is attached. It fixes a couple
issues related to use of the backend-local lock table hint:
- CheckSingleTargetForConflictsIn now correctly handles the case
where a lock that's being held is not reflected in the local lock
table. This fixes the asser
On Tue, Mar 01, 2011 at 07:07:42PM +0200, Heikki Linnakangas wrote:
> Was there test cases for any of the issues fixed by this patch that we
> should add to the suite?
Some of these issues are tricky to test, e.g. some of the code about
transferring predicate locks to a new target doesn't get exe
It would probably also be worth monitoring the size of pg_locks to see
how many predicate locks are being held.
On Fri, Mar 18, 2011 at 12:50:16PM -0500, Kevin Grittner wrote:
> Even with the above information it may be far from clear where
> allocations are going past their maximum, since one HT
On Fri, Mar 25, 2011 at 04:06:30PM -0400, Tom Lane wrote:
> Up to now, I believe the lockmgr's lock table is the only shared hash
> table that is expected to grow past the declared size; that can happen
> anytime a session exceeds max_locks_per_transaction, which we consider
> to be only a soft lim
On Thu, Mar 31, 2011 at 11:06:30AM -0500, Kevin Grittner wrote:
> The only thing I've been on the fence about is whether it
> makes more sense to allocate it all up front or to continue to allow
> incremental allocation but set a hard limit on the number of entries
> allocated for each shared memor
While looking into a SSI bug, I noticed that we don't actually display
the pid of the holding transaction, even though we have that
information available.
The attached patch fixes that.
One note is that it will show the pid of the backend that executed the
transaction, even if that transaction ha
On Fri, Apr 01, 2011 at 12:20:25PM -0500, Kevin Grittner wrote:
> I thought we already had that, but clearly I was mistaken.
Yeah, so did I. Turns out we had the vxid but not the pid. IIRC, we
weren't tracking a SERIALIZABLEXACT's pid yet, at the time we wrote the
code for pg_locks.
> I guess the
I think I see what is going on now. We are sometimes failing to set the
commitSeqNo correctly on the lock. In particular, if a lock assigned to
OldCommittedSxact is marked with InvalidSerCommitNo, it will never be
cleared.
The attached patch corrects this:
TransferPredicateLocksToNewTarget should
On Mon, Apr 04, 2011 at 10:33:22AM -0500, Kevin Grittner wrote:
> There are patches for all known issues except one. Dan Ports was
> able to replicate the latest issue uncovered by YAMAMOTO Takashi
> using a particular DBT-2 configuration, found the issue, and posted
> a patch:
Well,
On Mon, Apr 04, 2011 at 07:04:59PM -0400, Robert Haas wrote:
> On Mon, Apr 4, 2011 at 6:41 PM, Stephen Frost wrote:
> > What'd be horribly useful would be the pid and the *time* that the lock
> > was taken.. ?Knowing just the pid blows, since the pid could technically
> > end up reused (tho not te
On Wed, Apr 06, 2011 at 12:25:26PM -0500, Kevin Grittner wrote:
> By the way, the problem with SSI potentially running out of shared
> memory is rather parallel to how heavyweight locks can run out of
> shared memory. The SLRU prevents the number of transactions from
> being limited in that way, a
On Mon, Jan 06, 2014 at 05:14:12PM -0800, AK wrote:
> Also I cannot reproduce a scenario when "applications must not depend on
> results read during a transaction that later aborted;". In this example the
> SELECT itself has failed.
> Can you show an example where a SELECT completes, but the COMMIT
On Sun, May 23, 2010 at 04:21:58PM -0400, Jan Wieck wrote:
> In some systems (data warehousing, replication), the order of commits is
> important, since that is the order in which changes have become visible.
> This information could theoretically be extracted from the WAL, but
> scanning the entir
On Mon, May 24, 2010 at 10:24:07AM -0500, Kevin Grittner wrote:
> Jan Wieck wrote:
>
> > In some systems (data warehousing, replication), the order of
> > commits is important, since that is the order in which changes
> > have become visible.
>
> This issue intersects with the serializable work
On Tue, May 25, 2010 at 02:00:42PM +0200, Nicolas Barbier wrote:
> I don't understand the problem. According to me, in the context of
> SSI, a read-only slave can just map SERIALIZABLE to the technical
> implementation of REPEATABLE READ (i.e., the currently-existing
> "SERIALIZABLE"). The union of
On Tue, May 25, 2010 at 08:35:44PM +0200, Florian Pflug wrote:
> Hm, so in fact SSI sometimes allows the database to be inconsistent, but only
> as long as nobody tries to observe it?
Yes. Note that even while it's in an inconsistent state, you can still
perform any query that doesn't observe the
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
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
On Thu, Jul 21, 2011 at 02:31:15PM -0400, Robert Haas wrote:
> 1. Machines with strong memory ordering. On this category of machines
> (which include x86), the CPU basically does not perform loads or
> stores out of order. On some of these machines, it is apparently
> possible for there to be som
1 - 100 of 113 matches
Mail list logo
