Re: table level locking different in 7.0?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jim Mercer <jim(at)reptiles(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: table level locking different in 7.0?
Date: 2000-05-18 02:31:51
Message-ID: 200005180231.WAA23619@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > Jim Mercer <jim(at)reptiles(dot)org> writes:
> >> i had several concurrent processes which would do inserts via COPY and
> >> queries.
> >> on that system, i don't recall the COPY processes as being blocked by the
> >> query processes.
> >> now i'm running that app on solaris 7 with pgsql 7.0.
> >> i'm finding that a big long select is blocking other processes which
> >> are doing COPY's.
>
> > Hmm. In 7.0, COPY IN acquires an exclusive lock on the target table,
> > which is something I put in in a fit of paranoia. It may not really
> > be necessary --- probably a regular write lock would be good enough.
>
> OK, fix committed. Jim, if you're in a hurry for this fix, just change
> AccessExclusiveLock to RowExclusiveLock at line 289 of
> backend/commands/copy.c.

FYI, I have been telling people to grab tomorrow's snapshot from
ftp:/pub/dev if they need changes that have been applied. At this
point, we don't have any funny stuff in the cvs tree.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-05-18 02:35:33 Re: question about index cost estimates
Previous Message Bruce Momjian 2000-05-18 02:29:50 Re: table level locking different in 7.0?