Thread: table level locking different in 7.0?
i used to have a database on freebsd using 6.5.3. 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. i'm also finding that other queries are blocking. the only real difference between what was running before and what is running now is the use of an ORDER BY clause in the big long select, since 7.0 seems to need this to return records in the same order as 6.5.3 (i know, i shouldhave been using the ORDER BY in 6.5.3, but, such is the way it is). is the blocking i'm seeing supposed to be happening? or did i miss some flag or something when installing on solaris? -- [ Jim Mercer jim@reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
Jim Mercer <jim@reptiles.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.
(6.5's COPY code neglected to acquire any lock at all, which is surely
*not* good enough, but maybe I overreacted.)
Comments anyone?
regards, tom lane
> 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. > (6.5's COPY code neglected to acquire any lock at all, which is surely > *not* good enough, but maybe I overreacted.) Oh, seems I forgot about COPY in 6.5... -:( ROW EXCLUSIVE lock is required (just like for INSERT, DELETE, UPDATE)... Vadim
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> ROW EXCLUSIVE lock is required (just like for INSERT, DELETE, UPDATE)...
OK, will fix (I have another little fix to make in copy.c anyway)
regards, tom lane
On Wed, May 17, 2000 at 08:41:25PM -0400, Tom Lane wrote: > "Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes: > > ROW EXCLUSIVE lock is required (just like for INSERT, DELETE, UPDATE)... > > OK, will fix (I have another little fix to make in copy.c anyway) can i get a patch relative to 7.0-release? this is effecting a production database. -- [ Jim Mercer jim@reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
> Jim Mercer <jim@reptiles.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.
regards, tom lane
> Jim Mercer <jim@reptiles.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. > (6.5's COPY code neglected to acquire any lock at all, which is surely > *not* good enough, but maybe I overreacted.) I see no reason a write lock would not be good enough, unless we do some special stuff in copy which I have forgotten. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > Jim Mercer <jim@reptiles.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@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026