Alvaro Herrera [EMAIL PROTECTED] writes
Because we can't reuse MultiXactIds at system crash (else we risk taking
an Id which is already stored in some tuple), we need to XLog it. Not
at the locking operation, because we don't want to log that one (too
expensive.) We can log the current
On Thu, Apr 07, 2005 at 02:34:03PM +0800, Qingqing Zhou wrote:
Alvaro Herrera [EMAIL PROTECTED] writes
Because we can't reuse MultiXactIds at system crash (else we risk taking
an Id which is already stored in some tuple), we need to XLog it. Not
at the locking operation, because we don't
Hackers,
Again I come back to this topic. Now I have a better hold on an idea
that is hopefully implementable and doesn't have expensive performance
penalties.
Forget the idea of using the regular lock manager directly on tuples.
It's folly because we can't afford to have that many locks.
On Wed, 29 Dec 2004 19:57:15 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
I don't see too much of a difference between #1 (an on-disk structure
buffered in shared memory) and #2 (a shared memory structure spilling
to disk).
If you stand back that far, maybe
Manfred Koizar [EMAIL PROTECTED] writes:
So the question is whether starting by making nbtree more flexible isn't
the lower hanging fruit...
Certainly not; indexes depend on locks, not vice versa. You'd not be
able to do that without introducing an infinite recursion into the
system design.
On Thu, 30 Dec 2004 13:36:53 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Certainly not; indexes depend on locks, not vice versa. You'd not be
able to do that without introducing an infinite recursion into the
system design.
Wouldn't you have to face the same sort of problems if you spill part of
Manfred Koizar [EMAIL PROTECTED] writes:
On Thu, 30 Dec 2004 13:36:53 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Certainly not; indexes depend on locks, not vice versa. You'd not be
able to do that without introducing an infinite recursion into the
system design.
Wouldn't you have to face the
On Thu, 16 Dec 2004 21:54:14 -0300, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Else, it will have to wait, using XactLockTableWait, for
the first transaction in the array that is still running. We can be
sure that no one will try to share-lock the tuple while we check the
btree because we hold an
On Mon, 20 Dec 2004 21:44:01 +0100, [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] wrote on 20.12.2004, 19:34:21:
#1 could have a pretty serious performance impact, too. For small
numbers of FOR UPDATE locks (too few to force spill to disk) I would
expect #2 to substantially beat #1. #1
Manfred Koizar [EMAIL PROTECTED] writes:
I don't see too much of a difference between #1 (an on-disk structure
buffered in shared memory) and #2 (a shared memory structure spilling
to disk).
If you stand back that far, maybe you can't see a difference ;-) ...
but the proposal on the table was
In general, I agree with Tom: I haven't seen many programs that use
extended SELECT FOR UPDATE logic. However, the ones I have seen have
been batch style programs written using a whole-table cursor - these
latter ones have been designed for the cursor stability approach.
I think if we add
On Mon, Dec 20, 2004 at 03:09:24PM -0300, Alvaro Herrera wrote:
To solve the problem I want to solve, we have three orthogonal
possibilities:
1. implement shared row locking using the ideas outlined in the mail
starting this thread (pg_clog-like seems to be the winner, details TBD).
2.
On Mon, 2004-12-20 at 06:34, Jim C. Nasby wrote:
On Sun, Dec 19, 2004 at 11:35:02PM +0200, Heikki Linnakangas wrote:
On Sun, 19 Dec 2004, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Sun, 19 Dec 2004, Alvaro Herrera wrote:
This is not useful at all, because the
On Mon, Dec 20, 2004 at 06:23:24PM +1100, Gavin Sherry wrote:
On Sat, 18 Dec 2004, Bruce Momjian wrote:
Agreed. Once concern I have about allowing the lock table to spill to
disk is that a large number of FOR UPDATE locks could push out lock
entries used by other backends, causing very
Gavin Sherry [EMAIL PROTECTED] writes:
I think if we allow the lock manager to spill to disk (and I think we do
need to allow it) then we should also be able to control the amount of
shared memory allocated.
You mean like max_locks_per_transaction?
regards, tom lane
Alvaro Herrera [EMAIL PROTECTED] writes:
Gavin also mentioned to me we should also control the amount of memory
the shared inval queue uses.
Perhaps, but I've really seen no evidence that there's a need to worry
about that. Without demonstrated problems I'd sooner keep that code a
bit simpler
Tom lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
I think if we allow the lock manager to spill to disk (and I think
we do
need to allow it) then we should also be able to control the amount
of
shared memory allocated.
You mean like max_locks_per_transaction?
IMO,
Merlin Moncure [EMAIL PROTECTED] writes:
I may be over my head here, but I think lock spillover is dangerous. In
the extreme situations where this would happen, it would be a real
performance buster. Personally, I would rather see locks escalate when
the table gets full, or at least allow
On Mon, Dec 20, 2004 at 11:47:41AM -0500, Tom Lane wrote:
To me, performance buster is better than random, unrepeatable
deadlock failures. In any case, if we find we *can't* implement this
in a non-performance-busting way, then it would be time enough to look
at alternatives that force the
Alvaro Herrera [EMAIL PROTECTED] writes:
To solve the problem I want to solve, we have three orthogonal
possibilities:
1. implement shared row locking using the ideas outlined in the mail
starting this thread (pg_clog-like seems to be the winner, details TBD).
2. implement shared lock table
Tom Lane [EMAIL PROTECTED] wrote on 20.12.2004, 19:34:21:
Alvaro Herrera writes:
To solve the problem I want to solve, we have three orthogonal
possibilities:
1. implement shared row locking using the ideas outlined in the mail
starting this thread (pg_clog-like seems to be the
On Sun, 2004-12-19 at 04:04, Bruce Momjian wrote:
BTom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
You mean all empty/zero rows can be removed? Can we guarantee that on
commit we can clean up the bitmap? If not the idea doesn't work.
For whatever data structure we use, we
On Sun, Dec 19, 2004 at 09:52:01AM +, Simon Riggs wrote:
Simon,
In similar circumstances, DB2 uses these techniques:
- when locktable X % full, then escalate locks to full table locks: both
locktable memory and threshold% are instance parameters
This is not useful at all, because the
Alvaro Herrera [EMAIL PROTECTED] writes:
On Sun, Dec 19, 2004 at 09:52:01AM +, Simon Riggs wrote:
- use a lock mode called Cursor Stability that locks only those rows
currently being examined by a cursor, those maintaining the lock usage
of a cursor at a constant level as the cursor moves.
On Sun, 19 Dec 2004, Alvaro Herrera wrote:
On Sun, Dec 19, 2004 at 09:52:01AM +, Simon Riggs wrote:
Simon,
In similar circumstances, DB2 uses these techniques:
- when locktable X % full, then escalate locks to full table locks: both
locktable memory and threshold% are instance parameters
This
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Sun, 19 Dec 2004, Alvaro Herrera wrote:
This is not useful at all, because the objective of this exercise is to
downgrade locks, from exclusive row locking (SELECT ... FOR UPDATE) to
shared row locking.
Actually it might help in some scenarios.
On Sun, 19 Dec 2004, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Sun, 19 Dec 2004, Alvaro Herrera wrote:
This is not useful at all, because the objective of this exercise is to
downgrade locks, from exclusive row locking (SELECT ... FOR UPDATE) to
shared row locking.
Actually
On Sun, 2004-12-19 at 18:31, Alvaro Herrera wrote:
Thanks for your ideas anyway. And keep having them!
No problem. Just giving some info on what works and doesn't work in
other implementations.
--
Best Regards, Simon Riggs
---(end of
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Sun, 19 Dec 2004, Alvaro Herrera wrote:
This is not useful at all, because the objective of this exercise is to
downgrade locks, from exclusive row locking (SELECT ... FOR UPDATE) to
shared row locking.
Actually it might
On Sun, Dec 19, 2004 at 11:35:02PM +0200, Heikki Linnakangas wrote:
On Sun, 19 Dec 2004, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Sun, 19 Dec 2004, Alvaro Herrera wrote:
This is not useful at all, because the objective of this exercise is to
downgrade locks, from
On Sat, 18 Dec 2004, Bruce Momjian wrote:
BTom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
You mean all empty/zero rows can be removed? Can we guarantee that on
commit we can clean up the bitmap? If not the idea doesn't work.
For whatever data structure we use, we may reset
BTom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
You mean all empty/zero rows can be removed? Can we guarantee that on
commit we can clean up the bitmap? If not the idea doesn't work.
For whatever data structure we use, we may reset the structure to empty
during backend-crash
Hi,
I've been thinking on how to do shared row locking. There are some very
preliminar ideas on this issue. Please comment; particularly if any
part of it sounds unworkable or too incomplete.
There are several problems to be solved here: the grammar, the internal
SelectStmt representation, how
Alvaro Herrera wrote:
The btree idea:
- does not need crash recovery. Maybe we could use a stripped down
version of nbtree. This could cause a maintanibility nightmare.
Are you saying the btree is an index with no heap? If so, what about
the xid's? Are they just in the btree?
How does
The SQL spec does not say anything on this respect (that I can find).
It only talks of FOR UPDATE and FOR READ ONLY. However, because the
FK code uses SPI to do the locking, we definitely have to expose the
funcionality through SQL. So I think we need a new clause, which I
propose to be FOR
Alvaro Herrera [EMAIL PROTECTED] writes:
Using a B-tree
At transaction end, nothing special happens (tuples are not unlocked
explicitly).
I don't think that works, because there is no guarantee that an entry
will get cleaned out before the XID counter wraps around. Worst case,
you might
Bruce Momjian [EMAIL PROTECTED] writes:
You mean all empty/zero rows can be removed? Can we guarantee that on
commit we can clean up the bitmap? If not the idea doesn't work.
For whatever data structure we use, we may reset the structure to empty
during backend-crash recovery. So your
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Using a B-tree
At transaction end, nothing special happens (tuples are not unlocked
explicitly).
I don't think that works, because there is no guarantee that an entry
will get cleaned out before the XID counter wraps around.
38 matches
Mail list logo
