[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
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] (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'));
CREAT
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 h
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 m
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 you
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
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
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 do
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
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
structur
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 a
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
s
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 o
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 li
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
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 ...
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 o
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 spil
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 sp
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 wo
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 a
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
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
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
>> desi
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 partia
"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
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 workarou
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 S
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 c
"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 th
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 77
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 CONTEXT:
33 matches
Mail list logo
