Marti Raudsepp ma...@juffo.org writes:
We're already seeing first buildfarm failures, on system narwhal
using an msys/mingw compiler.
Yeah. After a full day's cycle, the answer seems to be that
denormalized input works fine everywhere except:
1. mingw on Windows (even though MSVC builds work)
On 02/03/2012 03:49 AM, Tom Lane wrote:
Marti Raudseppma...@juffo.org writes:
We're already seeing first buildfarm failures, on system narwhal
using an msys/mingw compiler.
Yeah. After a full day's cycle, the answer seems to be that
denormalized input works fine everywhere except:
1.
--On 3. Februar 2012 13:21:11 +0900 Fujii Masao masao.fu...@gmail.com wrote:
It seems to be more user-friendly to introduce a view like pg_stat_backup
rather than the function returning an array.
I like this idea. A use case i saw for monitoring backup_label's in the past,
was mainly to
On Fri, Feb 3, 2012 at 6:10 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 3. Februar 2012 13:21:11 +0900 Fujii Masao masao.fu...@gmail.com
wrote:
It seems to be more user-friendly to introduce a view like pg_stat_backup
rather than the function returning an array.
I like this idea. A
On Fri, Feb 3, 2012 at 10:47, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Feb 3, 2012 at 6:10 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 3. Februar 2012 13:21:11 +0900 Fujii Masao masao.fu...@gmail.com
wrote:
It seems to be more user-friendly to introduce a view like
On Fri, Feb 3, 2012 at 6:52 PM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Feb 3, 2012 at 10:47, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Feb 3, 2012 at 6:10 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 3. Februar 2012 13:21:11 +0900 Fujii Masao masao.fu...@gmail.com
* Peter Eisentraut wrote:
I noticed ecpglib still uses PQconnectdb() with a craftily assembled
connection string. Here is a patch to use PQconnectdbParams() instead.
+ const char *conn_keywords[6];
+ const char *conn_values[6];
Shouldn't these be [7]? You can have up to 6 items,
On Thu, Feb 2, 2012 at 8:31 PM, Joachim Wieland j...@mcknight.de wrote:
On Wed, Feb 1, 2012 at 12:24 PM, Robert Haas robertmh...@gmail.com wrote:
I think we're more-or-less proposing to rename Archive to
Connection, aren't we?
And then ArchiveHandle can store all the things that aren't
On Sat, Jan 28, 2012 at 1:53 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/26 Robert Haas robertmh...@gmail.com:
On Thu, Jan 26, 2012 at 7:27 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It seems to me reasonable design.
The attached patch is rebased one according to your perform-deletion
On Wed, Feb 1, 2012 at 2:39 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Feb 1, 2012 at 7:31 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-01-29 at 22:01 +, Simon Riggs wrote:
Patch now locks index in AccessExclusiveLock in final stage of drop.
Doesn't that defeat the
If I run the following sequence of commands, I get an assertion
failure in current HEAD.
postgres=# BEGIN;
BEGIN
postgres=# SELECT 1/0;
ERROR: division by zero
postgres=# ROLLBACK TO A;
ERROR: no such savepoint
postgres=# \q
The process fails when the session is closed and aborted transaction
On Fri, Feb 3, 2012 at 7:52 AM, Robert Haas robertmh...@gmail.com wrote:
If you're OK with that much I'll go do it.
Sure, go ahead!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jan 21, 2012 at 10:32 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra t...@fuzzy.cz wrote:
Fixed. The default value of TIMING option did not work as intended, it
was set to true even for plain EXPLAIN (without ANALYZE). In that case
the EXPLAIN
PostgreSQL 9.0.4:
While bringing up a streaming replica, and while it is working its way through
the WAL segments before connecting to the primary, I see a lot of messages of
the form:
2012-02-01 21:26:13.978 PST,,,24448,,4f2a1e61.5f80,54,,2012-02-01 21:25:53
PST,1/0,0,LOG,0,restored log
On 3 Únor 2012, 17:12, Robert Haas wrote:
On Sat, Jan 21, 2012 at 10:32 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra t...@fuzzy.cz wrote:
Fixed. The default value of TIMING option did not work as intended, it
was set to true even for plain EXPLAIN
On Fri, Feb 3, 2012 at 12:08 PM, Tomas Vondra t...@fuzzy.cz wrote:
I don't think changing the EXPLAIN syntax this way is a good idea. I think
that one option should not silently enable/disable others, so ROWS should
not enable ANALYZE automatically.
I didn't propose that. The point is that
On 3.2.2012 18:28, Robert Haas wrote:
On Fri, Feb 3, 2012 at 12:08 PM, Tomas Vondra t...@fuzzy.cz wrote:
I don't think changing the EXPLAIN syntax this way is a good idea. I think
that one option should not silently enable/disable others, so ROWS should
not enable ANALYZE automatically.
I
Hi Robert,
Thanks for the feedback! I think you make a good point about the small size of
dirty data in the OS cache. I think what you can say about this double-write
patch is that it will work not work well for configurations that have a small
Postgres cache and a large OS cache, since
On Fri, Jan 27, 2012 at 8:35 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I think you should break this off into a new function,
LWLockWaitUntilFree(), rather than treating it as a new LWLockMode.
Also, instead of adding lwWaitOnly, I would suggest that we generalize
On Fri, Feb 3, 2012 at 3:14 PM, Dan Scales sca...@vmware.com wrote:
Thanks for the feedback! I think you make a good point about the small size
of dirty data in the OS cache. I think what you can say about this
double-write patch is that it will work not work well for configurations that
On Fri, Feb 3, 2012 at 2:56 PM, Tomas Vondra t...@fuzzy.cz wrote:
OK, thanks for the explanation. I don't like the idea of subsets as it
IMHO makes it less obvious what options are enabled. For example this
EXPLAIN (ROWS) query...
does not immediately show it's actually going to do
On 3.2.2012 22:51, Robert Haas wrote:
On Fri, Feb 3, 2012 at 2:56 PM, Tomas Vondra t...@fuzzy.cz wrote:
OK, thanks for the explanation. I don't like the idea of subsets as it
IMHO makes it less obvious what options are enabled. For example this
EXPLAIN (ROWS) query...
does not immediately
On Thu, Feb 2, 2012 at 8:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's a bit disturbing that nobody has reported this from the field yet.
Seems to imply that hot standby isn't being used much.
I have seen this, but didn't get to dig in, as I thought it could be a
problem from other things done
On Tue, Jan 31, 2012 at 3:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
On Tue, Jan 17, 2012 at 2:14 AM, Daniel Farina dan...@heroku.com wrote:
See the attached patch. It has a detailed cover letter/comment at the
top of the file.
I have amended that
On Thu, Feb 02, 2012 at 08:01:48PM +0200, Peter Eisentraut wrote:
I noticed ecpglib still uses PQconnectdb() with a craftily assembled
connection string. Here is a patch to use PQconnectdbParams() instead.
Thanks, committed. Will sync as soon as I'm online again.
Michael
--
Michael Meskes
On Fri, Feb 03, 2012 at 11:12:33AM -0500, Robert Haas wrote:
After looking at this a bit, I think we can make the interface a bit
more convenient. I'd like to propose that we call the EXPLAIN option
ROWS rather than TIMING, and that we provide the row-count
information if *either* ROWS or
Robert Haas wrote:
A couple of things stand out at me from these graphs. First, some
of these transactions had really long latency. Second, there are a
remarkable number of seconds all of the test during which no
transactions at all manage to complete, sometimes several seconds
in a row.
On Fri, Feb 3, 2012 at 8:12 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 21, 2012 at 10:32 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra t...@fuzzy.cz wrote:
Fixed. The default value of TIMING option did not work as intended, it
was set
On Mon, Jan 16, 2012 at 5:59 PM, Greg Smith g...@2ndquadrant.com wrote:
On 01/16/2012 11:00 AM, Robert Haas wrote:
Also, I am still struggling with what the right benchmarking methodology
even is to judge whether
any patch in this area works. Can you provide more details about
your test
On Fri, Feb 3, 2012 at 12:57 PM, Robert Haas robertmh...@gmail.com wrote:
I think I recommended a bad name for this function. It's really
LWLockAcquireOrWaitUntilFree. Can we rename that?
We might also want to consider what all the behaviors are that we
might want here. It strikes me that
On Mon, Jan 30, 2012 at 6:57 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 27.01.2012 15:38, Robert Haas wrote:
On Fri, Jan 27, 2012 at 8:35 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yeah, we have to be careful with any overhead in there, it
On Mon, Jan 16, 2012 at 12:06 PM, Marti Raudsepp ma...@juffo.org wrote:
Here's v6 of my expression caching patch.
i little review...
first, i notice a change of behaviour... i'm not sure if i can say
this is good or not.
with this function:
create or replace function cached_random() returns
32 matches
Mail list logo
