Hi,
On 2012-10-31 11:41:37 +0530, Amit Kapila wrote:
There seems to be a problem in behavior of Create Index Concurrently and Hot
Update in HEAD code .
At pgcon.it I had a chance to discuss with Simon how to fix this
bug. Please check the attached patches - and their commit messages - for
the
Added to TODO:
Improve cache lookup speed for sessions accessing many relations
http://archives.postgresql.org/pgsql-hackers/2012-11/msg00356.php
---
On Fri, Nov 9, 2012 at 12:50:34AM -0500,
Amit kapila amit.kap...@huawei.com writes:
On Friday, November 23, 2012 10:10 PM Fujii Masao wrote:
What happens if the server crashes while SET PERSISTENT is writing the
setting to the file? A partial write occurs and restart of the server would
fail
because of corrupted
On 2012-10-05 19:56:40 -0400, Tom Lane wrote:
1. These operations think they can use ordinary heap_update operations
to change pg_index entries when they don't have exclusive lock on the
parent table. The lack of ex-lock means that another backend could be
currently loading up its list of
On Mon, Nov 12, 2012 at 06:14:59PM -0300, Alvaro Herrera wrote:
Bruce Momjian escribió:
--- 17,24
static void transfer_single_new_db(pageCnvCtx *pageConverter,
FileNameMap *maps, int size);
! static int transfer_relfile(pageCnvCtx
2012/11/21 Alvaro Herrera alvhe...@2ndquadrant.com:
Alvaro Herrera escribió:
FWIW I have pushed this to github; see
https://github.com/alvherre/postgres/compare/bgworker
It's also attached.
The UnBlockSig stuff is the main stumbling block as I see it because it
precludes compilation on
2012/11/21 Shigeru Hanada shigeru.han...@gmail.com:
Thank for the comment!
On Tue, Nov 20, 2012 at 10:23 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I also think the new use_remote_explain option is good. It works fine
when we try to use this fdw over the network with latency more or less.
I have found an odd mistake in pg_upgrade 9.2, though I don't think it
is a problem. Specifically, pg_upgrade will copy a visibility map (vm)
1GB extent file from the old cluster to the new, even if the
crash-safety of the old vm file does not match the new server. For
example, 19323_vm would
On Wed, 2012-11-21 at 15:12 -0500, Robert Haas wrote:
On Sat, Nov 17, 2012 at 1:22 AM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2012-11-12 at 11:42 -0600, Karl O. Pinc wrote:
Could ALTER TABLE use an option to drop the
primary key constraint? I needed to do that,
found it was not
On Wed, 2012-11-21 at 23:56 -0600, Karl O. Pinc wrote:
No, wait. If constraint name_of_primary_key is an internal
and is to change over time, how do you deal with dropping,
now, a primary key constraint that was created, then, before
some change to the internal name. And you wouldn't want
On Saturday, November 24, 2012 10:56 PM Tom Lane wrote:
Amit kapila amit.kap...@huawei.com writes:
On Friday, November 23, 2012 10:10 PM Fujii Masao wrote:
What happens if the server crashes while SET PERSISTENT is writing the
setting to the file? A partial write occurs and restart of the
On Fri, Nov 23, 2012 at 7:22 PM, Bruce Momjian br...@momjian.us wrote:
On Mon, Nov 19, 2012 at 12:11:26PM -0800, Jeff Janes wrote:
Yes, it is with synchronous_commit=off. (or if it wasn't originally,
it is now, with the same result)
Applying your fsync patch does solve the problem for me
While trying to decide of autovacuum was working optimally, I observed
some log messages like this:
9405 2012-11-24 01:01:25.982 PSTLOG: automatic vacuum of table
jeff.pg_catalog.pg_class: index scans: 1
pages: 0 removed, 2441 remain
tuples: 86 removed, 84079 remain
system usage:
13 matches
Mail list logo
