On tis, 2010-10-12 at 17:03 -0400, Tom Lane wrote:
> Oh, I had an idea for a small improvement to this. It doesn't seem
> unlikely that pg_hba.conf could contain multiple entries with the same
> host name (but, presumably, different user and/or database names). As
> this is coded, you'll do a for
Hi all!
./configure --prefix=$HOME/inst/pg-9 --enable-nls --enable-debug
--enable-depend --enable-cassert --enable-thread-safety --with-pgport=5431
--with-libxml --with-libxslt --with-python --with-perl --with-tcl
FLEX=/usr/local/bin/flex
--8<---cut here---start
This surprised me:
psql -p 5 -h localhost
psql: could not connect to server: Connection refused
Is the server running on host "localhost" and accepting
TCP/IP connections on port 5?
could not connect to server: Connection refused
Is the server running on host "local
On Wed, Oct 13, 2010 at 12:56:15PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > But creating a separate file doesn't fix that problem. It just moves
> > it around. If people will expect comments in postgresql.conf to get
> > preserved, then why won't they also expect comments in
> > postgre
Tom Lane wrote:
> the "OMG Postgres exposes my information" crowd is not going to
> distinguish leaks that only expose MCVs from those that trivially
> allow sucking out the entire table.
Well, I'd be in the crowd that would go "OMG" over one but not the
other. At least in our case management
Since MaxBackends is actually max_connections + autovacuum_max_workers +
1, when you get an error message from shmget() it will tell you
"reduce ... its max_connections parameter (currently 104)"
when you actually set
max_connections = 100
This looks a bit silly.
Should we just make the error
We have a database specification in .pgpass:
hostname:port:database:username:password
What is the purpose of 'database' since username/password combinations
are global, not per database? I would like to documents its purpose.
--
Bruce Momjian http://momjian.us
EnterpriseDB
Rados*aw Smogura wrote:
> I updated patch to latets CVS version, I didn't have time to
> remove some trashes from it.
>
> If something will be wrong with patch, give a feedback.
I skimmed it and agree that it is the right general approach --
using java.util.Timer to trigger the cancel method.
Robert Haas writes:
> Another awkwardness of this patch is that it makes
> create_append_path() and consequently set_dummy_rel_pathlist() take an
> additional "root" argument. While there's nothing terribly
> unreasonable about this on its face, it's only necessary so that
> create_append_path()
> IIRC the proposal was that postgresql.conf (the people-editable file)
> would have "include postgresql.auto" in it. You could put that at
> the top, bottom, or even middle to control how the priority works.
> So it's user-configurable. I think the factory default ought to
> be to have it at th
Robert Haas writes:
> You seem to believe that being able to infer the total size of a
> table or the frequency of some particular key in the table is
> equivalent to being able to trivially read every row of it.
I don't say that they're equivalent. I do say that what this patch is
mostly trying
This, what I see in your patch, is sending additional statement to server.
This adds some unnecessery (especially TCP/IP) latency. gura
> > I sent such patch fully in Java
> > (http://archives.postgresql.org/pgsql-jdbc/2009-11/msg00010.php),
> > implementing cancellation with Timer and "cancel q
>
> In this case search of near strings can be accelerated in more than 10
> times.
I mean that component of function runtime can be accelerated in more than 10
times. Of course, actual overall speedup depends on many other factors, but
I belive that it also can be significant.
With best reg
> No doubt, but the actual function runtime is only one component of the
> cost of applying it to a lot of dictionary entries --- I would think
> that the table read costs are the larger component anyway.
Data domain can be not only dictionary but also something like article
titles, urls and so on
Robert Haas writes:
> But creating a separate file doesn't fix that problem. It just moves
> it around. If people will expect comments in postgresql.conf to get
> preserved, then why won't they also expect comments in
> postgresql.conf.auto to get preserved?
Because postgresql.conf.auto will ha
Robert Haas writes:
> On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
>> That's all true, but you have to consider how much the obstacle actually
>> gets in their way versus how painful it is on your end to create and
>> maintain the obstacle. I don't think this proposed patch measures up
>> v
On Wed, Oct 13, 2010 at 11:42 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 13, 2010 at 10:51 AM, Tom Lane wrote:
>>> But the main point is that 6% performance penalty in a non-core function
>>> is well below my threshold of pain.
>
>> Well, then you have to wonder whether it's worth
On Wed, Oct 13, 2010 at 10:25 AM, Tom Lane wrote:
> Robert Haas writes:
>> You're not alone on this at all: I agree 100%. I don't like your
>> proposed syntax, but I completely agree with your concern. I don't
>> see what's wrong with having the initial contents of postgresql.conf
>> look like
On Wednesday 13 October 2010 16:18:01 Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of mié oct 13 10:32:36 -0300 2010:
> > Robert Haas writes:
> > > I spent some time hacking on this. It doesn't appear to be too easy
> > > to get levenshtein_less_equal() working without slowing down pl
On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> I had the pleasure of hearing Admiral Grace Hopper[1] speak at an
>> ACM luncheon once. When she discussed security, she asserted that
>> there was no such thing as security which could not be breached.
>> The goal o
On Wed, Oct 13, 2010 at 9:43 AM, Tom Lane wrote:
> Robert Haas writes:
>> With the possible exception of Tom,
>> everyone seems to agree that it would be a good step forward to
>> provide a way of plugging these holes, even if it didn't cover subtler
>> information leaks such as by reading the EX
On Wed, Oct 13, 2010 at 11:36:02AM -0300, Alvaro Herrera wrote:
> Excerpts from David Fetter's message of mié oct 13 11:27:56 -0300 2010:
> > On Tue, Oct 12, 2010 at 08:57:09PM +0200, Dimitri Fontaine wrote:
>
> > > - Extension Upgrading
> > >
> > >Should this be done by means of 'create ext
Tom Lane writes:
> I'm not sure if anybody is particularly against the initial contents
> looking like that. The big problem, which both you and Dimitri are
> conveniently ignoring, is that if people are allowed to hand-edit
> the file they are going to introduce comments that no mechanical
> par
On Oct 13, 2010, at 10:24 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> +1. Preserving the comments when you change the value could make the
>> comments totally bogus. Separating machine-generated values into a
>> separate file makes plenty of sense to me.
>
>> Which one wins, though? I can
"Kevin Grittner" writes:
> I had the pleasure of hearing Admiral Grace Hopper[1] speak at an
> ACM luncheon once. When she discussed security, she asserted that
> there was no such thing as security which could not be breached.
> The goal of security efforts should not be to make it perfect,
> b
Robert Haas writes:
> On Wed, Oct 13, 2010 at 10:51 AM, Tom Lane wrote:
>> But the main point is that 6% performance penalty in a non-core function
>> is well below my threshold of pain.
> Well, then you have to wonder whether it's worth having the
> lesss-than-or-equal-to version around at all.
Andrew Dunstan writes:
> +1. Preserving the comments when you change the value could make the
> comments totally bogus. Separating machine-generated values into a
> separate file makes plenty of sense to me.
> Which one wins, though? I can see cases being made for both.
IIRC the proposal was t
KaiGai Kohei wrote:
> Previous security researcher pointed out security is trading-off,
> not all-or-nothing. If we can plug most part of the threat with
> reasonable performance degrading, it is worthwhile to fix up.
I had the pleasure of hearing Admiral Grace Hopper[1] speak at an
ACM lunche
On Wed, Oct 13, 2010 at 10:51 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of mié oct 13 10:32:36 -0300 2010:
>>> Robert Haas writes:
I spent some time hacking on this. It doesn't appear to be too easy
to get levenshtein_less_equal() working without
On 13 October 2010 13:45, Jan Otto wrote:
> we can only prove self-consistency, because there is no algorithm behind
> the scene. the ranges gets applied to publishers depending on how much
> books they publishing over time and probably other criteria.
What about the issue I raised about new rang
Alvaro Herrera writes:
> Also, if upgrading is necessary, there will need to be one "upgrade"
> control file that says how to upgrade from version N to N+1.
> I don't think we should really support the downgrade case. It has the
> potential to get too messy -- and for what gain?
I think we coul
On Mon, 2010-10-11 at 11:07 -0700, Josh Berkus wrote:
> Absolutely. For a synch standby, you can't tolerate any standby delay
> at all. This means that anywhere from 1/4 to 3/4 of queries on the
> standby would be cancelled on any high-traffic OLTP server. Hence,
> "useless".
Don't agree with
On 10/13/2010 10:25 AM, Tom Lane wrote:
Robert Haas writes:
You're not alone on this at all: I agree 100%. I don't like your
proposed syntax, but I completely agree with your concern. I don't
see what's wrong with having the initial contents of postgresql.conf
look like this (these are the
On Thu, 2010-10-07 at 11:05 -0700, Josh Berkus wrote:
> Simon, Fujii,
>
> What follows are what I see as the major issues with making two-server
> synch replication work well. I would like to have you each answer them,
> explaining how your patch and your design addresses each issue. I
> believe
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié oct 13 10:32:36 -0300 2010:
>> Robert Haas writes:
>>> I spent some time hacking on this. It doesn't appear to be too easy
>>> to get levenshtein_less_equal() working without slowing down plain old
>>> levenshtein() by about 6%.
>
Excerpts from David Fetter's message of mié oct 13 11:27:56 -0300 2010:
> On Tue, Oct 12, 2010 at 08:57:09PM +0200, Dimitri Fontaine wrote:
> > - Extension Upgrading
> >
> >Should this be done by means of 'create extension' or some other
> >command, like 'alter extension foo upgrade'? Th
(2010/10/13 22:43), Tom Lane wrote:
> Robert Haas writes:
>> With the possible exception of Tom,
>> everyone seems to agree that it would be a good step forward to
>> provide a way of plugging these holes, even if it didn't cover subtler
>> information leaks such as by reading the EXPLAIN output o
On Tue, Oct 12, 2010 at 08:57:09PM +0200, Dimitri Fontaine wrote:
> Hi,
>
> Please find attached a WIP patch for extension's pg_dump support in
> PostgreSQL, following design decisions that we've outlined earlier at
> this year's and last year's PGCon developer meetings.
>
> What's in the patch?
Robert Haas writes:
> You're not alone on this at all: I agree 100%. I don't like your
> proposed syntax, but I completely agree with your concern. I don't
> see what's wrong with having the initial contents of postgresql.conf
> look like this (these are the settings that are uncommented by defa
Excerpts from Tom Lane's message of mié oct 13 10:32:36 -0300 2010:
> Robert Haas writes:
> > I spent some time hacking on this. It doesn't appear to be too easy
> > to get levenshtein_less_equal() working without slowing down plain old
> > levenshtein() by about 6%.
>
> Is that really enough sl
On mån, 2010-10-11 at 18:44 -0700, Greg Stark wrote:
> So we've been over this. All the pieces you need are already there:
> you can handle this without any nasty comment grunging by just writing
> the new setting to a postgresql.auto and including that from
> postgresql.conf. Include a note in pos
Robert Haas writes:
> With the possible exception of Tom,
> everyone seems to agree that it would be a good step forward to
> provide a way of plugging these holes, even if it didn't cover subtler
> information leaks such as by reading the EXPLAIN output or timing
> query execution.
> 1. Does any
Robert Haas writes:
> I spent some time hacking on this. It doesn't appear to be too easy
> to get levenshtein_less_equal() working without slowing down plain old
> levenshtein() by about 6%.
Is that really enough slowdown to be worth contorting the code to avoid?
I've never heard of an applicat
On Wed, Oct 13, 2010 at 3:41 AM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> I agree with Josh's proposal: keep mechanically-generated settings in a
>> separate file, and don't even pretend to allow comments to be kept there.
>
> And then, when you SET PERMANENT knob TO value (or whatever the s
hi tom,
>> Peter Eisentraut asked Jan to produce a regression test for the ISN
>> contrib module, which he is apparently working on. I would like to see
>> him more clearly explaining how that will work though - so far, it's
>> really just been described in very broad strokes.
>
> Even more to th
hi peter,
> I would like to hear what people think of my observations about the
> design of contrib/isn. In particular, I'd like Jan Otto to contribute
> - he probably has more domain knowledge than I do. I haven't heard
> from Jan about the proposed regression test.
>
> In producing this patch,
Hi,
I'm looking for a way to reliably detect if it's a promoting
standby. This is neccessary for pgpool-II manage streaming replication
clusters. When primary goes down, standby *could* start promoting to
primary. The only way to find it is calling
pg_is_in_recovery(). Problem is, it returns true
2010/10/13 Pavel Stehule :
> 2010/10/13 Peter Eisentraut :
>> On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
>>> The problem is in interface. The original patch did it, but I removed
>>> it. We cannot to unsure immutability of some parameters now.
>>
>> How about you store the "immutable"
2010/10/13 Peter Eisentraut :
> On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
>> The problem is in interface. The original patch did it, but I removed
>> it. We cannot to unsure immutability of some parameters now.
>
> How about you store the "immutable" parameter in the transition state
On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
> The problem is in interface. The original patch did it, but I removed
> it. We cannot to unsure immutability of some parameters now.
How about you store the "immutable" parameter in the transition state
and error out if it changes between c
Hello
I am looking on SQL standard for some info about "within group"
clause. This clause is necessary for functions:
rank, dense_rank, cume_dist, percent_rank and percentile_disc and
persentile_cont. These functions needs a clause "WITHIN GROUP".
If I understand, then these functions are not si
On Wed, Oct 13, 2010 at 3:50 PM, Robert Haas wrote:
> There's another problem here we should think about, too. Suppose you
> have a master and two standbys. The master dies. You promote one of
> the standbys, which turns out to be behind the other. You then
> repoint the other standby at the o
On Wed, Oct 13, 2010 at 3:43 PM, Heikki Linnakangas
wrote:
> On 13.10.2010 08:21, Fujii Masao wrote:
>>
>> On Sat, Oct 9, 2010 at 4:31 AM, Heikki Linnakangas
>> wrote:
>>>
>>> It shouldn't be too hard to fix. Walsender needs to be able to read WAL
>>> from
>>> preceding timelines, like recovery
On 10/13/2010 06:43 AM, Fujii Masao wrote:
> Unfortunately even enough standbys don't increase write-availability
> unless you choose wait-forever. Because, after promoting one of
> standbys to new master, you must keep all the transactions waiting
> until at least one standby has connected to and
Tom Lane writes:
> I agree with Josh's proposal: keep mechanically-generated settings in a
> separate file, and don't even pretend to allow comments to be kept there.
And then, when you SET PERMANENT knob TO value (or whatever the syntax
is), you never know what value is selected at next startup
On Fri, Oct 8, 2010 at 3:05 AM, Josh Berkus wrote:
> Adding a Synch Standby
> ---
> What is the procedure for adding a new synchronous standby in your
> implementation? That is, how do we go from having a standby server with
> an empty PGDATA to having a working synchronous st
56 matches
Mail list logo
