On Sat, Jul 7, 2012 at 1:46 AM, Bruce Momjian wrote:
> On Fri, Jul 06, 2012 at 03:41:41PM -0700, Daniel Farina wrote:
>> On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian wrote:
>> > I think our big gap is in integrating these sections. There is no easy
>> > way for a bug reporter to find out what
On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote:
> I've never thought of it in terms of "friction", but I think that term
> makes a lot of sense. And it sums up pretty much one of the things
> that I find the most annoying with the commitfest app - in the end it
> boils down to the
On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout
wrote:
> On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote:
>> I've never thought of it in terms of "friction", but I think that term
>> makes a lot of sense. And it sums up pretty much one of the things
>> that I find the most
Hello
updated patch - parameters can be subqueries now. This needs enhancing
SPI little bit.
postgres=# do (a int, b int, text) $$begin raise notice '% % %', $1,
$2, $3; end; $$ language plpgsql using 10+100,(select a from x),
:'USER';
NOTICE: 110 10 pavel
DO
Regards
Pavel
2012/7/6 Pavel Ste
Hi all,
I've created new patch to get/reset statistics of WAL buffer
writes (flushes) caused by WAL buffer full.
This patch provides two new functions, pg_stat_get_xlog_dirty_write()
and pg_stat_reset_xlog_dirty_write(), which have been designed to
determine an appropriate value for WAL buffer si
2012/7/7 Peter Geoghegan :
> Attached is a revision of this patch, with a few clean-ups, mostly to
> the wording of certain things.
>
> On 5 July 2012 17:41, Pavel Stehule wrote:
>> * renamed auxiliary functions and moved it elog.c - header is new file
>> "relerror.h"
>
> In my revision, I've just
On 07-07-2012 09:00, Satoshi Nagayasu wrote:
> I've created new patch to get/reset statistics of WAL buffer
> writes (flushes) caused by WAL buffer full.
>
This new statistic doesn't solve your problem (tune wal_buffers). It doesn't
give you the wal_buffers value. It only says "hey, I needed more
2012/07/07 22:07, Euler Taveira wrote:
> On 07-07-2012 09:00, Satoshi Nagayasu wrote:
>> I've created new patch to get/reset statistics of WAL buffer
>> writes (flushes) caused by WAL buffer full.
>>
> This new statistic doesn't solve your problem (tune wal_buffers). It doesn't
> give you the wal_b
On Jul 7, 2012, at 9:07 AM, Euler Taveira wrote:
> On 07-07-2012 09:00, Satoshi Nagayasu wrote:
>> I've created new patch to get/reset statistics of WAL buffer
>> writes (flushes) caused by WAL buffer full.
>>
> This new statistic doesn't solve your problem (tune wal_buffers). It doesn't
> give y
On Sat, Jul 7, 2012 at 3:52 PM, Robert Haas wrote:
> On Jul 7, 2012, at 9:07 AM, Euler Taveira wrote:
>> On 07-07-2012 09:00, Satoshi Nagayasu wrote:
>>> I've created new patch to get/reset statistics of WAL buffer
>>> writes (flushes) caused by WAL buffer full.
>>>
>> This new statistic doesn't
On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote:
> >> I do basically agree with this. I was reflecting on the bug tracker
> >> issue (or lack thereof) for unrelated reasons earlier today and I
> >> think there are some very nice things to recommend the current
> >> email-based syst
On Sat, Jul 07, 2012 at 12:59:02PM +0200, Magnus Hagander wrote:
> On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout
> wrote:
> > On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote:
> >> I've never thought of it in terms of "friction", but I think that term
> >> makes a lot of s
On Sat, Jul 7, 2012 at 4:42 PM, Bruce Momjian wrote:
> On Sat, Jul 07, 2012 at 12:59:02PM +0200, Magnus Hagander wrote:
>> On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout
>> wrote:
>> > On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote:
>> >> I've never thought of it in term
On Sat, Jul 07, 2012 at 04:45:42PM +0200, Magnus Hagander wrote:
> >> That's not to say it's a horrible idea, it's just to say that things
> >> are never as easy as they first look.
> >>
> >> BTW, the *bigger* issue with this path is that now we suddenly have
> >> different kinds of identifiers for
On Sat, Jul 7, 2012 at 4:48 PM, Bruce Momjian wrote:
> On Sat, Jul 07, 2012 at 04:45:42PM +0200, Magnus Hagander wrote:
>> >> That's not to say it's a horrible idea, it's just to say that things
>> >> are never as easy as they first look.
>> >>
>> >> BTW, the *bigger* issue with this path is that
On Fri, Jul 6, 2012 at 4:50 PM, Peter Eisentraut wrote:
> I have code in the wild that defines new operators and casts and has no
> C code and is not in an extension and has no business being in an
> extension.
Nobody is claiming that pgdump shouldn't dump it.
But, since you're using operators,
On Jul 7, 2012, at 8:54 AM, Magnus Hagander wrote:
> On Sat, Jul 7, 2012 at 3:52 PM, Robert Haas wrote:
>> On Jul 7, 2012, at 9:07 AM, Euler Taveira wrote:
>>> On 07-07-2012 09:00, Satoshi Nagayasu wrote:
I've created new patch to get/reset statistics of WAL buffer
writes (flushes) cau
On Sat, Jul 7, 2012 at 7:06 PM, Robert Haas wrote:
> On Jul 7, 2012, at 8:54 AM, Magnus Hagander wrote:
>> On Sat, Jul 7, 2012 at 3:52 PM, Robert Haas wrote:
>>> On Jul 7, 2012, at 9:07 AM, Euler Taveira wrote:
On 07-07-2012 09:00, Satoshi Nagayasu wrote:
> I've created new patch to ge
In
http://archives.postgresql.org/pgsql-general/2012-07/msg00107.php
it's pointed out that regex_fixed_prefix() gets the wrong answer
when presented with a regex like '^(xyz...)?...'. It thinks this
pattern has a fixed prefix of "xyz", that is can only match strings
beginning with "xyz". But beca
This is a review for pg_prewarm V2.
It applies (with some fuzz, but it is handled correctly) and builds cleanly.
It includes docs, but does not include regression tests, which it
probably should (just to verify that it continues to compile and
execute without throwing errors, I wouldn't expect an
Excerpts from Aidan Van Dyk's message of sáb jul 07 11:32:33 -0400 2012:
>
> On Fri, Jul 6, 2012 at 4:50 PM, Peter Eisentraut wrote:
>
> > I have code in the wild that defines new operators and casts and has no
> > C code and is not in an extension and has no business being in an
> > extension.
On Jul 7, 2012, at 1:46 PM, Tom Lane wrote:
> 3. Try another approach entirely. The idea that I've got in mind here
> is to compile the regex using the regex library and then look at the
> compiled NFA representation to see if there must be a fixed prefix.
> I would not have risked this before th
Alvaro Herrera writes:
> Excerpts from Aidan Van Dyk's message of sáb jul 07 11:32:33 -0400 2012:
>> But, since you're using operators, what would you think is an
>> appropriate name for the file the operator is dumped into?
> I was thinking that it might make sense to group operators according
On Thu, Jul 05, 2012 at 06:43:09PM -0700, Josh Kupershmidt wrote:
> On Mon, Jul 2, 2012 at 1:13 AM, Pavel Stehule wrote:
>
> > I tested Peter's patch and it works well.
>
> I liked it as well. But I'm not sure what should happen with the patch
> now. It seems like it'd be commit-ready with just
>> Tatsuo Ishii writes:
So far as I can see, the only LCPRVn marker code that is actually in
use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
that I can find.
I also read in the xemacs internals doc, at
http://www.xemacs.org/Documentation/21.5/html/i
Hi,
Jeff Janes has pointed out that my previous patch could hold
a number of the dirty writes only in single local backend, and
it could not hold all over the cluster, because the counter
was allocated in the local process memory.
That's true, and I have fixed it with moving the counter into
the
From: pgsql-hackers-ow...@postgresql.org [pgsql-hackers-ow...@postgresql.org]
on behalf of Jeff Janes [jeff.ja...@gmail.com]
>For the implementation:
>1)
>I think that for most users, making them know or care about forks and
> block numbers is too much. It would be nice if there were a
> singl
27 matches
Mail list logo
