On Thu, May 31, 2012 at 7:49 AM, Erik Rijkers <e...@xs4all.nl> wrote: > On Thu, May 31, 2012 13:14, Robert Haas wrote: >> On Thu, May 31, 2012 at 1:06 AM, Erik Rijkers <e...@xs4all.nl> wrote: >>> In my test, I run the bash code (the bits that I posted earlier) in a while >>> loop so that the >>> table >>> is CREATEd, COPYied into, and DROPped every few seconds -- perhaps that >>> wasn't clear. That loop >>> is necessary; a few iterations are often successful. >> >> Yes... I let it run all night on my laptop with no errors. > > My apologies to both of you. It seems the problem was indeed solved with > that commit from Robert. > I managed to forget that I, uh... temporary, commented out the git-pull from > my build script...
No problem. The one thing that still seems a little odd to me is that this caused a pin count to get orphaned. It seems reasonable that ignoring the AccessExclusiveLock could result in not-found errors trying to open a missing relation, and even fsync requests on a missing relation. But I don't see why that would cause the backend-local pin counts to get messed up, which makes me wonder if there really is another bug here somewhere. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
