Re: [HACKERS] stuck spin lock with many concurrent users

2001-06-21 Thread Tatsuo Ishii
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 actually stuck, or just

[HACKERS] Re: nocreatetable for 7.1.2

2001-06-21 Thread Karel Zak
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 with

Re: [HACKERS] stuck spin lock with many concurrent users

2001-06-21 Thread Tom Lane
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

[HACKERS] [PATCH] Re: Setuid functions

2001-06-21 Thread Mark Volpe
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 break

Re: [HACKERS] COPY vs. INSERT

2001-06-21 Thread Tom Lane
[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 only

RE: [HACKERS] RE: [BUGS] Update is not atomic

2001-06-21 Thread Mikheev, Vadim
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 occure -

[HACKERS] Re: [GENERAL] Call for alpha testing: planner statistics revisions

2001-06-21 Thread Tom Lane
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 VACUUMs?

Re: [HACKERS] COPY vs. INSERT

2001-06-21 Thread Tom Lane
[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 =

[HACKERS] Good name for new lock type for VACUUM?

2001-06-21 Thread Tom Lane
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

RE: [HACKERS] Good name for new lock type for VACUUM?

2001-06-21 Thread Mikheev, Vadim
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:

[HACKERS] Re: Good name for new lock type for VACUUM?

2001-06-21 Thread Thomas Swan
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

Re: [HACKERS] Re: Good name for new lock type for VACUUM?

2001-06-21 Thread Tom Lane
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

Re: [HACKERS] stuck spin lock with many concurrent users

2001-06-21 Thread Tatsuo Ishii
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 before

Re: [HACKERS] stuck spin lock with many concurrent users

2001-06-21 Thread Tom Lane
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 spinlock).

Re: [HACKERS] stuck spin lock with many concurrent users

2001-06-21 Thread Tatsuo Ishii
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