Re: Thousands of semops for every i/o

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Thousands of semops for every i/o
Date: 2003-06-23 05:59:04
Message-ID: 200306230559.h5N5x4H04174@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-patches


Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Jeffrey W. Baker wrote:
> On Mon, 2003-06-09 at 23:08, Tom Lane wrote:
> > "Jeffrey W. Baker" <jwbaker(at)acm(dot)org> writes:
> > > This is the strace of a process which is deleting rows from four tables,
> > > inside a transaction, one row at a time. There are a lot of semops for
> > > every i/o. There are about 30 connections to this database currently.
> > > I thought deletes in a transaction just flew along in Pg, because they
> > > simply wrote the deleted transaction ID on the record. It used to work
> > > fine in my previous locally-built 7.2 on Debian, but this is 7.2.2 on
> > > SuSE Enterprise Server 8.2.
> >
> > The first thing that comes to mind is that the thing is using SysV
> > semaphores as a substitute for spinlocks. If this is on a hardware
> > platform that is supposed to have TAS() support in s_lock.h or s_lock.c,
> > then it's a configuration or build error. If it's on some heretofore
> > unknown platform, you need to write some TAS() code to get decent
> > performance.
>
> It looks like a simple change in s_lock.h from
>
> #if defined(__i386__)
>
> to
>
> #if defined(__i386__) || defined(__x86_64__)
>
> Will be necessary for this platform.
>
> Thanks,
> jwb
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joel Rees 2003-06-23 06:28:46 Re: A creepy story about dates. How to prevent it?
Previous Message Christopher Kings-Lynne 2003-06-23 05:54:07 Re: [GENERAL] interesting PHP/MySQL thread

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2003-06-23 06:09:10 Re: [HACKERS] MARKED_FOR_UPDATE && XMAX_COMMITTED == XMAX_INVALID ?
Previous Message Bruce Momjian 2003-06-23 05:22:40 Re: UPDATE ... SET <col> = DEFAULT