On Thu, May 31, 2012 at 7:49 AM, Erik Rijkers <er@xs4all.nl> wrote:
> On Thu, May 31, 2012 13:14, Robert Haas wrote:
>> On Thu, May 31, 2012 at 1:06 AM, Erik Rijkers <er@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
