=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
2012/3/14 Tom Lane t...@sss.pgh.pa.us
For most people it won't
matter, but for people who are using the feature, it seems like
important information. Per the OP's complaint, it's particularly
important for those who
On Wed, Mar 21, 2012 at 10:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ashutosh Bapat ashutosh.ba...@enterprisedb.com writes:
Consider following sequence of commands
create type complex as (r float8, i float8);
create type quad as (c1 complex, c2 complex);
create temp table quadtable(f1
(2012/03/22 9:24), Tom Lane wrote:
What's at stake in the current discussion is whether it would be
advantageous to an FDW if we were to store some information about
remote indexes in the local catalogs. It would still be the FDW's
responsibility, and nobody else's, to make use of that
On Wed, Mar 21, 2012 at 3:38 PM, Robert Haas robertmh...@gmail.com wrote:
It looks like I neglected to record that information for the last set
of runs. But I can try another set of runs and gather that
information.
OK. On further review, my previous test script contained several
bugs. So
On Thu, Mar 22, 2012 at 1:28 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It strikes me that it likely wouldn't be any
worse than, oh, say, flipping the default value of
standard_conforming_strings,
Really? It's taking away
On Wed, Mar 21, 2012 at 8:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It strikes me that it likely wouldn't be any
worse than, oh, say, flipping the default value of
standard_conforming_strings,
Really? It's taking away
On Thu, Mar 15, 2012 at 10:34 PM, Daniel Farina dan...@heroku.com wrote:
I'd really like to find a way to layer both message-oblivious and
message-aware transport under FEBE with both backend and frontend
support without committing the project to new code for-ever-and-ever.
I guess I could
On Thu, Mar 22, 2012 at 9:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
Surely it just stops you using that idea 100% of the time. I don't see
why you can't have this co-exist with the current mechanism. So it
doesn't kill it for the common case.
I guess you could use it if you knew that
Alex Shulgin a...@commandprompt.com writes:
While working on this fix I've figured out that I need my
conninfo_uri_parse to support use_defaults parameter, like
conninfo(_array)_parse functions do.
The problem is that the block of code which does the defaults handling
is duplicated in both
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, the standard syntax apparently aims to reduce the number of
returned rows, which ORDER BY does not. Maybe you could do it
with ORDER BY .. LIMIT, but the idea here I think is that we'd
like to sample the table
On Thu, Mar 22, 2012 at 12:38 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, the standard syntax apparently aims to reduce the number of
returned rows, which ORDER BY does not. Maybe you could do it
Peter Geoghegan pe...@2ndquadrant.com writes:
[ pg_stat_statements_norm_2012_02_29.patch ]
I started to look at this patch (just the core-code modifications so
far). There are some things that seem not terribly well thought out:
* It doesn't look to me like it will behave very sanely with
Hi,
Again, thanks very much for the review. Here's an updated patch (just
merged against master) fixing most of your comments here. I couldn't
reproduce previous problems with the attached:
- DROP EXTENSION was broken, asking to cascade to self
- CREATE EXTENSION was bypassing requires
I
On Thu, Mar 22, 2012 at 6:58 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It strikes me that it likely wouldn't be any
worse than, oh, say, flipping the default value of
standard_conforming_strings,
Really? It's
Excerpts from Dimitri Fontaine's message of jue mar 22 14:38:29 -0300 2012:
Hi,
Again, thanks very much for the review. Here's an updated patch (just
merged against master) fixing most of your comments here. I couldn't
reproduce previous problems with the attached:
Alvaro Herrera alvhe...@commandprompt.com writes:
get_available_versions_for_extension seems to contain a bunch of
commented-out lines ...
Damn. Sorry about that. Here's a cleaned-up version of the patch.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation
On ons, 2012-03-21 at 11:57 -0300, Alvaro Herrera wrote:
Excerpts from Robert Haas's message of mié mar 21 11:43:17 -0300 2012:
On Fri, Mar 16, 2012 at 1:34 PM, Peter Eisentraut pete...@gmx.net wrote:
Here is a patch for being able to rename constraints of domains. It
goes on top of the
On 22 March 2012 17:19, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to think that the most useful behavior is to teach the
rewriter to copy queryId from the original query into all the Queries
generated by rewrite. Then, all rules fired by a source query would
be lumped into that query
Marco Nenciarini marco.nenciar...@2ndquadrant.it writes:
Attached is v5, which should address all the remaining issues.
I started to look at this patch a bit. I'm quite confused by the fact
that some, but not all, of the possible FK action types now come in an
EACH variant. This makes no sense
Peter Geoghegan pe...@2ndquadrant.com writes:
Since you haven't mentioned the removal of parse-analysis Const
location alterations, I take it that you do not object to that, which
is something I'm glad of.
I remain un-thrilled about it, but apparently nobody else cares, so
I'll yield the
On 22 March 2012 19:07, Tom Lane t...@sss.pgh.pa.us wrote:
Will you adjust the patch for the other issues?
Sure. I'll take a look at it now.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list
Greetings,
I've recently become a bit annoyed and frustrated looking at this in
top:
23296 postgres 20 0 3341m 304m 299m S 12 0.9 1:50.02 postgres: sfrost
gis [local] COPY waiting
24362 postgres 20 0 3353m 298m 285m D 12 0.9 1:24.99 postgres:
On Thu, Mar 22, 2012 at 9:07 AM, Robert Haas robertmh...@gmail.com wrote:
However, looking at this a bit more, I think the
checkpoint-sync-pause-v1 patch contains an obvious bug - the GUC is
supposedly represented in seconds (though not marked with GUC_UNIT_S,
oops) but what the sleep
* Robert Haas (robertmh...@gmail.com) wrote:
TPS numbers:
checkpoint-sync-pause-v1: 2594.448538, 2600.231666, 2580.041376
master: 2466.31, 2450.752843, 2291.613305
90th percentile latency:
checkpoint-sync-pause-v1: 1487, 1488, 1481
master: 1493, 1519, 1507
Well, those numbers just
Excerpts from Dimitri Fontaine's message of jue mar 22 15:08:27 -0300 2012:
Alvaro Herrera alvhe...@commandprompt.com writes:
get_available_versions_for_extension seems to contain a bunch of
commented-out lines ...
Damn. Sorry about that. Here's a cleaned-up version of the patch.
Hmm ..
Alex a...@commandprompt.com writes:
Marko Kreen mark...@gmail.com writes:
On Thu, Mar 15, 2012 at 11:29:31PM +0200, Alex wrote:
https://github.com/a1exsh/postgres/commits/uri
The point of the patch is to have one string with all connection options,
in standard format, yes? So why does not
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm .. feature names should be globally unique, right? If so I think
you're missing an UNIQUE index on the new catalog, covering just the
feature name. You have a two column index (extoid, featurename), so you
could have two different
Postgres 9.2 has been modified so psql no longer uppercases SQL keywords
when using tab completation, by this commit:
commit 69f4f1c3576abc535871c6cfa95539e32a36120f
Author: Peter Eisentraut pete...@gmx.net
Date: Wed Feb 1 20:16:40 2012 +0200
psql:
On Thu, Mar 22, 2012 at 3:45 PM, Stephen Frost sfr...@snowman.net wrote:
Well, those numbers just aren't that exciting. :/
Agreed. There's clearly an effect, but on this test it's not very big.
Then again, I'm a bit surprised that the latencies aren't worse, perhaps
the previous improvements
On Thursday, March 22, 2012 10:49:55 PM Bruce Momjian wrote:
Postgres 9.2 has been modified so psql no longer uppercases SQL keywords
when using tab completation, by this commit:
commit 69f4f1c3576abc535871c6cfa95539e32a36120f
Author: Peter Eisentraut pete...@gmx.net
Date:
On 03/22/2012 05:49 PM, Bruce Momjian wrote:
Robert Haas and I are disappointed by this change. I liked the fact
that I could post nice-looking SQL queries without having to use my
capslock key (which I use as a second control key). Any chance of
reverting this change?
Should it be
Marko Kreen mark...@gmail.com writes:
[ patches against libpq and dblink ]
I think this patch needs a lot of work.
AFAICT it breaks async processing entirely, because many changes have been
made that fail to distinguish insufficient data available as yet from
hard error. As an example, this
On 23 January 2012 02:08, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 21, 2012 at 6:32 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I'm finding the backend_writes column pretty unfortunate. The only
use I know of for it is to determine if the bgwriter is lagging
behind. Yet it doesn't
On Thu, Mar 22, 2012 at 6:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 21, 2012 at 3:38 PM, Robert Haas robertmh...@gmail.com wrote:
It looks like I neglected to record that information for the last set
of runs. But I can try another set of runs and gather that
information.
On Thu, Mar 22, 2012 at 7:03 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Mar 22, 2012 at 6:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 21, 2012 at 3:38 PM, Robert Haas robertmh...@gmail.com wrote:
It looks like I neglected to record that information for the last set
of
Some time ago I reported bug 6291[0], which reported a Xid wraparound,
both as reported in pg_controldata and by txid_current_snapshot.
Unfortunately, nobody could reproduce it.
Today, the same system of ours just passed the wraparound mark
successfully at this time, incrementing the epoch.
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Mar 22, 2012 at 3:45 PM, Stephen Frost sfr...@snowman.net wrote:
Well, those numbers just aren't that exciting. :/
Agreed. There's clearly an effect, but on this test it's not very big.
Ok, perhaps that was because of how you were
Hi,
I'd like to propose to change pg_controldata so that it reports the name
of WAL file containing the latest checkpoint's REDO record, as follows:
$ pg_controldata $PGDATA
...
Latest checkpoint's REDO location:0/16D6ACC (file
00010001)
Latest checkpoint's
On Thu, Mar 22, 2012 at 11:06 PM, Fujii Masao masao.fu...@gmail.com wrote:
We can use
pg_xlogfile_name function to calculate that, but it cannot be executed in
the standby. Another problem is that pg_xlogfile_name always uses
current timeline for the calculation, so if the reported timeline
39 matches
Mail list logo
