Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, Apr 01, 2005 at 10:14:07PM -0500, Paul Tillotson wrote:
...
Well, at that point you need to take a lock in order to be able to
manage locks. Managing not to step on your
On Fri, Apr 01, 2005 at 11:02:36PM -0500, Tom Lane wrote:
[Cc: to -hackers]
We currently store tuple locks on the same page as the tuples (ie, in
the tuple headers) and need no extra locks to do so. Certainly it
still has to have a spill mechanism, but the thought that is attractive
to me
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I looked at Paul's first message and thought nah, that won't work
because ... because ... hmm ... hmmm ...
For what it's worth, this would be very similar to how Oracle handles
[EMAIL PROTECTED] (Bruno Wolff III) writes:
Using domains is a good way to keep column constraints in just one place.
Speaking of domains, how do you find out what the range of a domain
is?
eg:
test=# create domain fruit as text
check( value in ('apple', 'orange', 'banana', 'pear'));
CREATE
On Fri, Apr 01, 2005 at 09:27:40AM -0700, Edmund Bacon wrote:
Speaking of domains, how do you find out what the range of a domain
is?
I'm not sure if there's a better way, but this appears to work:
SELECT pg_get_constraintdef(oid, TRUE)
FROM pg_constraint
WHERE contypid = 'fruit'::regtype;
[EMAIL PROTECTED] wrote:
On Sun, Mar 27, 2005 at 12:54:28AM -0600, Guy Rouillier wrote: []
The service_plane table is a reference table, i.e., a fixed set of
values used only to validate foreign keys. So the code doesn't have
any update statements on that table.
And idea that just came up
On Sun, Mar 27, 2005 at 12:54:28AM -0600, Guy Rouillier wrote:
[]
The service_plane table is a reference table, i.e., a fixed set of
values used only to validate foreign keys. So the code doesn't have any
update statements on that table.
And idea that just came up around here that sounds like
On Fri, Apr 01, 2005 at 10:37:11 +0200,
[EMAIL PROTECTED] wrote:
And idea that just came up around here that sounds like a pretty neat
workaround, which we're gonna try, is to drop the foreign key
constraints, and just use a check constraint for the allowed values. If
the cardinality of
Alvaro,
I suppose there must be reasons not to do this, but have you considered
using the slack space (empty space) in an ordinary table heap page
to store share-locks on the tuples in that page? (If not enough space
is available then you would still need to use the spilled-to-disk btree
On Fri, Apr 01, 2005 at 07:41:54PM -0500, Paul Tillotson wrote:
Hi,
I suppose there must be reasons not to do this, but have you considered
using the slack space (empty space) in an ordinary table heap page
to store share-locks on the tuples in that page? (If not enough space
is
I suppose there must be reasons not to do this, but have you considered
using the slack space (empty space) in an ordinary table heap page
to store share-locks on the tuples in that page? (If not enough space
is available then you would still need to use the spilled-to-disk btree
structure.)
On Fri, Apr 01, 2005 at 10:14:07PM -0500, Paul Tillotson wrote:
Would it work for an updater, who finds that the locks list (currently
located in the middle of the empty space) is in the way of a new tuple
that he wants to insert, to take some kind of lock, move the whole list
up or down
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, Apr 01, 2005 at 10:14:07PM -0500, Paul Tillotson wrote:
...
Well, at that point you need to take a lock in order to be able to
manage locks. Managing not to step on your own feet in that scenario
is complex, to say the least, if not downright
Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, Apr 01, 2005 at 10:14:07PM -0500, Paul Tillotson wrote:
...
Well, at that point you need to take a lock in order to be able to
manage locks. Managing not to step on your own feet in that scenario
is
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I looked at Paul's first message and thought nah, that won't work
because ... because ... hmm ... hmmm ...
For what it's worth, this would be very similar to how Oracle handles such
locks.
[ slightly alarmed ] Do they
Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, Mar 30, 2005 at 05:41:04PM -0500, Greg Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Is that true even if I'm updating/deleting 1,000 tuples that all reference
the
same foreign key? It seems like that should only need a
Alvaro Herrera wrote:
Now this can't be applied right away because it's easy to run out of
memory (shared memory for the lock table). Say, a delete or update
that touches 1 tuples does not work. I'm currently working on a
proposal to allow the lock table to spill to disk ...
While
On Thu, Mar 31, 2005 at 06:54:31PM -0600, Guy Rouillier wrote:
Alvaro Herrera wrote:
Now this can't be applied right away because it's easy to run out of
memory (shared memory for the lock table). Say, a delete or update
that touches 1 tuples does not work. I'm currently working on
On Sun, Mar 27, 2005 at 01:37:44AM -0700, Michael Fuhr wrote:
[]
The current implementation supports only
exclusive row-level locks (SELECT FOR UPDATE), but I think Alvaro
might be working on shared row-level locks for a future release.
Hmm ... are you saying that SELECT FOR UPDATE exquires an
On Wed, Mar 30, 2005 at 10:59:52PM +0200, [EMAIL PROTECTED] wrote:
On Sun, Mar 27, 2005 at 01:37:44AM -0700, Michael Fuhr wrote:
The current implementation supports only
exclusive row-level locks (SELECT FOR UPDATE), but I think Alvaro
might be working on shared row-level locks for a future
On Wed, Mar 30, 2005 at 02:30:58PM -0700, Michael Fuhr wrote:
I think Alvaro is working on a new locking mechanism that will allow
transactions to prevent a record from being modified without blocking
other transactions doing the same.
Yeah, and it does work. (I posted the patch two days
Alvaro Herrera [EMAIL PROTECTED] writes:
Now this can't be applied right away because it's easy to run out of
memory (shared memory for the lock table). Say, a delete or update
that touches 1 tuples does not work. I'm currently working on a
proposal to allow the lock table to spill to
On Mar 30, 2005, at 4:47 PM, Alvaro Herrera wrote:
Now this can't be applied right away because it's easy to run out of
memory (shared memory for the lock table). Say, a delete or update
that touches 1 tuples does not work. I'm currently working on a
proposal to allow the lock table to spill
On Wed, Mar 30, 2005 at 05:41:04PM -0500, Greg Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Now this can't be applied right away because it's easy to run out of
memory (shared memory for the lock table). Say, a delete or update
that touches 1 tuples does not work. I'm
On Sun, Mar 27, 2005 at 06:02:25PM -0600, Guy Rouillier wrote:
With the current implementation, it appears I need to either (1) always
commit after every inserted row, or (2) single thread my entire insert
logic. Neither of these two alternatives is very desirable. And it is
only a partial
Alvaro Herrera wrote:
On Sun, Mar 27, 2005 at 06:02:25PM -0600, Guy Rouillier wrote:
With the current implementation, it appears I need to either (1)
always commit after every inserted row, or (2) single thread my
entire insert logic. Neither of these two alternatives is very
desirable.
On Sun, Mar 27, 2005 at 12:54:28AM -0600, Guy Rouillier wrote:
I'm getting the following in the server log:
2005-03-27 06:04:21 GMT estat DETAIL: Process 20928 waits for ShareLock
on transaction 7751823; blocked by process 20929.
Process 20929 waits for ShareLock on transaction
Michael Fuhr [EMAIL PROTECTED] writes
To make sure the referenced key can't change until the transaction
completes and the referencing row becomes visible to other transactions
(or is rolled back) -- otherwise other transactions could change
or delete the referenced key and not know they'd be
On Sun, 27 Mar 2005, Qingqing Zhou wrote:
Michael Fuhr [EMAIL PROTECTED] writes
To make sure the referenced key can't change until the transaction
completes and the referencing row becomes visible to other transactions
(or is rolled back) -- otherwise other transactions could change
or
Michael Fuhr wrote:
On Sun, Mar 27, 2005 at 12:54:28AM -0600, Guy Rouillier wrote:
I'm getting the following in the server log:
2005-03-27 06:04:21 GMT estat DETAIL: Process 20928 waits for
ShareLock on transaction 7751823; blocked by process 20929.
Process 20929 waits for ShareLock
On Sun, Mar 27, 2005 at 06:02:25PM -0600, Guy Rouillier wrote:
With the current implementation, it appears I need to either (1) always
commit after every inserted row, or (2) single thread my entire insert
logic. Neither of these two alternatives is very desirable.
I think a usual workaround
Stephan Szabo [EMAIL PROTECTED] writes
Well, that's not the foreign key necessarily. I don't have a machine to
test on at the moment (machine currently dead), but I think the same
happens without a foreign key constraint due to the unique/primary key
constraint on a.i.
I see. That's more
I'm getting the following in the server log:
2005-03-27 06:04:21 GMT estat DETAIL: Process 20928 waits for ShareLock
on transaction 7751823; blocked by process 20929.
Process 20929 waits for ShareLock on transaction 7768115;
blocked by process 20928.
2005-03-27 06:04:21 GMT estat
33 matches
Mail list logo
