On Mon, Dec 10, 2012 at 11:21 PM, Jeff Davis pg...@j-davis.com wrote:
And I have a few other questions/comments:
* Why is summ spelled with two ms? Is it short for summation? If
so, might be good to use summation of instead of integrate in the
comment.
Fixed.
* Why does
Hello
What is state of this issue?
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00423.php
We detect this issue in our servers - we use 9.1.6 on Linux
locktype | database | relation | page | tuple | virtualxid |
transactionid | classid | objid | objsubid | virtualtransaction | pid
|
Hello,
I'm trying to print out the tuples in the b-tree nodes for analysis,
but when iterate over more than the first entry of the tuples
(scanKey++), I strangely get the error below on query execution:
ERROR: relation simpletest does not exist
LINE 1: SELECT * FROM simpletest WHERE id = 50;
On January 02, 2013 12:41 PM Hari Babu wrote:
On January 01, 2013 10:19 PM Boszormenyi Zoltan wrote:
I am reviewing your patch.
Is the patch in context diff format?
Yes.
Thanks for reviewing the patch.
Does it apply cleanly to the current git master?
Not quite cleanly but it doesn't
On Friday, December 28, 2012 3:52 PM Simon Riggs wrote:
On 28 December 2012 08:07, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Hello, I saw this patch and confirmed that
- Coding style looks good.
- Appliable onto HEAD.
- Some mis-codings are fixed.
I've had a
On 4 January 2013 13:53, Amit Kapila amit.kap...@huawei.com wrote:
On Friday, December 28, 2012 3:52 PM Simon Riggs wrote:
On 28 December 2012 08:07, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Hello, I saw this patch and confirmed that
- Coding style looks good.
-
On Mon, Dec 31, 2012 at 11:51 AM, Tomas Vondra t...@fuzzy.cz wrote:
I thought I followed the conding style - which guidelines have I broken?
+ /* If there are no non-local relations, then we're done. Release the
memory
+* and return. */
Multi-line comments should start with a
Pavel Stehule pavel.steh...@gmail.com writes:
What is state of this issue?
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00423.php
AFAICS we never identified the cause. It was pretty clear that
something was failing to clean up shared-memory lock data structures,
but not what that
On Mon, Dec 24, 2012 at 02:41:37AM +0100, Tomas Vondra wrote:
+ SMgrRelation *srels = palloc(sizeof(SMgrRelation));
+ int nrels = 0,
+ i = 0,
+ maxrels = 1;
maxrels=1 is not good -- too much palloc traffic.
On Fri, Dec 28, 2012 at 1:21 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Now, as to the question of whether we need to make sure that
everything is always fully qualified - I respectfully disagree with
Stephen, and maintain my position set out in the last round of
feedback [1], which is
2013/1/4 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
What is state of this issue?
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00423.php
AFAICS we never identified the cause. It was pretty clear that
something was failing to clean up shared-memory
On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Ascertaining the identity of the object in question perfectly
unambiguously, so that you can safely do something like lookup a
comment on the object, seems like something way beyond what I'd
envisioned for this
Robert Haas robertmh...@gmail.com schrieb:
On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan
pe...@2ndquadrant.com wrote:
Ascertaining the identity of the object in question perfectly
unambiguously, so that you can safely do something like lookup a
comment on the object, seems like something
Hi,
I am reviewing your patch.
2012-12-10 13:58 keltezéssel, Amit kapila írta:
On Thu, 6 Dec 2012 10:12:31 +0530 Amit Kapila wrote:
On Tuesday, December 04, 2012 8:37 AM Amit Kapila wrote:
On Monday, December 03, 2012 8:59 PM Tom Lane wrote:
Robert Haas robertmhaas(at)gmail(dot)com writes:
2013-01-04 18:27 keltezéssel, Boszormenyi Zoltan írta:
One specific comment about the documentation part of the patch:
***
*** 86,92 SET [ SESSION | LOCAL ] TIME ZONE { replaceable
class=PARAMETERtimezone/rep
applicationPL/pgSQL/application exception block. This
On 1/3/13 3:26 PM, Robert Haas wrote:
It's true, as we've often
said here, that leveraging the OS facilities means that we get the
benefit of improving OS facilities for free - but it also means that
we never exceed what the OS facilities are able to provide.
And that should be the deciding
anara...@anarazel.de and...@anarazel.de writes:
Robert Haas robertmh...@gmail.com schrieb:
The people who are content to do that don't need this patch at all.
They can just apply a regexp to the message that comes back from the
server and then set constraint_name based on what pops out of the
On 1/3/13 12:30 PM, Robert Haas wrote:
On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander mag...@hagander.net wrote:
Any particular reason? It goes pretty tightly together with
pg_receivexlog, which is why I'd prefer putting it alongside that one.
But if you have a good argument against it, I
I did three back-to-back runs using the same settings as in
http://archives.postgresql.org/pgsql-performance/2012-11/msg7.php
Except:
- use no prepared statement
- use 40 db connections
- build source from postgresql.git on the server box using: REL9_1_7,
REL9_2_2, REL9_2_2 + this patch
NOTPM
Dong Ye y...@vmware.com writes:
I did three back-to-back runs using the same settings as in
http://archives.postgresql.org/pgsql-performance/2012-11/msg7.php
Except:
- use no prepared statement
- use 40 db connections
- build source from postgresql.git on the server box using: REL9_1_7,
2013/1/4 Tom Lane t...@sss.pgh.pa.us:
Dong Ye y...@vmware.com writes:
I did three back-to-back runs using the same settings as in
http://archives.postgresql.org/pgsql-performance/2012-11/msg7.php
Except:
- use no prepared statement
- use 40 db connections
- build source from
Next question is what people think about back-patching into 9.2 so as
to eliminate the performance regression vs 9.1. I believe this would
be safe (although some care would have to be taken to put the added
boolean fields into places where they'd not result in an ABI break).
However it may
On 04.01.2013 22:05, Josh Berkus wrote:
Next question is what people think about back-patching into 9.2 so as
to eliminate the performance regression vs 9.1. I believe this would
be safe (although some care would have to be taken to put the added
boolean fields into places where they'd not
Samuel Vogel s...@muel-vogel.de writes:
I'm trying to print out the tuples in the b-tree nodes for analysis, but
when iterate over more than the first entry of the tuples (scanKey++), I
strangely get the error below on query execution:
ERROR: relation simpletest does not exist
LINE 1:
On 01/04/2013 12:05 PM, Josh Berkus wrote:
Next question is what people think about back-patching into 9.2 so as
to eliminate the performance regression vs 9.1. I believe this would
be safe (although some care would have to be taken to put the added
boolean fields into places where they'd
Hello
2013/1/4 Andrew Dunstan and...@dunslane.net:
On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan and...@dunslane.net
wrote:
Here is a patch for the first part of the JSON API that was recently
On 01/04/2013 03:36 PM, Pavel Stehule wrote:
Hello
2013/1/4 Andrew Dunstan and...@dunslane.net:
On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan and...@dunslane.net
wrote:
Here is a patch for the
Dimitri Fontaine escribió:
Robert Haas robertmh...@gmail.com writes:
OK, I committed this.
Thanks. Please find attached a rebased patch, v6. I think it's looking
more like what you would expect now:
I gave this patch a look. I'm not done with it; I mostly gave the
utility.c changes some
Alvaro Herrera escribió:
I gave this patch a look. I'm not done with it; I mostly gave the
utility.c changes some love so that the end result is not as cluttered.
I did this by creating a couple of macros that call the Start() thing,
then set the OID, then call the End() thing. This made
2013/1/4 Andrew Dunstan and...@dunslane.net:
On 01/04/2013 03:36 PM, Pavel Stehule wrote:
Hello
2013/1/4 Andrew Dunstan and...@dunslane.net:
On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan
Josh Berkus j...@agliodbs.com writes:
Next question is what people think about back-patching into 9.2 so as
to eliminate the performance regression vs 9.1.
8% is a pretty serious regression, for those of us with applications
which do a lot of dynamic SQL. As a reminder, many people do
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I gave this patch a look. I'm not done with it; I mostly gave the
utility.c changes some love so that the end result is not as cluttered.
Thanks Álvaro!
I did this by creating a couple of macros that call the Start() thing,
then set the OID,
Robert Haas robertmh...@gmail.com writes:
Mostly that it seems like a hack, and I suspect we may come up with a
better way to do this in the future.
Do you have the specs of such better way? Would it be a problem to have
both pg_retainxlog and the new way?
--
Dimitri Fontaine
On 01/04/2013 01:17 PM, Tom Lane wrote:
Well, of course, people with that type of problem should probably
rethink their use of dynamic SQL when they move to 9.2 anyway, because
that's the case where the new plancache code could actually help them
if they'd only let it.
Not to further the
On 4 January 2013 18:07, Tom Lane t...@sss.pgh.pa.us wrote:
Exactly. To my mind, the *entire* point of this patch is to remove the
need for people to try to dig information out of potentially-localized
message strings. It's not clear to me that we have to strain to provide
information that
On 4 January 2013 17:10, Robert Haas robertmh...@gmail.com wrote:
I don't really agree with this. To be honest, my biggest concern
about this patch is that it will make it take longer to report an
error. At least in the cases where these additional fields are
included, it will take CPU time
Well, of course, people with that type of problem should probably
rethink their use of dynamic SQL when they move to 9.2 anyway, because
that's the case where the new plancache code could actually help them
if they'd only let it.
Oh, no question. But it'll take time for users with 1000's of
On 4 January 2013 22:42, Tom Lane t...@sss.pgh.pa.us wrote:
Invent a one-shot variant of CachedPlans for better performance.
...
Back-patch to 9.2, since this was a performance regression compared to 9.1.
(In 9.2, place the added struct fields so as to avoid changing the offsets
of existing
On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote:
Hi,
I am reviewing your patch.
Thank you very much.
Since you are using a constant string, it would be a little faster
to use sizeof(string)-1 as it can be computed at compile-time
and not run the strlen() all the time this
2013-01-05 05:58 keltezéssel, Amit kapila írta:
On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote:
Hi,
I am reviewing your patch.
Thank you very much.
Since you are using a constant string, it would be a little faster
to use sizeof(string)-1 as it can be computed at compile-time
40 matches
Mail list logo
