[HACKERS] WARNING: pgstat wait timeout
While doing some pgbench testing on a new server with 9.1.1, I noticed quite a lot of $subject in the logs. I did some Googling and found this previous thread: http://archives.postgresql.org/pgsql-hackers/2010-01/msg02897.php It doesn't seem like the issue was resolved? I did: # pgbench -i -s 1000 bench1 # pgbench -c 8 -j 4 -T 1000 bench1 The server is: PostgreSQL 9.1.1 Ubuntu 10.04 2.6.32-35-generic #78-Ubuntu SMP x86_64 Quad Core Xeon, 22GB RAM, 2x SATA RAID1 The warning seems to come in average 3-4 times a minute: 2011-12-03 23:07:31 CET::@:[13728]: WARNING: pgstat wait timeout 2011-12-03 23:07:37 CET::@:[13728]: WARNING: pgstat wait timeout 2011-12-03 23:07:47 CET::@:[13556]: WARNING: pgstat wait timeout 2011-12-03 23:07:52 CET::@:[13729]: WARNING: pgstat wait timeout Some non-default postgresql.conf settings: shared_buffers = 6GB effective_cache_size = 12GB work_mem = 16MB synchronous_commit = off checkpoint_segments = 16 checkpoint_completion_target = 0.9 autovacuum_max_workers = 6 Is this a bug, something wrong with my setup, or simply harmless noise (although annoying in that case)? Regards, -- a. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Bug: citext not working in non-public schema
Researching a nasty bug discovered in our application led me to this bug report and its follow-ups: http://archives.postgresql.org/pgsql-bugs/2010-03/msg00058.php This bit us hard (on PostgreSQL 8.4.4). We have a custom domain for email addresses based on citext, placed in the public schema, while each user of our application has their own private schemas. The search path is set to their private schemas, and the few queries which required explicit access to the type prefixes the type with the public schema, i.e. WHERE 't...@example.com'::public.email = email_column. This *seems* to work, in that no error or warning is thrown, but comparisons are simply silently wrong. This led to a nasty bug in our application as it broke our expectation that the database should enforce this case-insensitive checks. Any possibility of getting this fixed? Obliviously I would prefer citext to work as advertised across schemas. If not, an out-right error thrown would be much better and consistent than the current situation. Regards, -- anders -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Show schema size with \dn+
Is there any interest in expanding \dn+ to show schema size, similar to table sizes using \dt+ in 8.4? We use separate schemas for each user, so this would allow us to quickly look up the sizes of each user's data. I have little experience with C and none with the PostgreSQL code base -- where should I look to have a go at this? -- a. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New CRC algorithm: Slicing by 8
On Mon, 23 Oct 2006 07:35:08 +0200, Tom Lane <[EMAIL PROTECTED]> wrote: I realize I forgot to document what I was using: HPPA: gcc version 2.95.3 20010315 (release) PPC: gcc version 4.0.1 (Apple Computer, Inc. build 5363) both Intels: gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) Interesting that it's only the oldest-line tech that's showing a win for me ... Does anyone have an Intel compiler availible? It would be interesting to see results on that compared to gcc (given that it is an Intel algorithm ;). \Anders ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
