Robert Haas writes:
> I think the only part of this that would be really brutal to try to
> represent is alternative join orders. I see no reasonable way for
> EXPLAIN to output useful information about what other join orders were
> considered and why they were not chosen; the only thing that see
On Fri, Sep 9, 2016 at 12:35 AM, Tom Lane wrote:
> Craig Ringer writes:
>> On 9 September 2016 at 01:40, Roger Pack wrote:
>>> Today's explain tells us what loops and scans were used, and relative
>>> costs, etc. It doesn't seem to tell *why* the planner elected to use
>>> what it did.
>
>> One
On 9/8/16 11:35 PM, Tom Lane wrote:
This isn't simple because there are often *lots* of variants. You
> don't just want to see the "top 10" candidate plans, because they're
> probably a bunch of small variants on the same plan; the ones you'll
> be interested in will probably be very different pl
On Thu, Sep 8, 2016 at 10:40 AM, Roger Pack wrote:
> My apologies if this was already requested before...
>
> I think it would be fantastic if postgres had an "explain the explain"
> option:
> Today's explain tells us what loops and scans were used, and relative
> costs, etc. It doesn't seem to
Craig Ringer writes:
> On 9 September 2016 at 01:40, Roger Pack wrote:
>> Today's explain tells us what loops and scans were used, and relative
>> costs, etc. It doesn't seem to tell *why* the planner elected to use
>> what it did.
> One thing that's been discussed here is to have a way to see
On 9 September 2016 at 01:40, Roger Pack wrote:
> My apologies if this was already requested before...
>
> I think it would be fantastic if postgres had an "explain the explain" option:
> Today's explain tells us what loops and scans were used, and relative
> costs, etc. It doesn't seem to tell *
My apologies if this was already requested before...
I think it would be fantastic if postgres had an "explain the explain" option:
Today's explain tells us what loops and scans were used, and relative
costs, etc. It doesn't seem to tell *why* the planner elected to use
what it did.
For instance
Although this is getting slightly off the original topic, rereading .psqlrc
is a potential can of worms. What triggers a reread? What portions of
.psqlrc are re-read?
For example, say I have just set tuples-only, extended-display, or output
file. Would they all get reset just because I changed con
Jerry Sievers wrote:
> Steve Crawford writes:
>
> > That is almost identical to the solution I suggested a week or two ago to
> > someone tackling the issue and the hack works on initial connection.
> >
> > Connect to a different cluster with "\c", however, and it will leave the
> > prompt show
Steve Crawford writes:
> That is almost identical to the solution I suggested a week or two ago to
> someone tackling the issue and the hack works on initial connection.
>
> Connect to a different cluster with "\c", however, and it will leave the
> prompt showing you connected to the original d
That is almost identical to the solution I suggested a week or two ago to
someone tackling the issue and the hack works on initial connection.
Connect to a different cluster with "\c", however, and it will leave the
prompt showing you connected to the original database which is not good.
Cheers,
Peter Eisentraut writes:
> On 5/5/16 9:21 PM, Steve Crawford wrote:
>
>> Adding an escape sequence that references cluster_name would enable
>> prompts to identify the cluster in a manner that is both consistent and
>> distinct regardless of access path.
>
> I think that would be a good idea. Yo
On 5/5/16 9:21 PM, Steve Crawford wrote:
Adding an escape sequence that references cluster_name would enable
prompts to identify the cluster in a manner that is both consistent and
distinct regardless of access path.
I think that would be a good idea. You could probably design it so that
any
It's great that 9.5 has the new cluster_name variable as an available GUC.
It would be even better to make that GUC available for use in psql
prompting escape sequences.
Prompting via sequences utilizing %M, %m and %> means the same cluster
could be identified numerous ways (local, 127.0.0.1, 10.
On Fri, Jan 17, 2014 at 4:53 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > Applied, thanks!
>
> Minor bikeshedding: the messages would read better, to my eye, as
>
> "user=%s database=%s SSL enabled (protocol=%s, cipher=%s)"
>
> Putting "enabled" where it is requires extra mental gymnastics
Magnus Hagander writes:
> Applied, thanks!
Minor bikeshedding: the messages would read better, to my eye, as
"user=%s database=%s SSL enabled (protocol=%s, cipher=%s)"
Putting "enabled" where it is requires extra mental gymnastics on
the part of the reader. And why the random change between "=
On Sun, Dec 8, 2013 at 10:27 AM, Marko Kreen wrote:
> On Fri, Dec 06, 2013 at 02:53:27PM +0100, Dr. Andreas Kunert wrote:
> > >>Anything else missing?
> > >
> > >Functionally it's fine now, but I see few style problems:
> > >
> > >- "if (port->ssl > 0)" is wrong, ->ssl is pointer. So use just
>
On Fri, Dec 06, 2013 at 02:53:27PM +0100, Dr. Andreas Kunert wrote:
> >>Anything else missing?
> >
> >Functionally it's fine now, but I see few style problems:
> >
> >- "if (port->ssl > 0)" is wrong, ->ssl is pointer. So use just
> > "if (port->ssl)".
> >- Deeper indentation would look nicer wit
Anything else missing?
Functionally it's fine now, but I see few style problems:
- "if (port->ssl > 0)" is wrong, ->ssl is pointer. So use just
"if (port->ssl)".
- Deeper indentation would look nicer with braces.
- There are some duplicated message, could you restructure it so that
each
On Fri, Dec 06, 2013 at 11:43:55AM +0100, Dr. Andreas Kunert wrote:
> >>That seems useful. Do we need more information, like whether a client
> >>certificate was presented, or what ciphers were used?
> >
> >Yes, please show ciphersuite and TLS version too. Andreas, you can use my
> >recent \conni
That seems useful. Do we need more information, like whether a client
certificate was presented, or what ciphers were used?
Yes, please show ciphersuite and TLS version too. Andreas, you can use my
recent \conninfo patch as template:
https://github.com/markokr/postgres/commit/7d1b27ac7464
On Thu, Dec 05, 2013 at 09:43:31AM -0500, Peter Eisentraut wrote:
> On 12/5/13, 8:53 AM, Dr. Andreas Kunert wrote:
> > we were really missing the information in our log files if (and which
> > of) our users are using SSL during their connections.
> >
> > The attached patch is a very simple solutio
On 12/5/13, 8:53 AM, Dr. Andreas Kunert wrote:
> we were really missing the information in our log files if (and which
> of) our users are using SSL during their connections.
>
> The attached patch is a very simple solution to this problem - it just
> tests if the ssl pointer in Port is null. If n
Hello,
we were really missing the information in our log files if (and which
of) our users are using SSL during their connections.
The attached patch is a very simple solution to this problem - it just
tests if the ssl pointer in Port is null. If no, it adds "SSL" to the
logfile, otherwise i
On Tue, Nov 5, 2013 at 11:55 PM, Tom Lane wrote:
> Joe Love writes:
>> I'm wondering what type of index would work for this as it is a volatile
>> function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
>> wouldn't be possible or worth doing. It seems to me that all functions i
Joe Love writes:
> I'm wondering what type of index would work for this as it is a volatile
> function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
> wouldn't be possible or worth doing. It seems to me that all functions in
> the "select" part of the statement could be calcula
I'm wondering what type of index would work for this as it is a volatile
function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
wouldn't be possible or worth doing. It seems to me that all functions in
the "select" part of the statement could be calculated at the end of the
quer
Atri Sharma writes:
> I understand the reasons for executing SELECT before the sort. But,
> couldnt we get the planner to see the LIMIT part and push the sort
> node above the select node for this specific case?
[ Shrug... ] I don't see the point. If the OP actually cares about the
speed of thi
On Sat, Nov 2, 2013 at 2:00 AM, Tom Lane wrote:
> Jim Nasby writes:
>> On Oct 31, 2013, at 11:04 AM, Joe Love wrote:
>>> In postgres 9.2 I have a function that is relatively expensive. When I
>>> write a query such as:
>>>
>>> select expensive_function(o.id),o.* from offeirng o where valid='Y'
Jim Nasby-2 wrote
> Should that really matter in this case? ISTM we should always handle LIMIT
> before moving on to the SELECT clause…?
SELECT generate_series(1,10) LIMIT 1
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Feature-request-Optimizer-improvement
On Friday, November 1, 2013, Jim Nasby wrote:
> On Oct 31, 2013, at 2:57 PM, Kevin Grittner
> >
> wrote:
>
> Joe Love 'j...@primoweb.com');>> wrote:
>
> In postgres 9.2 I have a function that is relatively expensive.
>
>
> What did you specify in the COST clause on the CREATE FUNCTION
> statemen
Jim Nasby writes:
> On Oct 31, 2013, at 11:04 AM, Joe Love wrote:
>> In postgres 9.2 I have a function that is relatively expensive. When I
>> write a query such as:
>>
>> select expensive_function(o.id),o.* from offeirng o where valid='Y' order by
>> name limit 1;
> Does anyone know what th
On Oct 31, 2013, at 2:57 PM, Kevin Grittner wrote:
> Joe Love wrote:
>
>> In postgres 9.2 I have a function that is relatively expensive.
>
> What did you specify in the COST clause on the CREATE FUNCTION
> statement?
Should that really matter in this case? ISTM we should always handle LIMIT
On Oct 31, 2013, at 11:04 AM, Joe Love wrote:
> In postgres 9.2 I have a function that is relatively expensive. When I write
> a query such as:
>
> select expensive_function(o.id),o.* from offeirng o where valid='Y' order by
> name limit 1;
>
> the query runs slow and appears to be running th
In postgres 9.2 I have a function that is relatively expensive. When I
write a query such as:
select expensive_function(o.id),o.* from offeirng o where valid='Y' order
by name limit 1;
the query runs slow and appears to be running the function on each ID,
which in this case should be totally unn
Joe Love wrote:
> In postgres 9.2 I have a function that is relatively expensive.
What did you specify in the COST clause on the CREATE FUNCTION
statement?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hacke
In postgres 9.2 I have a function that is relatively expensive. When I
write a query such as:
select expensive_function(o.id),o.* from offeirng o where valid='Y' order
by name limit 1;
the query runs slow and appears to be running the function on each ID,
which in this case should be totally unn
On Mon, Aug 19, 2013 at 11:44:36PM +0200, Dimitri Fontaine wrote:
> Bruce Momjian writes:
> > That's pretty vague. Exactly what does "keys to the kingdom" mean? If
> > it means you can do anything to the database, you are right. If it
> > means executing arbitrary code, including arbitrary kern
Bruce Momjian writes:
> That's pretty vague. Exactly what does "keys to the kingdom" mean? If
> it means you can do anything to the database, you are right. If it
> means executing arbitrary code, including arbitrary kernel calls, I
> would like to hear how that is done.
You've now heard ab
On Mon, Aug 19, 2013 at 11:34:47AM +0200, Dimitri Fontaine wrote:
> Dave Page writes:
> > If you find a hole in the boat, the preferred option is to fix it, not
> > to say "meh, well another won't hurt".
>
> My understanding is that there's no way to fix it. If you're superuser
> you have the key
Dave Page writes:
> If you find a hole in the boat, the preferred option is to fix it, not
> to say "meh, well another won't hurt".
My understanding is that there's no way to fix it. If you're superuser
you have the keys to the kingdom. That's it.
And that's why it's very important that as many
On Mon, Aug 19, 2013 at 10:21 AM, Dimitri Fontaine
wrote:
> Dave Page writes:
>> The escalation happens because in a normal system-wide installation of
>> PostgreSQL as you'd see on most production systems will have the
>> installation directories and binaries owned by the root user, so if
>> the
Dave Page writes:
> The escalation happens because in a normal system-wide installation of
> PostgreSQL as you'd see on most production systems will have the
> installation directories and binaries owned by the root user, so if
> the server or a superuser account on it is compromised, the attacker
On Sun, Aug 18, 2013 at 10:34 PM, Hannu Krosing wrote:
> On 08/18/2013 10:20 PM, Dimitri Fontaine wrote:
>> Hi,
>>
>> I had the chance to being at OSCON this year and had a chat with the
>> Open Shift team while there. Thanks for posting your use case!
>>
>> Tom Lane writes:
>>> Right offhand, it
On 08/18/2013 10:20 PM, Dimitri Fontaine wrote:
> Hi,
>
> I had the chance to being at OSCON this year and had a chat with the
> Open Shift team while there. Thanks for posting your use case!
>
> Tom Lane writes:
>> Right offhand, it seems like you have or could grant a developer
>> superuser/DBA
Hi,
I had the chance to being at OSCON this year and had a chat with the
Open Shift team while there. Thanks for posting your use case!
Tom Lane writes:
> Right offhand, it seems like you have or could grant a developer
> superuser/DBA privileges with respect to his own PG instance, so I'm not
>
Steven Citron-Pousty writes:
> What we need is the ability for Postgresql to load extensions from a
> users file space.
TBH this needs a whole lot of thought. I'm prepared to grant that there
may be other useful security models besides the one we currently have,
but we need to be sure that anyth
On 08/18/2013 11:36 AM, Hannu Krosing wrote:
> On 08/17/2013 11:53 PM, Steven Citron-Pousty wrote:
>> Greetings all:
>> I spoke to Josh B and company at OSCON about a feature we really need
>> for PostgreSQL extensions on OpenShift (Red Hat's Platform as a
>> Service).
>>
>> What we need is the ab
On 08/17/2013 11:53 PM, Steven Citron-Pousty wrote:
> Greetings all:
> I spoke to Josh B and company at OSCON about a feature we really need
> for PostgreSQL extensions on OpenShift (Red Hat's Platform as a
> Service).
>
> What we need is the ability for Postgresql to load extensions from a
> user
On Sat, 2013-08-17 at 17:53 -0400, Steven Citron-Pousty wrote:
> What we need is the ability for Postgresql to load extensions from a
> users file space.
Sure, that would be useful for a number of reasons. I think there was a
proposed patch for that a while ago that some people objected to, so
th
Greetings all:
I spoke to Josh B and company at OSCON about a feature we really need for
PostgreSQL extensions on OpenShift (Red Hat's Platform as a Service).
What we need is the ability for Postgresql to load extensions from a users file
space. For example, if, as a developer on a machine, I
On 24 December 2012 17:15, Andres Freund wrote:
>> On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
>> > From all of the above, I think its worth doing this
>> > * allowing recovery.conf to be in a different directory
>> > * make recovery config parameters into GUCs
>> > * no other ch
On Thu, Jan 3, 2013 at 07:45:32PM +, Simon Riggs wrote:
> On 3 January 2013 18:35, Josh Berkus wrote:
> > Robert,
> >
> >> In my view, the biggest problem with recovery.conf is that the
> >> parameters in there are not GUCs, which means that all of the
> >> infrastructure that we've built for
On 3 January 2013 18:35, Josh Berkus wrote:
> Robert,
>
>> In my view, the biggest problem with recovery.conf is that the
>> parameters in there are not GUCs, which means that all of the
>> infrastructure that we've built for managing GUCs does not work with
>> them. As an example, when we conver
Robert,
> In my view, the biggest problem with recovery.conf is that the
> parameters in there are not GUCs, which means that all of the
> infrastructure that we've built for managing GUCs does not work with
> them. As an example, when we converted recovery.conf to use the same
> lexer that the G
On Wed, Dec 26, 2012 at 3:32 PM, Josh Berkus wrote:
>> There already are two ways to promote a server out of recovery. One is
>> creating the trigger file. The other is "pg_ctl promote". (it uses a
>> trigger file called $PGDATA/promote internally, but that's invisible to
>> the user).
>
> Right,
There already are two ways to promote a server out of recovery. One is
creating the trigger file. The other is "pg_ctl promote". (it uses a
trigger file called $PGDATA/promote internally, but that's invisible to
the user).
Right, I was thinking of the trigger file to put a server *into*
repli
On 26.12.2012 21:55, Josh Berkus wrote:
I'm not sure that my POV exactly matches up with Tom's, but on the
last point, I strongly agree that the use of the trigger file makes it
trivial to integrate Postgres warm standby management into 3rd party
tools. I'm not against coming up with a new API
I'm not sure that my POV exactly matches up with Tom's, but on the
last point, I strongly agree that the use of the trigger file makes it
trivial to integrate Postgres warm standby management into 3rd party
tools. I'm not against coming up with a new API that's better for
postgres dedicated tool
On Mon, Dec 24, 2012 at 7:04 PM, Tom Lane wrote:
> Josh Berkus writes:
>>> What the patch doesn't change is the requirement to have a file that
>>> causes the server to place itself into archive recovery. So there is
>>> no more recovery.conf and instead we have a file called
>>> recovery.trigger
Josh Berkus writes:
>> What the patch doesn't change is the requirement to have a file that
>> causes the server to place itself into archive recovery. So there is
>> no more recovery.conf and instead we have a file called
>> recovery.trigger instead.
> Requiring a file in order to make a server
Simon,
> What the patch doesn't change is the requirement to have a file that
> causes the server to place itself into archive recovery. So there is
> no more recovery.conf and instead we have a file called
> recovery.trigger instead.
Requiring a file in order to make a server a replica is what w
On 2012-12-24 18:06:44 +0100, Dimitri Fontaine wrote:
> Bruce Momjian writes:
> > Is that what everyone else wants? If that is all, let's do it and close
> > the item.
>
> What Simon is proposing is quite clear and not what you pasted, if I'm
> reading that correctly:
>
> On Mon, Dec 24, 2012 at
Bruce Momjian writes:
> Is that what everyone else wants? If that is all, let's do it and close
> the item.
What Simon is proposing is quite clear and not what you pasted, if I'm
reading that correctly:
On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
> From all of the above, I thin
On Mon, Dec 24, 2012 at 03:57:10PM +, Simon Riggs wrote:
> On 24 December 2012 15:48, Bruce Momjian wrote:
> > On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
> >> I don't think that represents enough change to keep people happy, but
> >> I don't see anything else useful being sug
On 24 December 2012 15:48, Bruce Momjian wrote:
> On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
>> I don't think that represents enough change to keep people happy, but
>> I don't see anything else useful being suggested in this patch. Other
>> design thoughts welcome, but personall
On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
> I don't think that represents enough change to keep people happy, but
> I don't see anything else useful being suggested in this patch. Other
> design thoughts welcome, but personally, I think rushing this design
> through at this stage
On 23 December 2012 15:24, Fujii Masao wrote:
> The latest patch is the following. Of course, this cannot be applied
> cleanly in HEAD.
> http://archives.postgresql.org/message-id/CAHGQGwHB==cjehme6jiuy-knutrx-k3ywqzieg1gpnb3ck6...@mail.gmail.com
>
>> Just by looking at the last few posts, this s
On Sat, Dec 22, 2012 at 5:14 AM, Heikki Linnakangas
wrote:
> On 21.12.2012 21:43, Simon Riggs wrote:
>>
>> On 21 December 2012 19:35, Bruce Momjian wrote:
>>
It's not too complex. You just want that to be true. The original
developer has actually literally gone away, but not because of
> Forgive me because I have been up for 28 hours on a 9.0 to 9.2 migration
> with Hot Standby and PgPool-II for load balancing but I was excessively
> irritated that I had to go into recovery.conf to configure things. I am
> one of the software authors that breaking recovery.conf will cause
> prob
On 12/21/2012 11:56 AM, Bruce Momjian wrote:
That is where we are now. Overhauling recovery.conf can't be a
super-complex job, and we already have a patch we can base it of off.
Why is this not done yet! I don't know, but I have seen lots of
discussion about it, and no clear conclusions, at l
On 21.12.2012 21:43, Simon Riggs wrote:
On 21 December 2012 19:35, Bruce Momjian wrote:
It's not too complex. You just want that to be true. The original
developer has actually literally gone away, but not because of this.
Well, Robert and I remember it differently.
Anyway, I will ask for a
On Fri, Dec 21, 2012 at 07:43:29PM +, Simon Riggs wrote:
> On 21 December 2012 19:35, Bruce Momjian wrote:
>
> >> It's not too complex. You just want that to be true. The original
> >> developer has actually literally gone away, but not because of this.
> >
> > Well, Robert and I remember it
On 21 December 2012 19:35, Bruce Momjian wrote:
>> It's not too complex. You just want that to be true. The original
>> developer has actually literally gone away, but not because of this.
>
> Well, Robert and I remember it differently.
>
> Anyway, I will ask for a vote now.
And what will you as
On Fri, Dec 21, 2012 at 07:32:48PM +, Simon Riggs wrote:
> On 21 December 2012 19:21, Bruce Momjian wrote:
> > On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
> >> On 20 December 2012 19:29, Bruce Momjian wrote:
> >>
> >> > At this point backward compatibility has paralyzed us fr
On 21 December 2012 19:21, Bruce Momjian wrote:
> On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
>> On 20 December 2012 19:29, Bruce Momjian wrote:
>>
>> > At this point backward compatibility has paralyzed us from fixing a
>> > recovery.conf API that everyone agrees is non-optimal,
On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
> On 20 December 2012 19:29, Bruce Momjian wrote:
>
> > At this point backward compatibility has paralyzed us from fixing a
> > recovery.conf API that everyone agrees is non-optimal, and this has
> > gone on for multiple major releases.
On 21 December 2012 14:09, Robert Haas wrote:
> On Thu, Dec 20, 2012 at 5:07 PM, Joshua Berkus wrote:
>>> As ever, we spent much energy on debating backwards compatibility
>>> rather than just solving the problem it posed, which is fairly easy
>>> to
>>> solve.
>>
>> Well, IIRC, the debate was pr
On 21 December 2012 17:12, Robert Haas wrote:
> On Fri, Dec 21, 2012 at 9:21 AM, Simon Riggs wrote:
>> No, lets not.
>>
>> The only stall happening is because of a refusal to listen to another
>> person's reasonable request during patch review. That requirement is
>> not a blocker to the idea, it
On Fri, Dec 21, 2012 at 9:21 AM, Simon Riggs wrote:
> No, lets not.
>
> The only stall happening is because of a refusal to listen to another
> person's reasonable request during patch review. That requirement is
> not a blocker to the idea, it just needs to be programmed.
>
> Lets just implement
On 20 December 2012 19:29, Bruce Momjian wrote:
> At this point backward compatibility has paralized us from fixing a
> recovery.conf API that everyone agrees is non-optimal, and this has
> gone on for multiple major releases. I don't care what we have to do,
> just clean this up for 9.3!
The m
On 20 December 2012 19:29, Bruce Momjian wrote:
> On Wed, Dec 19, 2012 at 10:34:14PM +, Simon Riggs wrote:
>> On 19 December 2012 22:19, Joshua Berkus wrote:
>> >
>> >> It stalled because the patch author decided not to implement the
>> >> request to detect recovery.conf in data directory, wh
On Thu, Dec 20, 2012 at 5:07 PM, Joshua Berkus wrote:
>> As ever, we spent much energy on debating backwards compatibility
>> rather than just solving the problem it posed, which is fairly easy
>> to
>> solve.
>
> Well, IIRC, the debate was primarily of *your* making. Almost everyone else
> on t
Andreas,
> Do you want the node one step up or the top-level in the chain?
> Because
> I don't think we can do the latter without complicating the
> replication
> protocol noticably.
Well, clearly a whole chain would be nice for the user. But even just one step
up would be very useful.
--Josh
On 2012-12-18 19:43:09 -0800, Josh Berkus wrote:
> We should probably have a function, like pg_replication_master(), which
> gives the host address of the current master. This would help DBAs for
> large replication clusters a lot. Obviously, this would only work in
> streaming.
Do you want the
> As ever, we spent much energy on debating backwards compatibility
> rather than just solving the problem it posed, which is fairly easy
> to
> solve.
Well, IIRC, the debate was primarily of *your* making. Almost everyone else on
the thread was fine with the original patch, and it was nearly d
> Let me also add that I am tired of having recovery.conf improvement
> stalled by backward compatibility concerns. At this point, let's just
> trash recovery.conf backward compatibility and move on.
>
> And I don't want to hear complaints about tool breakage either. These are
> external tools,
On Thu, Dec 20, 2012 at 02:29:49PM -0500, Bruce Momjian wrote:
> Let me also add that I am tired of having recovery.conf improvement
> stalled by backward compatibility concerns. At this point, let's just
> trash recovery.conf backward compatibility and move on.
>
> And I don't want to hear co
On Wed, Dec 19, 2012 at 10:34:14PM +, Simon Riggs wrote:
> On 19 December 2012 22:19, Joshua Berkus wrote:
> >
> >> It stalled because the patch author decided not to implement the
> >> request to detect recovery.conf in data directory, which allows
> >> backwards compatibility.
> >
> > Well,
On Wed, Dec 19, 2012 at 07:32:33PM -0500, Robert Haas wrote:
> On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs wrote:
> > As ever, we spent much energy on debating backwards compatibility
> > rather than just solving the problem it posed, which is fairly easy to
> > solve.
>
> I'm still of the opini
On Thursday, December 20, 2012 3:50 AM Joshua Berkus wrote:
>
> > It stalled because the patch author decided not to implement the
> > request to detect recovery.conf in data directory, which allows
> > backwards compatibility.
>
> Well, I don't think we had agreement on how important backwards
>
On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs wrote:
> As ever, we spent much energy on debating backwards compatibility
> rather than just solving the problem it posed, which is fairly easy to
> solve.
I'm still of the opinion (as were a lot of people on the previous
thread, IIRC) that just makin
On 19 December 2012 22:19, Joshua Berkus wrote:
>
>> It stalled because the patch author decided not to implement the
>> request to detect recovery.conf in data directory, which allows
>> backwards compatibility.
>
> Well, I don't think we had agreement on how important backwards compatibility
>
> This sounds like my previous suggestion of returning the primary
> conninfo value, but with just ip. That one came with a pretty bad
> patch, and was later postponed until we folded recovery.conf into
> the main configuration file parsing. I'm not really sure what
> happened to that project? (th
> It stalled because the patch author decided not to implement the
> request to detect recovery.conf in data directory, which allows
> backwards compatibility.
Well, I don't think we had agreement on how important backwards compatibility
for recovery.conf was, particularly not on the whole
reco
On 19 December 2012 06:10, Magnus Hagander wrote:
> This sounds like my previous suggestion of returning the primary conninfo
> value, but with just ip. That one came with a pretty bad patch, and was
> later postponed until we folded recovery.conf into the main configuration
> file parsing. I'm n
On Dec 19, 2012 4:43 AM, "Josh Berkus" wrote:
>
> Hackers,
>
> Currently we can see each master's current replicas using
> pg_stat_replication. However, there is no way from a replica, that I
> know of, to figure out who its master is other than to look at
> recovery.conf.
>
> We should probably
Hackers,
Currently we can see each master's current replicas using
pg_stat_replication. However, there is no way from a replica, that I
know of, to figure out who its master is other than to look at
recovery.conf.
We should probably have a function, like pg_replication_master(), which
gives the
Hello Folks,
I hope this is the right place to ask for this feature.
I have just started working with Postgres seriously, and I come from a SQL
Server background. In SQL Server when one develops complex stored
procedures, it is possible to see the query plans of the stored procedure,
even when th
On Wed, Aug 15, 2012 at 10:26:55PM -0400, Bruce Momjian wrote:
> On Mon, Nov 14, 2011 at 04:19:30PM -0600, Ross Reedstrom wrote:
> > On Wed, Sep 28, 2011 at 11:47:51AM -0700, David Fetter wrote:
> > > On Wed, Sep 28, 2011 at 02:25:44PM -0400, Gurjeet Singh wrote:
> > > > On Wed, Sep 28, 2011 at 1:5
1 - 100 of 379 matches
Mail list logo
