Re: [CYGWIN] resource leak in 7.2

I'm attaching two sql scripts in a zip file. Run script1.sql from one
session. After it's done with the inserts, start script2.sql in another
session. Have task manager running in the background and watch the
backends eat handles.

If these don't run long enough, cut and paste some more updates to the
end.

One running by itself doesn't seem to be a problem. Two or more running
together cause a problem. Also, two interactive sessions updating the
same table don't appear to cause a problem. It only appears to be a
problem when two or more sessions hit the table with an update
simultaneously.

-----Original Message-----
From: Jason Tishler [mailto:jason(at)tishler(dot)net]
Sent: Tuesday, February 05, 2002 3:03 PM
To: Tom Lane
Cc: Tom Pfau; pgsql-bugs(at)postgresql(dot)org; pgsql-cygwin(at)postgresql(dot)org
Subject: Re: [CYGWIN] [BUGS] resource leak in 7.2

On Tue, Feb 05, 2002 at 01:07:18PM -0500, Tom Lane wrote:
> "Tom Pfau" <T(dot)Pfau(at)emCrit(dot)com> writes:
> > In any case, if I run my test procedure which just performs updates
to a
> > random column of a random row of a 1000 row table, I can watch the
> > handle usage continue to rise on the backend process.
> > Looking a bit more closely now, a single process doesn't seem to
cause a
> > problem. Running two or more copies simultaneously causes the
backends
> > to continuously consume handles. If I stop one of the processes,
the
> > other stops losing handles.
>
> Unsurprisingly, I don't see any such problem under Unix (HPUX to be
> specific, but I'd be astonished to see PG on any Unix do that,
> considering that each backend manages its open files independently).
>
> I think you must be looking at some misbehavior of the Cygwin layer.
> If the problem really did go away in 7.1.3, perhaps some fix was
applied
> by the Cygwin packager and not contributed back to the main code base.

I only include patches to the standard Cygwin PostgreSQL distribution
that have been accepted into CVS. [1] I'm too lazy to maintain private
patches for the long haul... :,) So, whatever is in Cygwin PostgreSQL
7.1.3 should be in 7.2.

[1] To be more precise, there are one or two instances where the version
of the patch in CVS was later tweaked for other platforms, but I
continued
to use the initial version.

> But it's got to be a Cygwin bug anyway; the most we could do is find
> some workaround to avoid triggering it.

Without any investigation, I would tend to agree with the above. Tom
(Pfau), please try to find a minimal test for submission to the Cygwin
mailing list.

Thanks,
Jason