Try setting the variable lc_collate, either in an individual session
using SET or (to change it for all session) in postgresql.conf.
Craig Ringer wrote:
CK Leung wrote:
I create a new database use UTF-8 and SQL_ASCII, same result found, how
can i fix this problem ?
If
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...
Bruce Momjian wrote:
Uh, no file attachment.
I attached the patch file to my Feb 3 post, but I'll attach it again.
---
Marshall, Steve wrote:
Any thoughts on whether or not this patch shou
Any thoughts on whether or not this patch should be included in a future
PostgreSQL release? If so, any thoughts on additional testing, etc,
that needs to be done? Should the patch be added to a minor release of
8.3, or only included forward in 8.4? In my opinion, this is a pretty
serious error
I've completed my test for changes to the Windows implementation of
pgkill. I ran two clients constantly doing a pair of notifications,
with one client subscribing to those events. I ran the test for 90
hours. I found 760 cases where the CallNamedPipe function initially
failed, but succeeded
Tom Lane wrote:
So my opinion is that the real issue here is why is the kill()
implementation failing when it should not. We need to fix that,
not put band-aids in async.c.
I think Tom makes a valid point. To that end, I think the Window's kill
implementation needs to be changed to have th
s on this or other possible solutions?
Steve
Marshall, Steve wrote:
As I posted before, changing the timeout from 1000 to
NMPWAIT_WAIT_FOREVER fixed the problem, or at least moved it such it
does not occur easily anymore.
To better understand the problem, I added debugging as Tom suggested.
uot;). I'm open to ideas on how to dig further.
Steve
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Wednesday, January 28, 2009 12:44 PM
To: Marshall, Steve
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] pg_listener entries deleted under heavy NOTIFY load
onl
:
> Marshall, Steve wrote:
>> Any thoughts on how to confirm or deny Theory A?
> Try changing the 1000 to NMPWAIT_WAIT_FOREVER
As long as you're changing the source code, it'd be a good idea to
verify the supposition that kill() is failing, eg in
src/ba
Marshall, Steve wrote:
Any thoughts on how to confirm or deny Theory A?
Alvaro Herrera wrote:
Try changing the 1000 to NMPWAIT_WAIT_FOREVER
I'd tried Alvaro suggestion and it fixed the problem in my test case.
With the original code, the test would consist
Tome Lane wrote:
Theory B is that you've got some broken antivirus code on there that is
arbitrarily interfering with the pipe access. The lack of any similar
previous reports suggests that there's some local issue contributing ,,,
Steve Marshall wrote:
To explore Theory B, I'll turned off all no
"Marshall, Steve" writes:
> Under a heavy load of NOTIFY events, entries in the pg_listener table
> for some events are deleted, effectively acting as though UNLISTEN
> were called.
> I have only been able to make this occur on a PostgreSQL server
> running on
Under a heavy load of NOTIFY events, entries in the pg_listener table
for some events are deleted, effectively acting as though UNLISTEN were
called.
I have only been able to make this occur on a PostgreSQL server running
on Windows. I cannot reproduce under Linux.
PostgreSQL version: 8.3.4
PostgreSQL 8.3 added a new optimization to avoid sorting in queries that
use ORDER BY ... LIMIT. This optimization does not work when the query
is issued to a parent table with several children, such as a partitioned
table.
PostgreSQL version: 8.3.1
Operating System:RedHat Enterprise Li
This has already been posted to pgsql-patches, but perhaps it belongs
better here...
There is a problem in PL/TCL that can cause the postgres backend to
become multithreaded. Postgres is not designed to be multithreaded, so
this causes downstream errors in signal handling. We have seen this
cau
Peter,
I don't know if this is directly related to your problem, but the
version of dbd_db_pg_notifies you are using has a memory leak in it.
The memory leak causes a small amount of memory to be leaked every time
pg_notifies is called from your perl code. This memory leak affected
several
16 matches
Mail list logo
