Re: [BUGS] BUG #5952: SetRWConflict assertion failure
On Sun, Mar 27, 2011 at 3:18 PM, Kevin Grittner wrote: > "YAMAMOTO Takashi" wrote: > >> Description: SetRWConflict assertion failure > >> SerializableXactHashLock relocking in CheckTargetForConflictsIn() >> seems racy to me. > > You're right. The attached patch should fix the assertion you hit. This patch looks reasonable, but I'm a bit concerned about the chunk immediately preceding the patched area. When we do this: LWLockRelease(SerializableXactHashLock); LWLockRelease(partitionLock); LWLockRelease(SerializablePredicateLockListLock); LWLockAcquire(partitionLock, LW_SHARED); LWLockAcquire(SerializableXactHashLock, LW_SHARED); Don't we need to also reset nextpredlock to the head of the list? I'm assuming it's the partitionLock that's keeping the PREDICATELOCKs from bouncing out from under us, so if we release it, aren't we potentially point off into thin air? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5952: SetRWConflict assertion failure
Robert Haas wrote: > This patch looks reasonable, but I'm a bit concerned about the > chunk immediately preceding the patched area. > > When we do this: > > LWLockRelease(SerializableXactHashLock); > LWLockRelease(partitionLock); > LWLockRelease(SerializablePredicateLockListLock); > LWLockAcquire(partitionLock, LW_SHARED); > LWLockAcquire(SerializableXactHashLock, LW_SHARED); > > Don't we need to also reset nextpredlock to the head of the list? > I'm assuming it's the partitionLock that's keeping the > PREDICATELOCKs from bouncing out from under us, so if we release > it, aren't we potentially point off into thin air? I think you are right. That sequence should be followed by a copy of the same "nextpredlock = " statement that's just above. Do you want me to revise the patch or do you just want to take care of it as part of the commit? Thanks for catching that. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5952: SetRWConflict assertion failure
On Tue, Apr 5, 2011 at 11:18 AM, Kevin Grittner wrote: > Robert Haas wrote: >> This patch looks reasonable, but I'm a bit concerned about the >> chunk immediately preceding the patched area. >> >> When we do this: >> >> LWLockRelease(SerializableXactHashLock); >> LWLockRelease(partitionLock); >> LWLockRelease(SerializablePredicateLockListLock); >> LWLockAcquire(partitionLock, LW_SHARED); >> LWLockAcquire(SerializableXactHashLock, LW_SHARED); >> >> Don't we need to also reset nextpredlock to the head of the list? >> I'm assuming it's the partitionLock that's keeping the >> PREDICATELOCKs from bouncing out from under us, so if we release >> it, aren't we potentially point off into thin air? > > I think you are right. That sequence should be followed by a copy > of the same "nextpredlock = " statement that's just above. Do you > want me to revise the patch or do you just want to take care of it > as part of the commit? > > Thanks for catching that. If you could send a revised patch, that would be great. I don't want to muck it up by accident. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5952: SetRWConflict assertion failure
Robert Haas wrote:
> If you could send a revised patch, that would be great.
Attached. I put it in the same spot relative to the lock
acquisition that was used earlier in the function.
-Kevin
*** a/src/backend/storage/lmgr/predicate.c
--- b/src/backend/storage/lmgr/predicate.c
***
*** 3757,3762 CheckTargetForConflictsIn(PREDICATELOCKTARGETTAG *targettag)
--- 3757,3774
LWLockRelease(partitionLock);
LWLockRelease(SerializablePredicateLockListLock);
LWLockAcquire(partitionLock, LW_SHARED);
+
+ /*
+* The list may have been altered by
another process
+* while we weren't holding the
partition lock. Start
+* over at the front.
+*/
+ LWLockAcquire(partitionLock, LW_SHARED);
+ nextpredlock = (PREDICATELOCK *)
+
SHMQueueNext(&(target->predicateLocks),
+
&(target->predicateLocks),
+
offsetof(PREDICATELOCK, targetLink));
+
LWLockAcquire(SerializableXactHashLock,
LW_SHARED);
}
}
***
*** 3770,3776 CheckTargetForConflictsIn(PREDICATELOCKTARGETTAG *targettag)
LWLockRelease(SerializableXactHashLock);
LWLockAcquire(SerializableXactHashLock, LW_EXCLUSIVE);
! FlagRWConflict(sxact, (SERIALIZABLEXACT *)
MySerializableXact);
LWLockRelease(SerializableXactHashLock);
LWLockAcquire(SerializableXactHashLock, LW_SHARED);
--- 3782,3800
LWLockRelease(SerializableXactHashLock);
LWLockAcquire(SerializableXactHashLock, LW_EXCLUSIVE);
! /*
!* Re-check after getting exclusive lock because the
other
!* transaction may have flagged a conflict.
!*/
! if (!SxactIsRolledBack(sxact)
! && (!SxactIsCommitted(sxact)
! ||
TransactionIdPrecedes(GetTransactionSnapshot()->xmin,
!
sxact->finishedBefore))
! && !RWConflictExists(sxact,
!
(SERIALIZABLEXACT *) MySerializableXact))
! {
! FlagRWConflict(sxact, (SERIALIZABLEXACT *)
MySerializableXact);
! }
LWLockRelease(SerializableXactHashLock);
LWLockAcquire(SerializableXactHashLock, LW_SHARED);
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5960: No rule to make target 'libpq.a', needed by 'all-static-lib'
On Wed, Mar 30, 2011 at 9:54 AM, Julia Jacobson wrote: > When trying to compile PostgreSQL 8.4.6 on Windows 7 using MSys (MinGW) in > order to build a static version of libpq by the commands > ./configure --without-zlib --disable-shared > make > the compilation process ends with the error message > "No rule to make target 'libpq.a', needed by 'all-static-lib'". > This issue was already discussed here on the mailing list more than 6 years > ago and successfully fixed with a patch: > http://archives.postgresql.org/pgsql-hackers-win32/2004-10/msg00057.php > However, it seems to me like there is a similar problem in version 8.4.x. > Please corrected me if I'm wrong. I tried this on MacOS X and got a different error: make -C interfaces all make -C libpq all make[3]: *** No rule to make target `libpq.5.4.dylib', needed by `all-shared-lib'. Stop. make[2]: *** [all-libpq-recurse] Error 2 make[1]: *** [all-interfaces-recurse] Error 2 make: *** [all-src-recurse] Error 2 I also tried it on Linux (Fedora 12), where it completed successfully. Unfortunately, I don't think we have any buildfarm coverage of --disable-shared, so there is no automatic way for us to notice when this has gotten broken. The problem appears to be that the all-shared-lib target in src/Makefile.shlib depends on $(shlib). The first two, generic assignments to that variable are protected like this: ifeq ($(enable_shared), yes) shlib = $(NAME)$(DLSUFFIX) endif But the remaining, platform-specific ones are not. So my guess is this will work on any platform that uses the default value for shlib, and fail on any platform that has a platform-specific override, namely: aix, darwin, freebsd, hpux, irix, cygwin, win32. Can you see whether the following patch fixes it for you? It seems to work on MacOS X, but I don't have a mingw environment handy. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company disable-shared.patch Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5952: SetRWConflict assertion failure
I wrote:
> Robert Haas wrote:
>
>> If you could send a revised patch, that would be great.
>
> Attached. I put it in the same spot relative to the lock
> acquisition that was used earlier in the function.
And version 3 which might actually work. [sigh]
-Kevin
*** a/src/backend/storage/lmgr/predicate.c
--- b/src/backend/storage/lmgr/predicate.c
***
*** 3757,3762 CheckTargetForConflictsIn(PREDICATELOCKTARGETTAG *targettag)
--- 3757,3773
LWLockRelease(partitionLock);
LWLockRelease(SerializablePredicateLockListLock);
LWLockAcquire(partitionLock, LW_SHARED);
+
+ /*
+* The list may have been altered by
another process
+* while we weren't holding the
partition lock. Start
+* over at the front.
+*/
+ nextpredlock = (PREDICATELOCK *)
+
SHMQueueNext(&(target->predicateLocks),
+
&(target->predicateLocks),
+
offsetof(PREDICATELOCK, targetLink));
+
LWLockAcquire(SerializableXactHashLock,
LW_SHARED);
}
}
***
*** 3770,3776 CheckTargetForConflictsIn(PREDICATELOCKTARGETTAG *targettag)
LWLockRelease(SerializableXactHashLock);
LWLockAcquire(SerializableXactHashLock, LW_EXCLUSIVE);
! FlagRWConflict(sxact, (SERIALIZABLEXACT *)
MySerializableXact);
LWLockRelease(SerializableXactHashLock);
LWLockAcquire(SerializableXactHashLock, LW_SHARED);
--- 3781,3799
LWLockRelease(SerializableXactHashLock);
LWLockAcquire(SerializableXactHashLock, LW_EXCLUSIVE);
! /*
!* Re-check after getting exclusive lock because the
other
!* transaction may have flagged a conflict.
!*/
! if (!SxactIsRolledBack(sxact)
! && (!SxactIsCommitted(sxact)
! ||
TransactionIdPrecedes(GetTransactionSnapshot()->xmin,
!
sxact->finishedBefore))
! && !RWConflictExists(sxact,
!
(SERIALIZABLEXACT *) MySerializableXact))
! {
! FlagRWConflict(sxact, (SERIALIZABLEXACT *)
MySerializableXact);
! }
LWLockRelease(SerializableXactHashLock);
LWLockAcquire(SerializableXactHashLock, LW_SHARED);
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5952: SetRWConflict assertion failure
On Tue, Apr 5, 2011 at 12:13 PM, Kevin Grittner wrote: > I wrote: >> Robert Haas wrote: >> >>> If you could send a revised patch, that would be great. >> >> Attached. I put it in the same spot relative to the lock >> acquisition that was used earlier in the function. > > And version 3 which might actually work. [sigh] Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5963: make -j4 check fails
> The following bug has been logged online: > > Bug reference: 5963 > Logged by: Gavin Flower > Email address: gavin(dot)flower(at)archidevsys(dot)co(dot)nz > PostgreSQL version: 9.1alpha5 > Operating system: x86_64 Linux > Description:make -j4 check fails > Details: > > After executing > time -j4 make > I went to initiate the testing (note: I deleted the directory, re-extracted > and repeated the compile for each of the following options): > > executing >time make check > works (All 126 tests passed) > > but executing >time make -j4 check > fails (I don't see any obvious problem in the log file): > [...] > == creating temporary installation== > > pg_regress: installation failed > Examine > /home/gavin/AAA/updates/postgresql/postgresql-9.1alpha5/src/test/regress/log > /install.log for the reason. > Command was: "make" -C "../../.." > DESTDIR="/home/gavin/AAA/updates/postgresql/postgresql-9.1alpha5/src/test/re > gress/./tmp_check/install" install > > "/home/gavin/AAA/updates/postgresql/postgresql-9.1alpha5/src/test/regress/lo > g/install.log" 2>&1 > make[2]: *** [check] Error 2 > make[2]: Leaving directory > `/home/gavin/AAA/updates/postgresql/postgresql-9.1alpha5/src/test/regress' > make[1]: *** [check] Error 2 > make[1]: Leaving directory > `/home/gavin/AAA/updates/postgresql/postgresql-9.1alpha5/src/test' > make: *** [check] Error 2 > > real 0m3.253s > user 0m1.666s > sys 0m1.141s I did some bisecting, and it appears the problem was introduced in the commit "Improved parallel make support" on November 12, 2010. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
