I am going to produce another revision in response to feedback already
received. I intend to outline the steps that it will take to resolve
some outstanding issues in the next day or so. It would be nice if you
could take a look at the revised patch that is ultimately produced.
Should I keep you
I decided to take advantage of my ongoing access to a benchmarking
server to see how I could get on with a query with an especially large
sort. Now, that box has 16GB of ram, and some people have that much
memory in their laptops these days, so I was somewhat limited in how
far I could push
2012/1/19 Robert Haas robertmh...@gmail.com:
On Thu, Jan 19, 2012 at 3:51 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/19 Robert Haas robertmh...@gmail.com:
On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
In sepgsql side, it determines a case to apply permission
On 19/01/2012, Robert Haas robertmh...@gmail.com wrote:
rhaas=# alter sequence foo_a_seq rename to bob;
ALTER SEQUENCE
If somebody renames the table or the column at this point, it's a good
bet that they *don't* want bob renamed.
FWIW the patch addresses this case and wouldn't try to rename
On 19 Jan 2012 21:00, Robert Haas robertmh...@gmail.com wrote:
I agree. It occurs to me that we recently changed the default *text*
output format for bytea for reasons not dissimilar to those
contemplated here. Presumably, that's a much more disruptive change,
and yet we've had minimal
c. Refine error handling of dblink.c. I think it preserves the
previous behavior for column number mismatch and type
conversion exception.
Hello,
I don't know if this cover following issue.
I just mention it for the case you didn't notice it and would like to
handle this rather
Someone has some kind of specification or description of the pg_dump
custom format?
What I'm trying to do is an utility to remotelly syncronize postgresql
dumps, using lib_rsync to syncronize each table independently and
copying blobs only when sizes differ.
I've made the same using the Tar
On 01/21/2012 07:44 AM, Guillermo M. Narvaja wrote:
Someone has some kind of specification or description of the pg_dump
custom format?
What I'm trying to do is an utility to remotelly syncronize postgresql
dumps, using lib_rsync to syncronize each table independently and
copying blobs only
On Fri, Jan 20, 2012 at 10:44 AM, Robert Haas robertmh...@gmail.com wrote:
D'oh. You're right. Looks like I accidentally tried to apply this to
the 9.1 sources. Sigh...
No worries. It's Friday.
Server passed 'make check' with this patch, but when I tried to fire
it up for some test runs,
On Sat, Jan 21, 2012 at 1:53 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 19, 2012 at 10:02 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Jan 18, 2012 at 11:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jan 18, 2012 at 5:49 PM, Simon Riggs si...@2ndquadrant.com
On Sat, Jan 21, 2012 at 1:57 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 20, 2012 at 10:44 AM, Robert Haas robertmh...@gmail.com wrote:
D'oh. You're right. Looks like I accidentally tried to apply this to
the 9.1 sources. Sigh...
No worries. It's Friday.
Server passed 'make
On 23-12-2011 12:05, Tom Lane wrote:
I too think a datatype is overkill, if we're only planning on providing
one function. Just emit the values as numeric and have done.
Here it is. Output changed to numeric. While the output was int8 I could use
pg_size_pretty but now I couldn't. I attached
On Sat, Jan 21, 2012 at 3:59 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I marked the default leakproof function according to the criteria that
does not leak contents of the argument.
Indeed, timestamp_ne_timestamptz() has a code path that rises
an error of timestamp out of range message. Is
On 20 Leden 2012, 13:23, Magnus Hagander wrote:
On Tue, Jan 17, 2012 at 21:39, Tomas Vondra t...@fuzzy.cz wrote:
On 20.12.2011 19:59, Tomas Vondra wrote:
On 20.12.2011 11:20, Magnus Hagander wrote:
2011/12/20 Tomas Vondra t...@fuzzy.cz:
I haven't updated the docs yet - let's see if the patch
On Sat, Jan 21, 2012 at 18:02, Tomas Vondra t...@fuzzy.cz wrote:
On 20 Leden 2012, 13:23, Magnus Hagander wrote:
On Tue, Jan 17, 2012 at 21:39, Tomas Vondra t...@fuzzy.cz wrote:
On 20.12.2011 19:59, Tomas Vondra wrote:
On 20.12.2011 11:20, Magnus Hagander wrote:
2011/12/20 Tomas Vondra
Hi,
Thank you for reviewing this patch!
Hitoshi Harada umi.tan...@gmail.com writes:
The patch applies with one reject, which I could fix easily. The make
check passed.
Bitrot happens fast in this season… will produce another version of the
patch.
Table pg_catalog.pg_extension_feature
On 21 Leden 2012, 18:20, Dimitri Fontaine wrote:
Hi,
Thank you for reviewing this patch!
Hitoshi Harada umi.tan...@gmail.com writes:
Next, some questions:
- Why is the finer dependency needed? Do you have tangible example
that struggles with the dependency granularity? I feel so good
On tis, 2012-01-17 at 13:03 +0100, Pavel Stehule wrote:
Hello
I did review of this small patch
http://archives.postgresql.org/message-id/1326055692.15293.15.ca...@vanquo.pezone.net
* This patch was applied without with one hunk and compiled without warnings
bash-4.2$ patch -p1
On ons, 2012-01-18 at 21:16 +0200, Peter Eisentraut wrote:
On sön, 2012-01-15 at 08:14 -0500, Andrew Dunstan wrote:
It would possibly have some documentary value too. Just looking very
quickly at Peter's patch, I don't really understand his assertion that
this would significantly butcher
On 21 Leden 2012, 18:13, Magnus Hagander wrote:
On Sat, Jan 21, 2012 at 18:02, Tomas Vondra t...@fuzzy.cz wrote:
On 20 Leden 2012, 13:23, Magnus Hagander wrote:
I'm wondering if this (and also my deadlocks stats patch that's int he
queue) should instead of inventing new pgstats messages, add
On Sat, Jan 14, 2012 at 08:18:48PM +0100, Marco Nenciarini wrote:
This is our latest version of the patch. Gabriele, Gianni and I have
discussed a lot and decided to send an initial patch which uses EACH
REFERENCES instead of ARRAY REFERENCES. The reason behind this is that
ARRAY REFERENCES
On fre, 2012-01-20 at 11:32 +0530, Nikhil Sontakke wrote:
Agreed. And right now primary key constraints are not marked as only
making them available for inheritance in the future. Or you prefer it
otherwise?
Anyways, fail to see the direct connection between this and renaming.
Might have to
On Sun, Jan 15, 2012 at 10:28 PM, Greg Smith g...@2ndquadrant.com wrote:
I would like to be able to tell people they need never turn on
log_checkpoints if they monitor pg_stat_bgwriter instead, because that sets
a good precedent for what direction the database is going. It would be nice
for
On 16 January 2012 00:59, Jeff Janes jeff.ja...@gmail.com wrote:
I think it would be better to pre-deduct the tape overhead amount we
will need if we decide to switch to tape sort from the availMem before
we even start reading (and then add it back if we do indeed make that
switch). That way
On Fri, Jan 13, 2012 at 7:21 AM, Robert Haas robertmh...@gmail.com wrote:
I think that people who are using index-only scans are going to want
some way to find out the degree to which the scans are in fact
index-only.
So here's a 5-line patch that adds the number of heap fetches to the
On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra t...@fuzzy.cz wrote:
Fixed. The default value of TIMING option did not work as intended, it
was set to true even for plain EXPLAIN (without ANALYZE). In that case
the EXPLAIN failed.
I've applied this over the show Heap Fetches in EXPLAIN ANALYZE
On Wed, Jan 4, 2012 at 12:35 PM, Noah Misch n...@leadboat.com wrote:
I neglected to commit after revising the text of a few comments; use this
version instead. Thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sun, Jan 15, 2012 at 8:08 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/14/2012 03:06 PM, Andrew Dunstan wrote:
OK, here's a patch that does both query_to_json and array_to_json, along
with docs and regression tests. It include Robert's original patch, although
I can produce a
On Sat, Jan 21, 2012 at 08:04:20PM -0800, Jeff Janes wrote:
This is failing make check for me.
*** /tmp/foo/src/test/regress/expected/alter_table.out Sat Jan 21 19:51:46
2012
--- /tmp/foo/src/test/regress/results/alter_table.out Sat Jan 21 19:54:18
2012
***
***
New version that repairs a defective test case.
diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index 712b0b0..1bf1de5 100644
*** a/src/backend/commands/indexcmds.c
--- b/src/backend/commands/indexcmds.c
***
*** 23,28
--- 23,29
#include
So, having received feedback from Tom and others in relation to this
patch, I would like to state how I think I should go about addressing
various concerns to ensure that a revision of the patch gets into the
9.2 release. As I've said time and again, I think that it is very
important that we have
On Sat, Jan 21, 2012 at 9:05 PM, Noah Misch n...@leadboat.com wrote:
On Sat, Jan 21, 2012 at 08:04:20PM -0800, Jeff Janes wrote:
This is failing make check for me.
*** /tmp/foo/src/test/regress/expected/alter_table.out Sat Jan 21 19:51:46
2012
---
32 matches
Mail list logo
