[BUGS] BUG #6390: maximum data limit of Postgres.
The following bug has been logged on the website: Bug reference: 6390 Logged by: apisith Email address: r...@hotmail.com PostgreSQL version: Unsupported/Unknown Operating system: linux Description: somenon tell me postgres DB have maximum data limit 60 GB. when am search on http://www.postgresql.org am not found answer. Can i know maximum data limit of Postgres. tank you, : ) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] FreeBSD 9.0/amd64, PostgreSQL 9.1.2, pgbouncer 1.4.2: segmentation fault
Hello everybody. Today I have run into some strange situation, maybe a bug. There is a client with variable "default_transaction_isolation='serializable'" set in role properties and it connects to Postgres via pgbouncer. The problem appears after it executes several ten thousand queries, the most of them are SELECTs, any other kinds occur very seldom (of course, the tables used are heavily explored by other clients). At some point the backend with this client crashes due to segmentation fault with signal 11. GDB shows the following: #0 0x006b3a5b in SHMQueueDelete (queue=0x845b4c498) at shmqueue.c:77 77 prevElem->next = queue->next; [New Thread 8025cd400 (LWP 100635/)] [New LWP 100709] (gdb) bt #0 0x006b3a5b in SHMQueueDelete (queue=0x845b4c498) at shmqueue.c:77 #1 0x006c16ef in SummarizeOldestCommittedSxact () at predicate.c:1467 #2 0x006c197f in RegisterSerializableTransactionInt (snapshot=0xbe7480) at predicate.c:1605 #3 0x006c190a in RegisterSerializableTransaction (snapshot=0xbe7480) at predicate.c:1569 #4 0x007ffcf7 in GetTransactionSnapshot () at snapmgr.c:138 #5 0x006cbaf5 in exec_simple_query (query_string=0x80249e030 "SELECT 'DBD::Pg ping test'") at postgres.c:932 #6 0x006cfcb3 in PostgresMain (argc=2, argv=0x80249a890, username=0x80249a860 "stat") at postgres.c:3926 #7 0x0068340d in BackendRun (port=0x802448900) at postmaster.c:3601 #8 0x00682b1a in BackendStartup (port=0x802448900) at postmaster.c:3286 #9 0x0067ff5c in ServerLoop () at postmaster.c:1455 #10 0x0067f73d in PostmasterMain (argc=3, argv=0x7fffdb90) at postmaster.c:1116 #11 0x005fa67a in main (argc=3, argv=0x7fffdb90) at main.c:199 (gdb) p prevElem $1 = (SHM_QUEUE *) 0x0 The other conditions are: - FreeBSD 9.0-RELEASE / amd64 / ZFS and 12G RAM; - PostgreSQL 9.1.2 built from ports (with debug symbols); - pgbouncer 1.4.2 built from ports at the same host; /etc/sysctl.conf: kern.ipc.shmall=393216 kern.ipc.shmmax=2147483648 kern.ipc.shm_use_phys=1 /boot/loader.conf: kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256 postgresql.conf: shared_buffers = 1GB temp_buffers = 64MB max_prepared_transactions = 20 work_mem = 16MB wal_buffers = 128kB If one undefs variable "default_transaction_isolation", then the situation vanishes. So why does this thing happen? Is there a bug in Postgresql or FreeBSD? I'd be glad to produce any other meaning information. With the best regards, Andrew. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6377: some notice on the manual page
OK, but at least some notes on the technique or special small section in the manual. I was able to extract this info from the manual using this query to google just by chance when I already lost any hope https://www.google.com/search?q=postgresql+match+every+error Thanks, I. -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-6377-some-notice-on-the-manual-page-tp5119443p5133743.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] FreeBSD 9.0/amd64, PostgreSQL 9.1.2, pgbouncer 1.4.2: segmentation fault
On 10.01.2012 17:22, Andrew Alcheyev wrote: At some point the backend with this client crashes due to segmentation fault with signal 11. GDB shows the following: #0 0x006b3a5b in SHMQueueDelete (queue=0x845b4c498) at shmqueue.c:77 77 prevElem->next = queue->next; [New Thread 8025cd400 (LWP 100635/)] [New LWP 100709] (gdb) bt #0 0x006b3a5b in SHMQueueDelete (queue=0x845b4c498) at shmqueue.c:77 #1 0x006c16ef in SummarizeOldestCommittedSxact () at predicate.c:1467 #2 0x006c197f in RegisterSerializableTransactionInt (snapshot=0xbe7480) at predicate.c:1605 #3 0x006c190a in RegisterSerializableTransaction (snapshot=0xbe7480) at predicate.c:1569 #4 0x007ffcf7 in GetTransactionSnapshot () at snapmgr.c:138 #5 0x006cbaf5 in exec_simple_query (query_string=0x80249e030 "SELECT 'DBD::Pg ping test'") at postgres.c:932 #6 0x006cfcb3 in PostgresMain (argc=2, argv=0x80249a890, username=0x80249a860 "stat") at postgres.c:3926 #7 0x0068340d in BackendRun (port=0x802448900) at postmaster.c:3601 #8 0x00682b1a in BackendStartup (port=0x802448900) at postmaster.c:3286 #9 0x0067ff5c in ServerLoop () at postmaster.c:1455 #10 0x0067f73d in PostmasterMain (argc=3, argv=0x7fffdb90) at postmaster.c:1116 #11 0x005fa67a in main (argc=3, argv=0x7fffdb90) at main.c:199 (gdb) p prevElem $1 = (SHM_QUEUE *) 0x0 That clearly looks like a bug in the SSI feature, introduced in PostgreSQL 9.1. This looks superficically similar to the bug that Dan Ports spotted on Friday: http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg190135.html. If you can reproduce the issue easily, could you try the patch he posted and see if it fixes it? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6390: maximum data limit of Postgres.
r...@hotmail.com writes: > somenon tell me postgres DB have maximum data limit 60 GB. You were misinformed. There is some less untrustworthy information in this FAQ entry: http://wiki.postgresql.org/wiki/FAQ#What_is_the_maximum_size_for_a_row.2C_a_table.2C_and_a_database.3F regards, tom lane -- 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 #6393: cluster sometime fail under heavy concurrent write load
The following bug has been logged on the website: Bug reference: 6393 Logged by: Maxim Boguk Email address: maxim.bo...@gmail.com PostgreSQL version: 9.0.6 Operating system: Linux Ubuntu Description: I have heavy write-load table under PostgreSQL 9.0.6 and sometime (not always but more then 50% chance) i'm getting the next error during cluster: db=# cluster public.enqueued_mail; ERROR: duplicate key value violates unique constraint "pg_toast_119685646_index" DETAIL: Key (chunk_id, chunk_seq)=(119685590, 0) already exists. chunk_id different each time. No uncommon datatypes exists in the table. Currently I work on create reproducible test case (but it seems require 2-3 open write transaction on the table). -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
