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: C
On Fri, Nov 23, 2012 at 7:22 PM, Bruce Momjian 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 on ext
On Saturday, November 24, 2012 10:56 PM Tom Lane wrote:
Amit kapila 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
>>> fai
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 w
On Wed, 2012-11-21 at 15:12 -0500, Robert Haas wrote:
> On Sat, Nov 17, 2012 at 1:22 AM, Peter Eisentraut 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 obvi
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 no
2012/11/21 Shigeru Hanada :
> Thank for the comment!
>
> On Tue, Nov 20, 2012 at 10:23 PM, Kohei KaiGai 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.
>> It seems to me its default is "
2012/11/21 Alvaro Herrera :
> 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 Windows. May
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(pageC
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
Amit kapila 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 postgresql.auto.conf?
> This sit
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, T
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
13 matches
Mail list logo
