Robert Haas writes:
> On Sat, Mar 19, 2011 at 10:46 AM, Nikhil Sontakke
> wrote:
>> Not really a performance issue AFAICS. If the relcache init file exists,
>> then the phase2 of the catalog cache which eventually calls the above code
>> path is avoided.
> Oh, that doesn't sound so bad, then.
I
On Sat, Mar 19, 2011 at 10:32 AM, Yeb Havinga wrote:
> Testing 'methodology' sounds a bit heavy. I tested a number of patch
> versions over time, with 30 second, hourly and nightly pgbench runs. The
> nightly more for durability/memory leak testing than tps numbers, since I
> gradually got the imp
2011/3/19 Vaibhav Kaushal :
> Hello hom,
>
> Frankly I am a learner as well. The experts here are almost always ready
> to help and would be a better source of information.
>
> Moreover I am also using eclipse but I do not use it for building the
> source. I use it only as a source code browser (it
On Sat, Mar 19, 2011 at 10:46 AM, Nikhil Sontakke
wrote:
> Not really a performance issue AFAICS. If the relcache init file exists,
> then the phase2 of the catalog cache which eventually calls the above code
> path is avoided.
Oh, that doesn't sound so bad, then.
--
Robert Haas
EnterpriseDB: h
On Sat, Mar 19, 2011 at 11:34 AM, Grzegorz Jaskiewicz
wrote:
>
> On 18 Mar 2011, at 21:12, Robert Haas wrote:
>
>> While investigating Simon's complaint about my patch of a few days
>> ago, I discovered that synchronous replication appears to slow to a
>> crawl if fsync is turned off on the standb
On 03/18/2011 10:48 PM, Kevin Grittner wrote:
> the least of the evils. I guess we should document it, though, so
> nobody has a false expectation that seeing something on the replica
> means that a connection looking at the master will see something
> that current.
Agreed. Note, however, that e
Hi!
The PostgreSQL project has been accepted into the Google Summer of Code 2011.
Students may begin submitting proposals starting March 28, concluding
on April 8.
Development work runs from May 23 through August 15. For students,
suggested projects, ideas and details are at:
http://wiki.postgre
On Sat, Mar 19, 2011 at 17:39, Tom Lane wrote:
> Magnus Hagander writes:
>> On Sat, Mar 19, 2011 at 16:24, Tom Lane wrote:
>>> ... The docs need
>>> to state the truth, namely that "ident" is still allowed as a synonym
>>> for "peer" on local connections. Otherwise people will get confused
>>>
On Sat, Mar 19, 2011 at 5:05 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Sat, Mar 19, 2011 at 6:10 AM, Tom Lane wrote:
>>> Or we could bite the bullet and start using str_tolower(), but the
>>> performance implications of that are unpleasant; not to mention that
>>> we really don't want to r
I wrote:
> ISTM there are basically three things we might do about this:
> (1) Decide that the patch's behavior is correct and what's embodied in
> the regression expected file is wrong.
> (2) Allow collations to propagate up through nodes that deliver
> noncollatable outputs.
> (3) Decide that
Magnus Hagander writes:
> On Sat, Mar 19, 2011 at 16:24, Tom Lane wrote:
>> ... The docs need
>> to state the truth, namely that "ident" is still allowed as a synonym
>> for "peer" on local connections. Otherwise people will get confused
>> as to why their pg_hba files still work.
> Hmm: Good p
On Sat, Mar 19, 2011 at 16:24, Tom Lane wrote:
> Magnus Hagander writes:
>> Here's an updated patch that removes this log message, and adds a few
>> lines to initdb to create a combination of ident/peer rows. And
>> finally, adds docs.
>
>> Comments?
>
> As near as I can tell (I hate reading u-st
On Sun, Feb 13, 2011 at 17:44, Magnus Hagander wrote:
> On Mon, Feb 7, 2011 at 13:43, Fujii Masao wrote:
>> Hi,
>>
>> When I ran pg_basebackup with -x, -P and -v options, I encountered
>> the following odd output.
>>
>> $ pg_basebackup -D hoge -x -P -v
>> xlog start point: 0/220
>> 3
On 18 Mar 2011, at 21:12, Robert Haas wrote:
> While investigating Simon's complaint about my patch of a few days
> ago, I discovered that synchronous replication appears to slow to a
> crawl if fsync is turned off on the standby.
>
> I'm not sure why this is happening or what the right behavior
Magnus Hagander writes:
> Here's an updated patch that removes this log message, and adds a few
> lines to initdb to create a combination of ident/peer rows. And
> finally, adds docs.
> Comments?
As near as I can tell (I hate reading u-style diffs) you've documented
the ident and peer keywords a
Marko Kreen writes:
> On Sat, Mar 19, 2011 at 6:10 AM, Tom Lane wrote:
>> Or we could bite the bullet and start using str_tolower(), but the
>> performance implications of that are unpleasant; not to mention that
>> we really don't want to re-introduce the "Turkish problem" with
>> unexpected han
Hi,
> The fix is similar to the earlier commit by Tom. I tested this fix
> > against 8.3.13. We lock the parent catalog now before calling
> > index_open. Patch against git HEAD attached with this mail. I guess we
> > will backpatch this? Tom's last commit was backpatched till 8.2 I
> > think.
On 2011-03-18 18:25, Robert Haas wrote:
On Fri, Mar 18, 2011 at 1:15 PM, Simon Riggs wrote:
On Thu, 2011-03-17 at 09:33 -0400, Robert Haas wrote:
Thanks for the review!
Lets have a look here...
You've added a test inside the lock to see if there is a standby, which
I took out for performance
Robert Haas wrote:
> On Fri, Mar 18, 2011 at 7:23 PM, Bruce Momjian wrote:
> > I just applied a doc patch for pg_last_xact_replay_timestamp, and the
> > text now says:
> >
> > ? ? ? Get timestamp of last transaction replayed during recovery.
> > ? ? ? ?This is the time at which the commit or abort
On Fri, Mar 18, 2011 at 11:25 PM, Nikhil Sontakke
wrote:
> The fix is similar to the earlier commit by Tom. I tested this fix
> against 8.3.13. We lock the parent catalog now before calling
> index_open. Patch against git HEAD attached with this mail. I guess we
> will backpatch this? Tom's last c
On Mon, Mar 14, 2011 at 16:26, Magnus Hagander wrote:
> On Mon, Mar 14, 2011 at 16:17, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, Mar 14, 2011 at 14:43, Robert Haas wrote:
Also, the text is not accurate: nothing has been automatically changed
to anything. The pg_hba.conf
On Sat, Mar 19, 2011 at 6:10 AM, Tom Lane wrote:
> Or we could bite the bullet and start using str_tolower(), but the
> performance implications of that are unpleasant; not to mention that
> we really don't want to re-introduce the "Turkish problem" with
> unexpected handling of i/I in identifiers
22 matches
Mail list logo
