Re: [BUGS] pg_listener entries deleted under heavy NOTIFY load only on Windows
Marshall, Steve wrote: > What's the timing of the errors? Is there a chance that we are sending > the kill signal before the signal handling thread has actually started > *and created the named pipe*? > > We set up the signal handling stuff pretty early, but we do seem to let > the postmaster continue it's work before it's up... > > Under heavy load, a signal will typically be dropped within the first > few minutes. However, it can sometimes take a little while before the > problem happens. Thousands of the same signal to the same process may > be properly handled before one is mishandled. This is not consistant > with a problem with initial creation of the pipe. > > Going back to your tests, did it ever require more than one retry? > > Yes, but rarely. In a 90 hour stress test with code that allowed up to 5 > calls to CallNamedPipe, I found 760 signals that required a retry. Only > one required two retries. That is why I set the number of retries to 2. > The behavior might be different if the sleep interval between retries > was changed. I used a 20 ms sleep interval between retries in all my > tests, and in the patch I sent. I have applied a modified version (no functional changes, just stylistic) of this patch to head and backpatched to 8.2 which is as far back as we support win32. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4657: mod() makes a mistake in calculation in v8.3
The following bug has been logged online: Bug reference: 4657 Logged by: Fujii Masao Email address: masao.fu...@gmail.com PostgreSQL version: 8.3.6 on x86_64 Operating system: Red Hat Enterprise Linux Server release 5.1 (Tikanga) Description:mod() makes a mistake in calculation in v8.3 Details: In 8.3, I found the bug of 'mod' function to make an error in calculation when the second argument is defined as 'numeric'. postgres=# SELECT version(); version --- PostgreSQL 8.3.6 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14) (1 row) postgres=# SELECT mod(7, 35); mod - 0 (1 row) postgres=# SELECT mod(7.0, 35.0); mod -- 35.0 (1 row) On the other hand, in HEAD, mod() seems to work fine. postgres=# SELECT version(); version -- PostgreSQL 8.4devel on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14), 64-bit (1 row) postgres=# SELECT mod(7, 35); mod - 0 (1 row) postgres=# SELECT mod(7.0, 35.0); mod - 0.0 (1 row) I guess the following change fixed the bug which I found. Right? Why don't we backport this? http://archives.postgresql.org/pgsql-committers/2008-04/msg00030.php Regards, -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
