> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >>> How can I check it?
> >>
> >> The 'stuck' message should at least give you a code location...
>
> > FATAL: s_lock(0x2ac2d016) at spin.c:158, stuck spinlock. Aborting.
>
> Hmm, that's SpinAcquire, so it's one of the predefined spinlocks
> (and not
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>>> How can I check it?
>>
>> The 'stuck' message should at least give you a code location...
> FATAL: s_lock(0x2ac2d016) at spin.c:158, stuck spinlock. Aborting.
Hmm, that's SpinAcquire, so it's one of the predefined spinlocks
(and not, say, a buffer sp
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> If it is stuck, on which lock(s)?
>
> > How can I check it?
>
> The 'stuck' message should at least give you a code location...
Here is the actual message:
FATAL: s_lock(0x2ac2d016) at spin.c:158, stuck spinlock. Aborting.
Last several queries b
Thomas Swan <[EMAIL PROTECTED]> writes:
> I think that type of lock would best be kept to the system level.
Why?
I don't have a scenario offhand where it'd be useful, but if we've
discovered it's useful for VACUUM then there may be cases where a lock
with these properties would be useful to us
Tom Lane wrote:
>Awhile ago I said that I wanted to create a new flavor of table-level
>lock for concurrent VACUUM to get on a table. RowExclusiveLock is
>not the right thing because it is not self-exclusive, whereas we don't
>want more than one VACUUM mangling a table at a time. But anything
>
> Any better ideas out there?
Names were always hard for me -:)
> Where did the existing lock type names
> come from, anyway? (Not SQL92 or SQL99, for sure.)
Oracle. Except for Access Exclusive/Share Locks.
Vadim
---(end of broadcast)---
TIP 6:
Awhile ago I said that I wanted to create a new flavor of table-level
lock for concurrent VACUUM to get on a table. RowExclusiveLock is
not the right thing because it is not self-exclusive, whereas we don't
want more than one VACUUM mangling a table at a time. But anything
higher locks out concu
[EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
>> Obviously it isn't. Care to show us the code?
> Sure. ftp://ftp.vex.net/pub/glaccount.
PG_FUNCTION_INFO_V1(glaccount_cmp);
Datum
glaccount_cmp(PG_FUNCTION_ARGS)
{
glaccount *a1 = (glaccount *) PG_GETARG_POINTER(0);
glaccount *a2
Ed Loehr <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> * ANALYZE is now available as a separate command; you can run it without
>> also doing a VACUUM. (Of course, VACUUM ANALYZE still works.)
> What is the impact of this newly isolated ANALYZE command on the need
> and/or frequency for VACUU
> > Incrementing comand counter is not enough - dirty reads are required
> > to handle concurrent PK updates.
>
> What's that with you and dirty reads? Every so often you tell
> me that something would require them - you really like to
> read dirty things - no? :-)
Dirty things o
[EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
> I followed the instructions on interfacing user defined types as per
> http://www.ca.postgresql.org/devel-corner/docs/programmer/xindex.html.
> In fact I helped write that page so I am pretty sure I got it right.
> This code worked fine before. The o
Sorry, I have decided not to follow the SQL standard ;-) PRIVILEGE is spelled
correctly in my patch.
This patch will implement the "ENABLE PRIVILEGE" and "DISABLE PRIVILEGE"
commands in PL/pgSQL, which, respectively, change the effective uid to that
of the function owner and back. It doesn't br
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> If it is stuck, on which lock(s)?
> How can I check it?
The 'stuck' message should at least give you a code location...
regards, tom lane
---(end of broadcast)---
TIP 6: Have you
On Thu, Jun 21, 2001 at 01:39:38PM +0200, RISKO Gergely wrote:
> Hello!
>
> I saaw your patch for 7.0.2, but it is hard to port to 7.1.2 for me,
> because I haven't got any knowlendge in postgresql programming.
> Can you give me a nocreatetable patch for postgres 7.1.2?
I'd like, but I unsure w
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I have seen problems with extremely many concurrent users.
> > I run pgbench:
>
> > pgbench -c 1000 -t 1 test
>
> > And I get stuck spin lock errors. This is 100% reproducable (i.e. I
> > have nerver succeeded in pgbench -c 1000).
>
> Is it actuall
15 matches
Mail list logo
