Re: [BUGS] BUG #7572: virtualxid lock held by bgwriter on promoted slaves
On 27 September 2012 22:29, Simon Riggs wrote: > On 26 September 2012 22:33, wrote: >> The following bug has been logged on the website: >> >> Bug reference: 7572 >> Logged by: Daniele Varrazzo >> Email address: daniele.varra...@gmail.com >> PostgreSQL version: 9.1.4 >> Operating system: Linux >> Description: >> >> Hello, >> >> when a slave is promoted, the pgwriter keeps holding a lock with virtualxid >> "1/1" and virtualtransaction "-1/0". Such lock stops pg_reorg to run (as >> reported here: >> http://pgfoundry.org/tracker/index.php?func=detail&aid=1011203&group_id=1000411&atid=1376) >> but I've verified the same condition on 9.1.4). >> >> Is it possible to free that lock on slave promotion? >> >> Is it safe to ignore that lock for pg_reorg sake? The program is which is >> probably waiting for all the transactions to finish before swapping the >> table in the system catalog but I'm not sure about that yet. > > This one is mine I don't think its important we hold that lock, > but will check. This was an interesting bug to track down and certainly had me stumped for some time. Nothing at all todo with the WALwriter. It turns out that the Startup process never ended its VirtualTransaction, which caused 2 separate bugs in 9.0/9.1 and 9.2/HEAD. The bugs in 9.2+ were only visible because of lack of initialisation of the fp fields, also fixed. Thanks for the bug report. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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 #7713: Is it a good idea to write more?
jackie.qq.zh...@gmail.com writes: > This actually not a bug but an enhanced log message. It doesn't seem reasonable to me to try to make that message mention every single variable that affects shared memory size. If we did, it would constantly be in need of adjustment. And frankly it's too verbose already. 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 #7714: Error Message related to "sql_implementation_info" when itś not part of the query...
The following bug has been logged on the website:
Bug reference: 7714
Logged by: Cláudio Bezerra Leopoldino
Email address: claudiob...@yahoo.com.br
PostgreSQL version: 9.2.1
Operating system: Linux - Ubuntu
Description:
I dont know if its an error or an expected behavior, but it seems strange to
me.
I was testing table privilege functions and a inusual message appeared,
related to "sql_implementation_info" when itś not part of the query.
The commands to induce the mesage appear above:
postgres=# SELECT 'r1' as TABELA, has_table_privilege('postgres', 'r1',
'SELECT') AS SELECT;
tabela | select
+
r1 | t
(1 registro)
postgres=# SELECT tablename as TABELA, has_table_privilege('postgres',
tablename, 'SELECT') AS SELECT FROM pg_tables;
ERRO: relação "sql_implementation_info" não existe
postgres=# SELECT version();
version
-
PostgreSQL 9.2.1 on i686-pc-linux-gnu, compiled by gcc-4.4.real (Ubuntu
4.4.3-4ubuntu5.1) 4.4.3, 32-bit
(1 registro)
(END)
--
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 #7712: pgsql2shp should set Language Driver ID (LDID) header in .dbf
The following bug has been logged on the website: Bug reference: 7712 Logged by: François Bonzon Email address: francois.bon...@gmail.com PostgreSQL version: 9.2.1 Operating system: Ubuntu 12.04 Description: This header is an optional feature of .DBF files to specify the character encoding of its text attributes (UTF-8, CP1251, etc.). So is a .cpg sibling file, that can carry the same information, and an alternate way to store this information, that many GIS software support. The dumper tool pgsql2shp should set this header, as PostreSQL knowns what encoding it is writing to. Some popular tools (including OGR library, QGIS) are mis-interpreting the encoding of a shapefile that is missing this header. -- 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 #7713: Is it a good idea to write more?
The following bug has been logged on the website: Bug reference: 7713 Logged by: Jackie Zhang Email address: jackie.qq.zh...@gmail.com PostgreSQL version: 9.2.1 Operating system: Ubuntu Description: Hi, This actually not a bug but an enhanced log message. I encountered an issue that my PostgreSQL server refused to start with the following messages: --- FATAL: could not create shared memory segment: Invalid argument DETAIL: Failed system call was shmget(key=5432001, size=207691268096, 03600). HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 207691268096 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections. If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for. The PostgreSQL documentation contains more information about shared memory configuration. --- Then, I checked and tuned very very hard the two configuration parameters mentioned in the log, i.e., shared_buffers max_connections but failed to make it work – the problem actually is not caused by these two. I asked some PG guru to check my configuration file, and it finally turned out to be the inappropriate “autovacuum_max_workers" settings. After reading the manual “Managing Kernel Resources”, I find the shared memory is calculated using the following configuration parameters (Table 17-2): UsageApproximate shared memory bytes required (as of 8.3) Connections (1800 + 270 * max_locks_per_transaction) * max_connections Autovacuum workers(1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers Prepared transactions(770 + 270 * max_locks_per_transaction) * max_prepared_transactions Shared disk buffers (block_size + 208) * shared_buffers WAL buffers (wal_block_size + 8) * wal_buffers Fixed space requirements 770 kB So, I wonder can we simply write this in the log message to make it more clear? I definitely think it's easy for we users to understand and quickly figure out the problem. Currently, the log only mentioned two configuration parameters which may mislead users who is dumb as I. Here is the patch I made. I think it's even better to write down the equation (Table 17-2) but I don't know whether the numbers (i.e., 1800, 270) are only used for example. --- -- src/backend/port/sysv_shmem.c 2012-09-19 14:47:58.0 -0700 +++ ../../postgresql-9.2.1/src/backend/port/sysv_shmem.c2012-11-29 00:59:32.656158310 -0800 @@ -150,12 +150,18 @@ "segment exceeded your kernel's SHMMAX parameter. You can either " "reduce the request size or reconfigure the kernel with larger SHMMAX. " "To reduce the request size (currently %lu bytes), reduce " -"PostgreSQL's shared memory usage, perhaps by reducing shared_buffers " -"or max_connections.\n" -"If the request size is already small, it's possible that it is less than " +"PostgreSQL's shared memory usage, perhaps by reducing the following configuration parameters:\n" + " shared_buffers\n" + " wal_buffers\n" + " max_connections\n" + " autovacuum_max_workers\n" + " max_prepared_transactions\n" + " max_locks_per_transaction\n" + " max_pred_locks_per_transaction\n" + "If the request size is already small, it's possible that it is less than " "your kernel's SHMMIN parameter, in which case raising the request size or " "reconfiguring SHMMIN is called for.\n" - "The PostgreSQL documentation contains more information about shared " + "The PostgreSQL documentation (\"Managing Kernel Resources\") contains more information about shared " "memory configuration.", (unsigned long) size) : 0, (errno == ENOMEM) ? --- -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To
