On Thu, Mar 22, 2012 at 11:06 PM, Fujii Masao 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 is not
> the same
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 Tim
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 22, 2012 at 3:45 PM, Stephen Frost 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 analyzing it using t
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. Howev
On Thu, Mar 22, 2012 at 7:03 PM, Jeff Janes wrote:
> On Thu, Mar 22, 2012 at 6:07 AM, Robert Haas wrote:
>> On Wed, Mar 21, 2012 at 3:38 PM, Robert Haas 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 tha
On Thu, Mar 22, 2012 at 6:07 AM, Robert Haas wrote:
> On Wed, Mar 21, 2012 at 3:38 PM, Robert Haas 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
On 23 January 2012 02:08, Robert Haas wrote:
> On Sat, Jan 21, 2012 at 6:32 PM, Jeff Janes 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 serve even this purpose because it
Marko Kreen 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 code at the beg
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 govern
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
> Date: Wed Feb
On Thu, Mar 22, 2012 at 3:45 PM, Stephen Frost 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 have made the c
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
Date: Wed Feb 1 20:16:40 2012 +0200
psql: Case preserving c
Alvaro Herrera 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 extensions providing the same
Alex writes:
> Marko Kreen 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 this work:
>>
>> db = PQ
Excerpts from Dimitri Fontaine's message of jue mar 22 15:08:27 -0300 2012:
> Alvaro Herrera 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 .. feature names shoul
* 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 numb
On Thu, Mar 22, 2012 at 9:07 AM, Robert Haas 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 implements is actually *te
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: sfros
On 22 March 2012 19:07, Tom Lane 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 (pgsql-hackers@po
Peter Geoghegan 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 point. (I do however ob
Marco Nenciarini 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 at all to me. ISTM that EACH
On 22 March 2012 17:19, Tom Lane 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 for tracking purp
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 wrote:
> > > Here is a patch for being able to rename constraints of domains. It
> > > goes on top of the previou
Alvaro Herrera 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 et Support
diff --git a
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:
get_available_vers
On Thu, Mar 22, 2012 at 6:58 AM, Robert Haas wrote:
> On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane 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 functionality and n
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 c
Peter Geoghegan 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 rules.
The patch doesn't
On Thu, Mar 22, 2012 at 12:38 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>> Robert Haas 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
Tom Lane wrote:
> Robert Haas 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 without reading all of it firs
Alex Shulgin 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 of the above functi
On Thu, Mar 22, 2012 at 9:31 AM, Simon Riggs 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 there were no DELETE o
On Thu, Mar 15, 2012 at 10:34 PM, Daniel Farina 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 investigate it i
On Wed, Mar 21, 2012 at 8:28 PM, Robert Haas wrote:
> On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane 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 functionality and not sup
On Thu, Mar 22, 2012 at 1:28 AM, Robert Haas wrote:
> On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane 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 functionality and not sup
On Wed, Mar 21, 2012 at 3:38 PM, Robert Haas 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 you should probably
(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 inf
37 matches
Mail list logo
