On Sat, Jan 21, 2012 at 9:05 PM, Noah Misch 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
>> --- /tmp/foo/src/test/regress/results/alter_tabl
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 t
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 "cata
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
> ***
> **
On Sun, Jan 15, 2012 at 8:08 AM, Andrew Dunstan 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 diff
On Wed, Jan 4, 2012 at 12:35 PM, Noah Misch 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:
> http://www.postgresql.o
On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra 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
output
On Fri, Jan 13, 2012 at 7:21 AM, Robert Haas 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
> EXPLAIN ANALYZE outpu
On 16 January 2012 00:59, Jeff Janes 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 we wouldn't over-
On Sun, Jan 15, 2012 at 10:28 PM, Greg Smith 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 pg_stat_bgwriter'
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 ha
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 21 Leden 2012, 18:13, Magnus Hagander wrote:
> On Sat, Jan 21, 2012 at 18:02, Tomas Vondra 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 fields
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 but
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 21 Leden 2012, 18:20, Dimitri Fontaine wrote:
> Hi,
>
> Thank you for reviewing this patch!
>
> Hitoshi Harada 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 about
>> the
Hi,
Thank you for reviewing this patch!
Hitoshi Harada 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"
>Column | Type
On Sat, Jan 21, 2012 at 18:02, Tomas Vondra wrote:
> On 20 Leden 2012, 13:23, Magnus Hagander wrote:
>> On Tue, Jan 17, 2012 at 21:39, Tomas Vondra wrote:
>>> On 20.12.2011 19:59, Tomas Vondra wrote:
On 20.12.2011 11:20, Magnus Hagander wrote:
> 2011/12/20 Tomas Vondra :
>>
>> I
On 20 Leden 2012, 13:23, Magnus Hagander wrote:
> On Tue, Jan 17, 2012 at 21:39, Tomas Vondra wrote:
>> On 20.12.2011 19:59, Tomas Vondra wrote:
>>> On 20.12.2011 11:20, Magnus Hagander wrote:
2011/12/20 Tomas Vondra :
>
> I haven't updated the docs yet - let's see if the patch is acc
On Sat, Jan 21, 2012 at 3:59 AM, Kohei KaiGai 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 it a good idea
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 attache
On Sat, Jan 21, 2012 at 1:57 PM, Robert Haas wrote:
> On Fri, Jan 20, 2012 at 10:44 AM, Robert Haas 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, bu
On Sat, Jan 21, 2012 at 1:53 AM, Robert Haas wrote:
> On Thu, Jan 19, 2012 at 10:02 AM, Simon Riggs wrote:
>> On Wed, Jan 18, 2012 at 11:12 PM, Robert Haas wrote:
>>> On Wed, Jan 18, 2012 at 5:49 PM, Simon Riggs wrote:
Can I just check with you that the only review comment is a one line
>>
On Fri, Jan 20, 2012 at 10:44 AM, Robert Haas 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, it fell over
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 wh
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 form
> >
> > 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 rat
On 19 Jan 2012 21:00, "Robert Haas" 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 complaints because an
On 19/01/2012, Robert Haas 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 'bob'.
> Another
2012/1/19 Robert Haas :
> On Thu, Jan 19, 2012 at 3:51 AM, Kohei KaiGai wrote:
>> 2012/1/19 Robert Haas :
>>> On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai wrote:
In sepgsql side, it determines a case to apply permission checks
according to the contextual information; that is same techn
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 things.
"""
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 yo
32 matches
Mail list logo
