On 2011-09-28 15:25, Joachim Wieland wrote:
Yes, that's the desired behaviour, the patch add this paragraph to the
documentation already:
I can't believe I missed that. My apologies.
On 2011-09-29 05:16, Joachim Wieland wrote:
The attached patch addresses the reported issues.
Thanks, this
On Fri, Sep 30, 2011 at 3:57 PM, Simon Riggs wrote:
> I think we should issue PANIC if the source is a critical rmgr, or
> just WARNING if from a non-critical rmgr, such as indexes.
>
> Ideally, I think we should have a mechanism to allow indexes to be
> marked corrupt. For example, a file that if
Andrew Dunstan writes:
> While investigating a client problem I just observed that pg_dump takes
> a surprisingly large amount of time to dump a schema with a large number
> of views. The client's hardware is quite spiffy, and yet pg_dump is
> taking many minutes to dump a schema with some 35,0
Simon Riggs writes:
> On Sun, Oct 2, 2011 at 10:05 PM, Tom Lane wrote:
>> So at this point I'd vote for just dropping it and always allowing
>> custom (that is, qualified) GUC names to be set, whether the prefix
>> corresponds to any loaded module or not.
> Sounds sensible. One less thing to con
On Sun, Oct 2, 2011 at 7:54 AM, Bruce Momjian wrote:
> What exactly is your question? You are not using a config-only
> directory but the real data directory, so it should work fine.
No. He is using PGDATA (= /etc/postgresql-9.0) as a config-only
directory, and DATA_DIR (= /var/lib/postgresql/9.
Heikki Linnakangas writes:
> On 06.09.2011 20:34, Oleg Bartunov wrote:
>> Here is the latest spgist patch, which has all planned features as well as
>> all overhead, introduced by concurrency and recovery, so performance
>> measurement should be realistic now.
> I'm ignoring the text suffix-tree
2011/10/2 Simon Riggs :
> On Thu, Sep 15, 2011 at 11:53 PM, Simon Riggs wrote:
>
>> Current patch has a bug at shutdown I've not located yet, but seems
>> likely is a simple error. That is mainly because for personal reasons
>> I've not been able to work on the patch recently. I expect to be able
On 10/02/2011 05:25 PM, Tom Lane wrote:
Andrew Dunstan writes:
I have been investigating some build performance issues, and trying to
narrow down causes of slowness, and observed an odd effect, which was
suggested by a huge time difference between building from git and
building from a tarball
On Sun, Oct 2, 2011 at 10:05 PM, Tom Lane wrote:
> During the discussion of Alexey Klyukin's rewrite of ParseConfigFile,
> considerable unhappiness was expressed by various people about the
> complexity and relative uselessness of the custom_variable_classes GUC.
> While working over his patch jus
Robert Haas writes:
> It occurs to me that pgstat_report_xact_end_timestamp doesn't really
> need to follow the protocol of bumping the change count before and
> after bumping the timestamp. We elsewhere assume that four-byte reads
> and writes are atomic, so there's no harm in assuming the same
Noah Misch writes:
> On Sun, Oct 02, 2011 at 06:55:51AM -0400, Robert Haas wrote:
>> On Sat, Oct 1, 2011 at 10:11 PM, Euler Taveira de Oliveira
>> wrote:
>>> I see. What about passing this decision to DBA? I mean a GUC
>>> can_cancel_session = user, dbowner (default is '' -- only superuser). You
Andrew Dunstan writes:
> I have been investigating some build performance issues, and trying to
> narrow down causes of slowness, and observed an odd effect, which was
> suggested by a huge time difference between building from git and
> building from a tarball.
> If I do
> make -C src/po
Hi Andrew,
On 10/01/2011 09:46 PM, Andrew Dunstan wrote:
>
>
> On 10/01/2011 05:48 PM, Joe Abbate wrote:
>> On 10/01/2011 05:08 PM, Andrew Dunstan wrote:
>>> There is also this gem of behaviour, which is where I started:
>>>
>>> p1p2
>>> begin;
>>> drop view foo;
>>>
During the discussion of Alexey Klyukin's rewrite of ParseConfigFile,
considerable unhappiness was expressed by various people about the
complexity and relative uselessness of the custom_variable_classes GUC.
While working over his patch just now, I've come around to the side that
was saying that t
Alexey Klyukin writes:
> Attached is v5. It should fix both problems you've experienced with v4.
I've applied this patch after some additional hacking.
> One problem I'm not sure how to address is the fact that we require 2
> calls of set_config_option for each option, one to verify the new
> va
Hi,
Kohei KaiGai writes:
>> I've been reviewing those patches, that are all about code refactoring.
>> I like what it's doing, generalizing ad-hoc code by adding some more
>> knowledge about the source tree into some data structures. Typically,
>> what catcache to use for a given object's class-
I have been investigating some build performance issues, and trying to
narrow down causes of slowness, and observed an odd effect, which was
suggested by a huge time difference between building from git and
building from a tarball.
If I do
make -C src/port all
and then wait 10 seconds
Noah Misch writes:
>> >> On Fri, Sep 30, 2011 at 9:30 PM, Tom Lane ?wrote:
>> >>> ISTM it would be reasonably non-controversial to allow users to issue
>> >>> pg_cancel_backend against other sessions logged in as the same userID.
>> >>> The question is whether to go further than that, and if so ho
2011/9/30 Noah Misch :
> On Sun, Sep 25, 2011 at 11:22:56PM -0400, Robert Haas wrote:
>> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
>> > On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
>> >> Robert Haas ?09/25/11 10:58 AM >>>
>> >>
>> >> > I'm not sure we've been 100% cons
On Sun, 2011-10-02 at 11:32 +0200, Florian Pflug wrote:
> Looking at the patch, I noticed that it's possible to specify the default
> boundaries ([], [), (] or ()) per individual float type with the
> DEFAULT_FLAGS clause of CREATE TYPE .. AS RANGE. I wonder if that doesn't
> do more harm then good
On Sun, Oct 02, 2011 at 06:55:51AM -0400, Robert Haas wrote:
> On Sat, Oct 1, 2011 at 10:11 PM, Euler Taveira de Oliveira
> wrote:
> > On 01-10-2011 17:44, Daniel Farina wrote:
> >> On Fri, Sep 30, 2011 at 9:30 PM, Tom Lane ?wrote:
> >>> ISTM it would be reasonably non-controversial to allow users
On Sun, Oct 2, 2011 at 12:10 PM, Robert Haas wrote:
> On Fri, Sep 30, 2011 at 4:07 PM, Simon Riggs wrote:
>> On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas wrote:
>>> On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs wrote:
If the feature could not be done another way, easily, I might agree.
>>>
On Thu, Sep 15, 2011 at 4:52 AM, Fujii Masao wrote:
> Okay, I've changed the patch in that way.
It occurs to me that pgstat_report_xact_end_timestamp doesn't really
need to follow the protocol of bumping the change count before and
after bumping the timestamp. We elsewhere assume that four-byte
On Fri, Sep 30, 2011 at 4:07 PM, Simon Riggs wrote:
> On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas wrote:
>> On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs wrote:
>>> If the feature could not be done another way, easily, I might agree.
>>
>> I don't see that you've offered a reasonable alternative
I like this idea
+1
Il giorno 02/ott/2011 12:56, "Robert Haas" ha
scritto:
> On Sat, Oct 1, 2011 at 10:11 PM, Euler Taveira de Oliveira
> wrote:
>> On 01-10-2011 17:44, Daniel Farina wrote:
>>>
>>> On Fri, Sep 30, 2011 at 9:30 PM, Tom Lane wrote:
ISTM it would be reasonably non-contro
On Sat, Oct 1, 2011 at 10:11 PM, Euler Taveira de Oliveira
wrote:
> On 01-10-2011 17:44, Daniel Farina wrote:
>>
>> On Fri, Sep 30, 2011 at 9:30 PM, Tom Lane wrote:
>>>
>>> ISTM it would be reasonably non-controversial to allow users to issue
>>> pg_cancel_backend against other sessions logged in
On Oct2, 2011, at 08:12 , Jeff Davis wrote:
> Done. Now range types more closely resemble records in parsing behavior.
> Patch attached.
Cool!
Looking at the patch, I noticed that it's possible to specify the default
boundaries ([], [), (] or ()) per individual float type with the
DEFAULT_FLAGS c
27 matches
Mail list logo