Hi,
On 28/01/14 22:35, Tom Lane wrote:
Absolutely. Probably best to save errno into a local just before the
ereport.
I think just resetting to edata-saved_errno is better and sufficient?
-1 --- that field is nobody's business except elog.c's.
Ok, so I propose the attached patch as a
On 28th January, Mitsumasa KONDO wrote:
2014-01-26 Simon Riggs si...@2ndquadrant.com
mailto:si...@2ndquadrant.com
On 21 January 2014 19:48, Simon Riggs si...@2ndquadrant.com
mailto:si...@2ndquadrant.com wrote:
On 21 January 2014 12:54, KONDO Mitsumasa
I'll elaborate on the use case. I have OCR scanned text for a large amounts
of images, corresponding to one row per image. I want to match against
words in another table. I need two results sets, one with all matched words
and one with only the first matched word within the first 50 chars of the
On Tue, Jan 28, 2014 at 8:17 PM, Stephen Frost sfr...@snowman.net wrote:
Greg,
* Greg Stark (st...@mit.edu) wrote:
On Tue, Jan 28, 2014 at 11:56 AM, Josh Berkus j...@agliodbs.com wrote:
For example, I would really like to GRANT an unpriv user access to the
WAL columns in
On 28 January 2014 20:16, Florian Pflug f...@phlo.org wrote:
On Jan27, 2014, at 23:28 , Dean Rasheed dean.a.rash...@gmail.com wrote:
strict transfn vs non-strict inv_transfn
This case is explicitly forbidden, both in CREATE AGGREGATE and in the
On Wed, Jan 29, 2014 at 9:03 AM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
(2014/01/29 15:51), Tom Lane wrote:
KONDO Mitsumasa kondo.mitsum...@lab.ntt.co.jp writes:
By the way, latest pg_stat_statement might affect performance in
Windows system.
Because it uses fflush() system
Hello,
I initially tried to keep track of them by allocating read pointers on the
tuple store, but it turned out to be so expensive that I had to find another
way (24bytes per stored tuple, which are not reclaimable until the end of
the transaction).
What do you think about this approach ?
On Wed, Jan 29, 2014 at 8:58 AM, Peter Geoghegan p...@heroku.com wrote:
I am not opposed in principle to adding new things to the counters
struct in pg_stat_statements. I just think that the fact that the
overhead of installing the module on a busy production system is
currently so low is of
Andreas Karlsson wrote:
On 01/28/2014 10:56 PM, Andres Freund wrote:
On 2014-01-28 21:48:09 +, Thom Brown wrote:
On 28 January 2014 21:37, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas robertmh...@gmail.com
wrote:
The point of Andres's patch set
On 01/29/2014 03:34 PM, Kouhei Kaigai wrote:
Kouhei Kaigai kai...@ak.jp.nec.com writes:
Let me ask an elemental question. What is the reason why inheritance
expansion logic should be located on the planner stage, not on the
tail of rewriter?
I think it's mostly historical. You would however
Hello Robert,
I'm not particularly in favor of implementing this as client-side
functionality, because then it's only available to people who use that
particular client. Simon Riggs proposed a server-side option to the
DROP DATABASE command some time ago, and I think that might be the way
to
On 01/28/2014 07:01 PM, Heikki Linnakangas wrote:
On 01/27/2014 07:03 PM, Amit Kapila wrote:
I have tried to improve algorithm in another way so that we can get
benefit of same chunks during find match (something similar to lz).
The main change is to consider chunks at fixed boundary (4 byte)
Hi Pavel,
Now the patch looks good to me. However when I try to restore your own sql
file's dump, I get following errors:
pg_restore: [archiver (db)] could not execute query: ERROR: relation
public.emp does not exist
Command was: DROP TRIGGER IF EXISTS emp_insert_trigger ON public.emp;
2014-01-29 Jeevan Chalke jeevan.cha...@enterprisedb.com
Hi Pavel,
Now the patch looks good to me. However when I try to restore your own sql
file's dump, I get following errors:
pg_restore: [archiver (db)] could not execute query: ERROR: relation
public.emp does not exist
Command
On 28 January 2014 21:28, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 28, 2014 at 5:02 AM, Simon Riggs si...@2ndquadrant.com wrote:
I agree that this is being seen the wrong way around. The planner
contains things it should not do, and as a result we are now
discussing enhancing the
On 01/28/2014 07:34 PM, Thom Brown wrote:
And I'd be fine with being admin again this year, unless there's
anyone else who would like to take up the mantle?
Please do, thanks!
Who would be up for mentoring this year?
I can mentor.
- Heikki
--
Sent via pgsql-hackers mailing list
On 29 January 2014 06:43, Tom Lane t...@sss.pgh.pa.us wrote:
Actually though, isn't this issue mostly about inheritance of a query
*target* table?
Exactly. IMHO updateable views on inheritance sets will have multiple
other performance problems, so trying to support them here will not
make
On 01/23/2014 06:06 PM, Dean Rasheed wrote:
On 21 January 2014 09:18, Dean Rasheed dean.a.rash...@gmail.com wrote:
Yes, please review the patch from 09-Jan
(http://www.postgresql.org/message-id/CAEZATCUiKxOg=voovja2s6g-sixzzxg18totggp8zobq6qn...@mail.gmail.com).
After further testing I
On 01/28/2014 06:11 PM, Christian Kruse wrote:
Hi,
attached you will find a new version of the patch, ported to HEAD,
fixed the mentioned bug and - hopefully - dealing the the remaining
issues.
Thanks, I have committed this now.
The documentation is still lacking. We should explain somewhere
On 29 January 2014 11:27, Simon Riggs si...@2ndquadrant.com wrote:
On 29 January 2014 06:43, Tom Lane t...@sss.pgh.pa.us wrote:
Actually though, isn't this issue mostly about inheritance of a query
*target* table?
Exactly. IMHO updateable views on inheritance sets will have multiple
other
On Wed, Jan 29, 2014 at 3:41 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 01/28/2014 07:01 PM, Heikki Linnakangas wrote:
On 01/27/2014 07:03 PM, Amit Kapila wrote:
I have tried to improve algorithm in another way so that we can get
benefit of same chunks during find match
On 29 January 2014 11:34, Craig Ringer cr...@2ndquadrant.com wrote:
On 01/23/2014 06:06 PM, Dean Rasheed wrote:
On 21 January 2014 09:18, Dean Rasheed dean.a.rash...@gmail.com wrote:
Yes, please review the patch from 09-Jan
While transforming the LIKE clause in transformTableLikeClause(), the
function does remap the varattnos of the constraint expression.
838│
839│ ccbin_node =
map_variable_attnos(stringToNode(ccbin),
840│
1, 0,
841│
attmap, tupleDesc-natts,
842│
found_whole_row);
So,
On Mon, Jan 27, 2014 at 7:14 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
FDW's join pushing down is one of the valuable use-cases of this interface,
but not all. As you might know, my motivation is to implement GPU
acceleration
feature on top of this interface, that offers alternative way
On Jan29, 2014, at 09:59 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 28 January 2014 20:16, Florian Pflug f...@phlo.org wrote:
On Jan27, 2014, at 23:28 , Dean Rasheed dean.a.rash...@gmail.com wrote:
This case is explicitly forbidden, both in CREATE AGGREGATE and in the
executor. To me,
On 29 January 2014 06:43, Tom Lane t...@sss.pgh.pa.us wrote:
Kouhei Kaigai kai...@ak.jp.nec.com writes:
Let me ask an elemental question. What is the reason why inheritance
expansion logic should be located on the planner stage, not on the tail
of rewriter?
I think it's mostly historical.
On 29 January 2014 09:16, Magnus Hagander mag...@hagander.net wrote:
On Wed, Jan 29, 2014 at 8:58 AM, Peter Geoghegan p...@heroku.com wrote:
I am not opposed in principle to adding new things to the counters
struct in pg_stat_statements. I just think that the fact that the
overhead of
Hi all,
The undocumented GUC called xloginsert_slots has been introduced by
commit 9a20a9b. It is mentioned by the commit that this parameter
should be removed before the release. Wouldn't it be a good time to
remove this parameter soon? I imagine that removing it before the beta
would make sense
Hi,
On 2014-01-29 21:59:05 +0900, Michael Paquier wrote:
The undocumented GUC called xloginsert_slots has been introduced by
commit 9a20a9b. It is mentioned by the commit that this parameter
should be removed before the release. Wouldn't it be a good time to
remove this parameter soon? I
2014-01-29 Christian Convey christian.con...@gmail.com:
On Mon, Jan 27, 2014 at 7:14 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
FDW's join pushing down is one of the valuable use-cases of this
interface,
but not all. As you might know, my motivation is to implement GPU
acceleration
On Sat, Jan 25, 2014 at 5:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
I think that it's time to rename all the variables related to
pg_stat_bgwriter.
For example, it's better to change PgStat_GlobalStats to PgStat_Bgwriter.
I think that it's okay to make this change as separate patch,
On Wed, Jan 29, 2014 at 10:38 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Jan 25, 2014 at 5:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
I think that it's time to rename all the variables related to
pg_stat_bgwriter.
For example, it's better to change PgStat_GlobalStats to
On 01/28/2014 02:11 PM, Craig Ringer wrote:
My first thought is to add a boolean flag to RangeTblEntry (similar to
the inh flag) to say whether RLS expansion is requested for that
RTE. Then set it to false on each RTE as you add new RLS quals to it's
securityQuals.
That's what I was
On 01/29/2014 01:12 PM, Heikki Linnakangas wrote:
On 01/28/2014 06:11 PM, Christian Kruse wrote:
Hi,
attached you will find a new version of the patch, ported to HEAD,
fixed the mentioned bug and - hopefully - dealing the the remaining
issues.
Thanks, I have committed this now.
The
On 01/29/2014 02:58 AM, Peter Geoghegan wrote:
I am not opposed in principle to adding new things to the counters
struct in pg_stat_statements. I just think that the fact that the
overhead of installing the module on a busy production system is
currently so low is of *major* value, and
On 01/29/2014 04:01 PM, Vik Fearing wrote:
On 01/29/2014 01:12 PM, Heikki Linnakangas wrote:
The documentation is still lacking.
The documentation is indeed lacking since it breaks the build.
doc/src/sgml/config.sgml contains the line
normal allocation if that fails. With
On Tue, Jan 28, 2014 at 11:01 PM, salah jubeh s_ju...@yahoo.com wrote:
Hello Sawada,
- This patch is not patched to master branch
Sorry, My mistake
//new connections are not allowed
Corrected.
I hope now the patch in better state, if somthing left, I will be glad to
fix it
Regards
On
On Tue, Jan 28, 2014 at 5:58 AM, Christian Kruse
christ...@2ndquadrant.com wrote:
Hi,
On 28/01/14 13:51, Heikki Linnakangas wrote:
Oh darn, I remembered we had already committed this, but clearly not. I'd
love to still get this into 9.4. The latest patch (hugepages-v5.patch) was
pretty much
On 01/29/2014 02:21 PM, Amit Kapila wrote:
On Wed, Jan 29, 2014 at 3:41 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
For example, if the new tuple is an exact copy of the old tuple,
except for one additional byte in the beginning, the algorithm would fail to
recognize that. It would be
On 29 January 2014 12:20, Dean Rasheed dean.a.rash...@gmail.com wrote:
@Dean: If we moved that to rewriter, would expand_security_quals() and
preprocess_rowmarks() also move?
Actually I tend to think that expand_security_quals() should remain
where it is, regardless of where inheritance
In the jsonb patch I have been working on, I have replicated all of what
I call the json processing functions, and I will shortly add analogs for
the new functions in that category json_to_record and json_to_recordset.
However I have not replicated what I call the json generation functions,
On Wed, Jan 29, 2014 at 9:08 AM, Andrew Dunstan and...@dunslane.net wrote:
In the jsonb patch I have been working on, I have replicated all of what I
call the json processing functions, and I will shortly add analogs for the
new functions in that category json_to_record and json_to_recordset.
Andrew Dunstan and...@dunslane.net writes:
In the jsonb patch I have been working on, I have replicated all of what
I call the json processing functions, and I will shortly add analogs for
the new functions in that category json_to_record and json_to_recordset.
However I have not replicated
On 01/29/2014 10:21 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
In the jsonb patch I have been working on, I have replicated all of what
I call the json processing functions, and I will shortly add analogs for
the new functions in that category json_to_record and
2014/1/29 Ian Lawrence Barwick barw...@gmail.com:
2014-01-29 Andrew Dunstan and...@dunslane.net:
On 01/28/2014 05:55 AM, Ian Lawrence Barwick wrote:
Hi Payal
Many thanks for the review, and my apologies for not getting back to
you earlier.
Updated version of the patch attached with
New patch attached with the following changes:
On Thu, Jan 23, 2014 at 11:01 AM, Steeve Lennmark stee...@handeldsbanken.se
wrote:
On Thu, Jan 23, 2014 at 2:06 AM, Peter Eisentraut pete...@gmx.net wrote:
I'm not totally happy with the choice of : as the mapping separator,
because that would
2014-01-29 Pavel Stehule pavel.steh...@gmail.com
2014-01-29 Jeevan Chalke jeevan.cha...@enterprisedb.com
Hi Pavel,
Now the patch looks good to me. However when I try to restore your own
sql file's dump, I get following errors:
pg_restore: [archiver (db)] could not execute query: ERROR:
On Wed, Jan 29, 2014 at 4:12 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 01/28/2014 06:11 PM, Christian Kruse wrote:
Hi,
attached you will find a new version of the patch, ported to HEAD,
fixed the mentioned bug and - hopefully - dealing the the remaining
issues.
Thanks, I
On 28 January 2014 20:14, Josh Berkus j...@agliodbs.com wrote:
On 01/28/2014 12:10 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
For example, I would really like to GRANT an unpriv user access to the
WAL columns in pg_stat_replication so that I can monitor replication
delay
Christian Kruse christ...@2ndquadrant.com writes:
Ok, so I propose the attached patch as a fix.
No, what I meant is that the ereport caller needs to save errno, rather
than assuming that (some subset of) ereport-related subroutines will
preserve it.
In general, it's unsafe to assume that any
Esteemed hackers,
I can't be the only person to have encountered a situation where
adding a new foreign key pointing at a busy table essentially never
happens because the way things work now, creating the constraint
trigger on that busy table requires an AccessExclusive lock, or a
unicorn,
Hi,
On 29/01/14 14:12, Heikki Linnakangas wrote:
The documentation is still lacking. We should explain somewhere how to set
nr.hugepages, for example. The Managing Kernel Resources section ought to
mention setting. Could I ask you to work on that, please?
Of course! Attached you will find a
Hello
I am looking on this patch
http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com
a) pg_sleep_for - no objection - it is simple and secure
b) pg_sleep_until
I am not sure - maybe this implementation is too simply. I see two possible
risk where it should not work as users can
On 01/29/2014 04:55 AM, Simon Riggs wrote:
It is possible that adding this extra straw breaks the camel's back,
but it seems unlikely to be that simple. A new feature to help
performance problems will be of a great use to many people; complaints
about the performance of pg_stat_statements are
On 01/29/2014 08:04 PM, Pavel Stehule wrote:
Hello
I am looking on this patch
Thank you for looking at it.
http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com
a) pg_sleep_for - no objection - it is simple and secure
Okay.
b) pg_sleep_until
I am not sure - maybe this
Hi,
On 29/01/14 10:11, Jeff Janes wrote:
I'm getting this warning now with gcc (GCC) 4.4.7:
Interesting. I don't get that warning. But the compiler is (formally)
right.
pg_shmem.c: In function 'PGSharedMemoryCreate':
pg_shmem.c:332: warning: 'allocsize' may be used uninitialized in this
On 01/28/2014 09:39 PM, Tom Lane wrote:
I'm for doing the measurement in ExplainOneQuery() and not printing
anything in code paths that don't go through there.
Reading the discussion here and realizing that my last patch was wrong I
am now in agreement with this. I have attached a patch which
2014-01-29 Vik Fearing vik.fear...@dalibo.com
On 01/29/2014 08:04 PM, Pavel Stehule wrote:
Hello
I am looking on this patch
Thank you for looking at it.
http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com
a) pg_sleep_for - no objection - it is simple and secure
On 01/29/2014 10:19 AM, Simon Riggs wrote:
No specific reason that I can recall but replication is heavily
protected by layers of security.
pg_stat_replication is a join with pg_stat_activity, so some of the
info is open, some closed. It seems possible to relax that.
I'm all for the idea of
On 01/29/2014 08:21 PM, Pavel Stehule wrote:
second question - is not this functionality too dangerous? If somebody
use it as scheduler, then
a) can holds connect, session data, locks too long time
b) it can stop on query timeout probably much more early then user expect
What is expected
On 01/29/2014 09:18 PM, Christian Kruse wrote:
Hi,
On 29/01/14 10:11, Jeff Janes wrote:
I'm getting this warning now with gcc (GCC) 4.4.7:
Interesting. I don't get that warning. But the compiler is (formally)
right.
pg_shmem.c: In function 'PGSharedMemoryCreate':
pg_shmem.c:332: warning:
2014-01-29 Vik Fearing vik.fear...@dalibo.com
On 01/29/2014 08:21 PM, Pavel Stehule wrote:
second question - is not this functionality too dangerous? If somebody
use it as scheduler, then
a) can holds connect, session data, locks too long time
b) it can stop on query timeout probably
On Wed, Jan 29, 2014 at 4:56 AM, salah jubeh s_ju...@yahoo.com wrote:
I'm not particularly in favor of implementing this as client-side
functionality, because then it's only available to people who use that
particular client. Simon Riggs proposed a server-side option to the
DROP DATABASE command
On Wed, Jan 29, 2014 at 8:22 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2014-01-29 21:59:05 +0900, Michael Paquier wrote:
The undocumented GUC called xloginsert_slots has been introduced by
commit 9a20a9b. It is mentioned by the commit that this parameter
should be removed before
On Wed, Jan 29, 2014 at 9:06 AM, Andrew Dunstan and...@dunslane.net wrote:
I am not opposed in principle to adding new things to the counters
struct in pg_stat_statements. I just think that the fact that the
overhead of installing the module on a busy production system is
currently so low is
On 29 January 2014 05:43, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 28, 2014 at 12:36 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Honestly, I would prefer that we push a patch that has been thoroughly
reviewed and in which we have more
Hi,
On 29/01/14 21:36, Heikki Linnakangas wrote:
[…]
Fix pushed.
You are right. Thanks. But there is another bug, see
20140128154307.gc24...@defunct.ch
ff. Attached you will find a patch fixing that.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL
On Wed, Jan 29, 2014 at 2:21 PM, Andreas Karlsson andr...@proxel.se wrote:
On 01/28/2014 09:39 PM, Tom Lane wrote:
I'm for doing the measurement in ExplainOneQuery() and not printing
anything in code paths that don't go through there.
Reading the discussion here and realizing that my last
On 01/29/2014 11:54 AM, Robert Haas wrote:
I agree. I find it somewhat unlikely that pg_stat_statements is
fragile enough that these few extra counters are going to make much of
a difference. At the same time, I find min and max a dubious value
proposition. It seems highly likely to me that
On 14 January 2014 08:38, Christian Kruse christ...@2ndquadrant.com wrote:
Hi,
On 13/01/14 20:06, Heikki Linnakangas wrote:
On 12/17/2013 04:58 PM, Christian Kruse wrote:
attached you will find a patch for showing the current transaction id
(xid) and the xmin of a backend in pg_stat_activty
On 01/29/2014 09:01 PM, Robert Haas wrote:
Cool. I propose adding one parameter rather than two to
ExplainOnePlan() and making it of type instr_time * rather than
passing an instr_time and a bool. If you don't want to include the
planning time, pass NULL; if you do, pass a pointer to the
On 01/29/2014 09:59 PM, Christian Kruse wrote:
Hi,
On 29/01/14 21:36, Heikki Linnakangas wrote:
[…]
Fix pushed.
You are right. Thanks. But there is another bug, see
20140128154307.gc24...@defunct.ch
ff. Attached you will find a patch fixing that.
Thanks. There are more cases of that in
Hi,
On 29/01/14 22:17, Heikki Linnakangas wrote:
Thanks. There are more cases of that in InternalIpcMemoryCreate, they ought
to be fixed as well. And should also grep the rest of the codebase for more
instances of that. And this needs to be back-patched.
I'm way ahead of you ;-) Working on
related to
http://www.postgresql.org/message-id/bf2827dcce55594c8d7a8f7ffd3ab7713ddb1...@szxeml508-mbx.china.huawei.com
Hello
1. I had to rebase this patch - actualised version is attached - I merged
two patches to one
2. The psql code is compiled without issues after patching
3. All regress
Hi,
On 29/01/14 13:39, Tom Lane wrote:
No, what I meant is that the ereport caller needs to save errno, rather
than assuming that (some subset of) ereport-related subroutines will
preserve it.
[…]
Your reasoning sounds quite logical to me. Thus I did a
grep -RA 3 ereport src/* | less
and
Hi,
On 29/01/14 21:37, Christian Kruse wrote:
[…]
attached you will find a patch addressing that issue.
Maybe we should include the patch proposed in
20140129195930.gd31...@defunct.ch
and do this as one (slightly bigger) patch. Attached you will find
this alternative version.
Best regards,
On Wed, Jan 29, 2014 at 12:03 PM, Andrew Dunstan and...@dunslane.net wrote:
Only change in functionality is the addition of casts between jsonb and
json.
The other changes are the merge with the new json functions code, and
rearrangement of the docs changes to make them less ugly. Essentially
On 01/29/2014 12:46 PM, Merlin Moncure wrote:
I think the opening paragraphs contrasting json/jsonb be needs
refinement. json is going to be slightly faster than jsonb for input
*and* output. For example, in one application I store fairly large
json objects containing pre-compiled static
On 29. Januar 2014 20:51:38 MEZ, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jan 29, 2014 at 8:22 AM, Andres Freund and...@2ndquadrant.com
wrote:
Hi,
On 2014-01-29 21:59:05 +0900, Michael Paquier wrote:
The undocumented GUC called xloginsert_slots has been introduced by
commit 9a20a9b.
On Wed, Jan 29, 2014 at 3:13 PM, Andreas Karlsson andr...@proxel.se wrote:
On 01/29/2014 09:01 PM, Robert Haas wrote:
Cool. I propose adding one parameter rather than two to
ExplainOnePlan() and making it of type instr_time * rather than
passing an instr_time and a bool. If you don't want to
On Wed, Jan 29, 2014 at 6:06 AM, Andrew Dunstan and...@dunslane.net wrote:
mportance is in the eye of the beholder. As far as I'm concerned, min and
max are of FAR less value than stddev. If stddev gets left out I'm going to
be pretty darned annoyed, especially since the benchmarks seem to
On 01/29/2014 10:10 PM, Robert Haas wrote:
Committed with minor doc changes.
Thanks!
/Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/29/2014 04:14 PM, Peter Geoghegan wrote:
On Wed, Jan 29, 2014 at 6:06 AM, Andrew Dunstan and...@dunslane.net wrote:
mportance is in the eye of the beholder. As far as I'm concerned, min and
max are of FAR less value than stddev. If stddev gets left out I'm going to
be pretty darned
Hello
I am looking on this patch.
It is great idea, and I am sure, so we want this patch - it was requested
and proposed more time.
Some tips:
a) possibility to test only selected tests
b) possibility to verify generated file against expected file
c) detection some warnings
Christian Kruse christ...@2ndquadrant.com writes:
Your reasoning sounds quite logical to me. Thus I did a
grep -RA 3 ereport src/* | less
and looked for ereport calls with errno in it. I found quite a few,
attached you will find a patch addressing that issue.
Excellent, thanks for doing the
Last week:
Status Summary. Needs Review: 66, Waiting on Author: 16, Ready for
Committer: 9, Committed: 20, Returned with Feedback: 2. Total: 113.
This week:
Status Summary. Needs Review: 49, Waiting on Author: 18, Ready for
Committer: 9, Committed: 33, Returned with Feedback: 3, Rejected: 1.
On Wed, Jan 29, 2014 at 3:56 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/29/2014 01:03 PM, Andrew Dunstan wrote:
On 01/27/2014 10:43 PM, Andrew Dunstan wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of patches for nested hstore and jsonb.
Because
On 01/29/2014 05:37 PM, Merlin Moncure wrote:
On Wed, Jan 29, 2014 at 3:56 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/29/2014 01:03 PM, Andrew Dunstan wrote:
On 01/27/2014 10:43 PM, Andrew Dunstan wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of
It seems to me that the terms physical, logical, and binary are
always relative to the perspective of the component being worked on.
Physical often means one level of abstraction below mine, and upon which
my work builds. Logical means my work's level of abstraction. And
Binary means data which
On 01/29/2014 02:37 PM, Merlin Moncure wrote:
create table bar(a int, b int[]);
postgres=# select jsonb_populate_record(null::bar, '{a: 1, b:
[1,2]}'::jsonb, false);
ERROR: cannot populate with a nested object unless use_json_as_text is true
Hmmm. What about just making any impossibly
Andrew Dunstan and...@dunslane.net writes:
I could live with just stddev. Not sure others would be so happy.
FWIW, I'd vote for just stddev, on the basis that min/max appear to add
more to the counter update time than stddev does; you've got
this:
+ e-counters.total_sqtime +=
On Mon, Jan 27, 2014 at 10:54 AM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Jan 27, 2014 at 10:27 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I think I see some bugs in _bt_moveright(). If you examine
_bt_finish_split() in detail, you'll see that it doesn't just drop the
write
On Wed, Jan 29, 2014 at 12:53:02AM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
If this only affects a handful of places, then sure, let's go ahead
and fix it. But if it's going to create a massive enough diff that
we've gotta think about back-patching it, then IMHO
Bruce Momjian br...@momjian.us writes:
I have cleaned up entab.c so I am ready to add a new option that removes
tabs from only comments. Would you like me to create that and provide a
diff at a URL? It would have to be run against all back branches.
If you think you can actually tell the
On Tue, Jan 28, 2014 at 1:17 PM, Peter Eisentraut wrote:
On 11/30/13, 6:59 AM, Haribabu kommi wrote:
To detect provided data and xlog directories are same or not, I reused
the
Existing make_absolute_path() code as follows.
I note that initdb does not detect whether the data and xlog
On 28.1.2014 08:29, Heikki Linnakangas wrote:
On 01/28/2014 05:54 AM, Tomas Vondra wrote:
Then I ran those scripts on:
* 9.3
* 9.4 with Heikki's patches (9.4-heikki)
* 9.4 with Heikki's and first patch (9.4-alex-1)
* 9.4 with Heikki's and both patches (9.4-alex-2)
It would be
Christian Kruse christ...@2ndquadrant.com writes:
Your reasoning sounds quite logical to me. Thus I did a
grep -RA 3 ereport src/* | less
and looked for ereport calls with errno in it. I found quite a few,
attached you will find a patch addressing that issue.
Committed. I found a couple of
David Fetter wrote:
2) Is there another way to solve the problem of adding a foreign
key constraint that points at a busy table?
Add it as NOT VALID and do a later VALIDATE CONSTRAINT step, after the
patch to reduce lock levels for ALTER TABLE goes in, perhaps?
--
Álvaro Herrera
On Wed, Jan 29, 2014 at 07:31:29PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have cleaned up entab.c so I am ready to add a new option that removes
tabs from only comments. Would you like me to create that and provide a
diff at a URL? It would have to be run against
(2014/01/29 16:58), Peter Geoghegan wrote:
On Tue, Jan 28, 2014 at 10:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
KONDO Mitsumasa kondo.mitsum...@lab.ntt.co.jp writes:
By the way, latest pg_stat_statement might affect performance in Windows system.
Because it uses fflush() system call every
1 - 100 of 109 matches
Mail list logo
