On Sat, Jul 7, 2012 at 1:46 AM, Bruce Momjian br...@momjian.us 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 br...@momjian.us wrote:
I think our big gap is in integrating these sections. There is no easy
way for a bug
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 same
On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout
klep...@svana.org 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
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
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
2012/7/7 Peter Geoghegan pe...@2ndquadrant.com:
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 pavel.steh...@gmail.com wrote:
* renamed auxiliary functions and moved it elog.c - header is new file
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_buffers
On Jul 7, 2012, at 9:07 AM, Euler Taveira eu...@timbira.com 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
On Sat, Jul 7, 2012 at 3:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Jul 7, 2012, at 9:07 AM, Euler Taveira eu...@timbira.com 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.
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 system, which
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
klep...@svana.org 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
On Sat, Jul 7, 2012 at 4:42 PM, Bruce Momjian br...@momjian.us 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
klep...@svana.org wrote:
On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote:
I've never
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 different
On Sat, Jul 7, 2012 at 4:48 PM, Bruce Momjian br...@momjian.us 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 pete...@gmx.net 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
On Jul 7, 2012, at 8:54 AM, Magnus Hagander mag...@hagander.net wrote:
On Sat, Jul 7, 2012 at 3:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Jul 7, 2012, at 9:07 AM, Euler Taveira eu...@timbira.com wrote:
On 07-07-2012 09:00, Satoshi Nagayasu wrote:
I've created new patch to get/reset
On Sat, Jul 7, 2012 at 7:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Jul 7, 2012, at 8:54 AM, Magnus Hagander mag...@hagander.net wrote:
On Sat, Jul 7, 2012 at 3:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Jul 7, 2012, at 9:07 AM, Euler Taveira eu...@timbira.com wrote:
On
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 because
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
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 pete...@gmx.net 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
On Jul 7, 2012, at 1:46 PM, Tom Lane t...@sss.pgh.pa.us 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
Alvaro Herrera alvhe...@commandprompt.com 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
On Thu, Jul 05, 2012 at 06:43:09PM -0700, Josh Kupershmidt wrote:
On Mon, Jul 2, 2012 at 1:13 AM, Pavel Stehule pavel.steh...@gmail.com 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
Tatsuo Ishii is...@postgresql.org 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
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
27 matches
Mail list logo