SEO

Folks, my mailbox is filling with unresolved Win32 bug reports,
specifically:

integer division
shared memory
statistics collector
rename
fsync

I have put the emails at the bottom of the patches_hold queue:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Here's one to add to the list: running pgbench with a moderately heavy
load on an SMP box likes to trigger a state where the database (or
pgbench) just stops doing work (CPU usage drops to nothing, as does disk
activity). I've been able to repro this on 2 Intel boxes (one a 2 way,
one a 4 way), and a dual Opteron, all running the latest windows binary.
A 50 connection test running 1000 transactions is pretty much ensured to
fail.

I've been unable to produce the same behavior on a single-proc machine.

Please let me know if there's any more info that would be helpful.

On Thu, Apr 20, 2006 at 07:02:01AM -0400, Bruce Momjian wrote:
> Folks, my mailbox is filling with unresolved Win32 bug reports,
> specifically:
>
> integer division
> shared memory
> statistics collector
> rename
> fsync
>
> I have put the emails at the bottom of the patches_hold queue:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> --
> Bruce Momjian http://candle.pha.pa.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Thu, Apr 20, 2006 at 12:17:07PM -0500, Jim C. Nasby wrote:
> Here's one to add to the list: running pgbench with a moderately heavy
> load on an SMP box likes to trigger a state where the database (or
> pgbench) just stops doing work (CPU usage drops to nothing, as does disk
> activity). I've been able to repro this on 2 Intel boxes (one a 2 way,
> one a 4 way), and a dual Opteron, all running the latest windows binary.
> A 50 connection test running 1000 transactions is pretty much ensured to
> fail.

Well, this sounds like a dead-lock, the obvious step would be to
attached gdb to both and get a stack-trace...
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFER8P6IB7bNG8LQkwRAiPCAJ9F8CXMyXQxCLUdbgpJ/NtLqdzLjwCfQRNJ
1xBCAenYjbz7BbcSk1OsZG0=
=B96x
-----END PGP SIGNATURE-----

On Thu, Apr 20, 2006 at 07:25:15PM +0200, Martijn van Oosterhout wrote:
> On Thu, Apr 20, 2006 at 12:17:07PM -0500, Jim C. Nasby wrote:
> > Here's one to add to the list: running pgbench with a moderately heavy
> > load on an SMP box likes to trigger a state where the database (or
> > pgbench) just stops doing work (CPU usage drops to nothing, as does disk
> > activity). I've been able to repro this on 2 Intel boxes (one a 2 way,
> > one a 4 way), and a dual Opteron, all running the latest windows binary.
> > A 50 connection test running 1000 transactions is pretty much ensured to
> > fail.
>
> Well, this sounds like a dead-lock, the obvious step would be to
> attached gdb to both and get a stack-trace...

Any pointers on how to get that setup? IS gdb part of the mingw runtime?

BTW, this appears to be readily reproducable, so it might be a lot more
productive for one of the windows hackers to test this themselves...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Martijn van Oosterhout <kleptog@svana.org> writes:
> On Thu, Apr 20, 2006 at 12:17:07PM -0500, Jim C. Nasby wrote:
>> Here's one to add to the list: running pgbench with a moderately heavy
>> load on an SMP box likes to trigger a state where the database (or
>> pgbench) just stops doing work (CPU usage drops to nothing, as does disk
>> activity).

> Well, this sounds like a dead-lock, the obvious step would be to
> attached gdb to both and get a stack-trace...

Yeah, I wonder if it's related to that apparent bug Qingqing saw in the
windows semaphore code? It's clearly windows-specific since no one's
ever reported any such thing on Unixen.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Bruce Momjian said:
> Folks, my mailbox is filling with unresolved Win32 bug reports,
> specifically:
>
> integer division
> shared memory
> statistics collector
> rename
> fsync
>
> I have put the emails at the bottom of the patches_hold queue:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>

There's also a pg_config buglet that David Fetter found that still needs to
be fixed.

I am currently travelling on family business, but when I return home in a
couple of weeks will be working on getting my new machine built, and
installing a permanent Windows VM (among others), which will make it easier
for me to look at Windows issues within my realm of competence.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"Tom Lane" <tgl@sss.pgh.pa.us> wrote
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > On Thu, Apr 20, 2006 at 12:17:07PM -0500, Jim C. Nasby wrote:
> >> Here's one to add to the list: running pgbench with a moderately heavy
> >> load on an SMP box likes to trigger a state where the database (or
> >> pgbench) just stops doing work (CPU usage drops to nothing, as does
disk
> >> activity).
>
> > Well, this sounds like a dead-lock, the obvious step would be to
> > attached gdb to both and get a stack-trace...
>
> Yeah, I wonder if it's related to that apparent bug Qingqing saw in the
> windows semaphore code? It's clearly windows-specific since no one's
> ever reported any such thing on Unixen.
>

I also suspect the EAGAIN error reports are related to the semaphore code.
So if possible, I suggest we patch the code and test it.

Regards,
Qingqing

On Mon, Apr 24, 2006 at 10:23:07AM +0800, Qingqing Zhou wrote:
>
> "Tom Lane" <tgl@sss.pgh.pa.us> wrote
> > Martijn van Oosterhout <kleptog@svana.org> writes:
> > > On Thu, Apr 20, 2006 at 12:17:07PM -0500, Jim C. Nasby wrote:
> > >> Here's one to add to the list: running pgbench with a moderately heavy
> > >> load on an SMP box likes to trigger a state where the database (or
> > >> pgbench) just stops doing work (CPU usage drops to nothing, as does
> disk
> > >> activity).
> >
> > > Well, this sounds like a dead-lock, the obvious step would be to
> > > attached gdb to both and get a stack-trace...
> >
> > Yeah, I wonder if it's related to that apparent bug Qingqing saw in the
> > windows semaphore code? It's clearly windows-specific since no one's
> > ever reported any such thing on Unixen.
> >
>
> I also suspect the EAGAIN error reports are related to the semaphore code.
> So if possible, I suggest we patch the code and test it.

There a patched build available for testing? (I'd rather not have to
figure out how to get windows builds working, unless there's some kind
of instructions somewhere...)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

""Jim C. Nasby"" <jnasby@pervasive.com> wrote
>
> There a patched build available for testing? (I'd rather not have to
> figure out how to get windows builds working, unless there's some kind
> of instructions somewhere...)
> --

Not yet - the patch is still pending.

Regards,
Qingqing