From: "Amit Kapila"
On Wed, Jan 15, 2014 at 8:12 PM, MauMau wrote:
Thanks for reviewing and testing the patch. Yes, at first I did what you
mentioned, but modified the patch according to some advice in the mail
thread. During redo, create_tablespace_directories() needs to handle the
case whe
On Fri, Mar 21, 2014 at 9:49 AM, Rajashree Mandaogane <
rajashree@gmail.com> wrote:
> What can be done to get rid of the 'optimized out' tags while debugging?
>
Did you use the appropriate debugging flags when running ./configure?
Regards,
Atri
--
Regards,
Atri
*l'apprenant*
What can be done to get rid of the 'optimized out' tags while debugging?
We added these ConstrCheck fields for 9.2, but equalTupleDescs() did not get
the memo. I looked for resulting behavior problems, and I found one in
RelationClearRelation() only. Test case:
set constraint_exclusion = on;
drop table if exists ccvalid_test;
create table ccvalid_test (c int);
alter
On Sat, Mar 08, 2014 at 11:14:30AM +, Simon Riggs wrote:
> On 7 March 2014 09:04, Simon Riggs wrote:
> > The right thing to do here is to not push to the extremes. If we mess
> > too much with the ruleutil stuff it will just be buggy. A more
> > considered analysis in a later release is requir
On 03/21/2014 11:09 AM, Tom Lane wrote:
> Craig Ringer writes:
>> Here's how I think it needs to look:
>> [ move all the functionality to the backend ]
>
> Of course, after you've done all that work, you've got something that is
> of exactly zero use to its supposed principal use-case, pg_dump.
Craig Ringer writes:
> Here's how I think it needs to look:
> [ move all the functionality to the backend ]
Of course, after you've done all that work, you've got something that is
of exactly zero use to its supposed principal use-case, pg_dump. pg_dump
will still have to support server versions
On 03/21/2014 09:28 AM, Robert Haas wrote:
> On Tue, Mar 18, 2014 at 8:41 PM, Alexandr wrote:
>> Rewrite (add) pg_dump and pg_restore utilities as libraries (.so, .dll &
>> .dylib)
>
> This strikes me as (1) pretty vague and (2) probably too hard for a
> summer project.
>
> I mean, getting the e
On 03/21/2014 01:12 AM, Tom Lane wrote:
> Rajashree Mandaogane writes:
>> While debugging any function in PostgreSQL, whenever I use the command
>> 'bt', it doesn't give the entire list of functions used. Which command
>> should be used instead?
>
> It's probably omitting functions that have been
On Tue, Mar 18, 2014 at 8:41 PM, Alexandr wrote:
> Rewrite (add) pg_dump and pg_restore utilities as libraries (.so, .dll &
> .dylib)
This strikes me as (1) pretty vague and (2) probably too hard for a
summer project.
I mean, getting the existing binaries to build libraries that you can
call wit
I've endeavored to enable the return of arrays of composite types from code
written in PL/Python. It seems that this can be accomplished though a very
minor change to the code:
On line 401 in the file src/pl/plpython/plpy_typeio.c, remove the error
report "PL/Python functions cannot return typ
On Thu, Mar 20, 2014 at 5:55 PM, Alexandr wrote:
>> Subtracting to get an interval, then converting that interval to seconds
>> or minutes could give you a value that's wildly different from the right
>> answer.
>
> Can you explain me when it happens ?
'1 month'::interval
It's different dependi
Subtracting to get an interval, then converting that interval to
seconds or minutes could give you a value that’s wildly different from
the right answer.
Can you explain me when it happens ?
With best wishes,
Alexander S.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Alexandr escribió:
>
> 21.03.2014 00:33, Josh Berkus пишет:
> >Comments:
> >#2: I don't understand this one?
> >#3 is already a patch for version 9.4, but possibly you can
> >improve/expand it.
> >#4 has already been the subject of a LOT of debate, I think you
> >don't want to get into it.
> I mea
> I meaned this one: Allow TIMESTAMP WITH TIME ZONE to store the original
> timezone information, either zone name or offset from UTC
> And which ideas can you advise me to add to proposal?
That one has also been hotly debated. You'd probably have to do it as
an extension, and that would be a fa
21.03.2014 00:33, Josh Berkus пишет:
Comments:
#2: I don't understand this one?
#3 is already a patch for version 9.4, but possibly you can
improve/expand it.
#4 has already been the subject of a LOT of debate, I think you don't
want to get into it.
I meaned this one: Allow TIMESTAMP WITH TIM
On Mar 20, 2014, at 1:24 PM, Thom Brown wrote:
> On 20 March 2014 20:07, Josh Berkus wrote:
>> On 03/20/2014 09:56 AM, Alexandr wrote:
>>> Here is the text of my proposal which I've applied to GSoC.
>>> (and link
>>> https://docs.google.com/document/d/1vBjQzhFT_fgoIkoEP5TVeyFA6ggsYlLq76tghGVUD6
On 03/20/2014 01:26 PM, Alexandr wrote:
>
> 21.03.2014 00:07, Josh Berkus пишет:
>> Per my comments on the GSOC app, it looks good, but I'd like to see
>> some "stretch goals" if you are able to implement the new function
>> before GSOC is over. For example, one thing which has been frequently
>>
21.03.2014 00:07, Josh Berkus пишет:
Per my comments on the GSOC app, it looks good, but I'd like to see
some "stretch goals" if you are able to implement the new function
before GSOC is over. For example, one thing which has been frequently
requested is functions to display intervals in the u
On 20 March 2014 20:07, Josh Berkus wrote:
> On 03/20/2014 09:56 AM, Alexandr wrote:
>> Here is the text of my proposal which I've applied to GSoC.
>> (and link
>> https://docs.google.com/document/d/1vBjQzhFT_fgoIkoEP5TVeyFA6ggsYlLq76tghGVUD6A/edit?usp=sharing)
>>
>> Any suggestions and comments a
On 15/03/14 20:27, Heikki Linnakangas wrote:
That said, I didn't expect the difference to be quite that big when
you're appending to the end of the table. When the new entries go to
the end of the posting lists, you only need to recompress and WAL-log
the last posting list, which is max 256 byt
On 03/20/2014 09:56 AM, Alexandr wrote:
> Here is the text of my proposal which I've applied to GSoC.
> (and link
> https://docs.google.com/document/d/1vBjQzhFT_fgoIkoEP5TVeyFA6ggsYlLq76tghGVUD6A/edit?usp=sharing)
>
> Any suggestions and comments are welcome.
> Because I don't know the code of Pos
Hi,
My proposal is now available on Google melange website:
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/viod/5668600916475904
There seems to be a formatting issue: half of the text is a link to the
page I mentionned during my registration on my website. I don't know how to
f
Hi all,
There is 1 day left to get submissions in, so students should ensure
that they submit their proposals as soon as possible. No submissions
will be accepted beyond the deadline of 19:00 UTC tomorrow (Friday
21st March).
Regards
Thom
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Thu, Mar 20, 2014 at 5:32 AM, Alexander Korotkov
wrote:
> Besides implementation, what the idea was here? For me, it's impossible to
> skip any single element, because it's possible for query to include only
> this element. If we skip that element, we can't answer corresponding query
> no more.
Rajashree Mandaogane writes:
> While debugging any function in PostgreSQL, whenever I use the command
> 'bt', it doesn't give the entire list of functions used. Which command
> should be used instead?
It's probably omitting functions that have been inlined; if so, the "fix"
is to recompile with a
While debugging any function in PostgreSQL, whenever I use the command
'bt', it doesn't give the entire list of functions used. Which command
should be used instead?
Hello!
Here is the text of my proposal which I've applied to GSoC.
(and link
https://docs.google.com/document/d/1vBjQzhFT_fgoIkoEP5TVeyFA6ggsYlLq76tghGVUD6A/edit?usp=sharing)
Any suggestions and comments are welcome.
Because I don't know the code of PostgreSQL well I decide not to
participate i
On Thu, Mar 20, 2014 at 10:45 AM, Tom Lane wrote:
> Robert Haas writes:
>> So you might think that the problem here is that we're assuming
>> uniform density. Let's say there are a million rows in the table, and
>> there are 100 that match our criteria, so the first one is going to
>> happen 1/1
On Sat, Mar 8, 2014 at 08:44:34PM -0500, Bruce Momjian wrote:
> [Just getting back to this.]
>
> Agreed. I have developed the attached patch which passes the strdup()
> failure up from pg_fe_getauthname() and maps the failure to
> PQconndefaults(), which is now documented as being memory allocat
Fujii Masao writes:
> On Thu, Mar 20, 2014 at 2:34 AM, Jeff Janes wrote:
>> In 9.4dev, if the server is started with effective_cache_size = -1, then it
>> cannot be changed away from that without a restart.
> I think that's a bug. Patch attached.
PGC_S_FILE is at least as bogus as the previous
On Thu, Mar 20, 2014 at 8:51 PM, Tom Lane wrote:
> Atri Sharma writes:
> > Now, why cannot we take the estimate of all the buckets behind the bucket
> > in which our value is present? Will that estimate not give us the
> fraction
> > of tuples that are expected to be before the first matching ro
Atri Sharma writes:
> Now, why cannot we take the estimate of all the buckets behind the bucket
> in which our value is present? Will that estimate not give us the fraction
> of tuples that are expected to be before the first matching row?
Uh, no, not unless you assume that the table happens to b
On Thu, Mar 20, 2014 at 8:10 PM, Robert Haas wrote:
> On Tue, Mar 18, 2014 at 2:41 PM, Tom Lane wrote:
> > Atri Sharma writes:
> >> One of the factors that leads to bad estimates is that the histogram of
> the
> >> values of a column maintained by the planner gets old by time and the
> data
> >
Marko Tiikkaja writes:
> On 3/20/14, 12:32 AM, Tom Lane wrote:
>> Also, adding GUC_LIST_INPUT later is not really cool since it changes
>> the parsing behavior for the GUC. If it's going to be a list, it should
>> be one from day zero.
> I'm not sure what exactly you mean by this. If the only a
Robert Haas writes:
> So you might think that the problem here is that we're assuming
> uniform density. Let's say there are a million rows in the table, and
> there are 100 that match our criteria, so the first one is going to
> happen 1/10,000'th of the way through the table. Thus we set SC =
On Tue, Mar 18, 2014 at 2:41 PM, Tom Lane wrote:
> Atri Sharma writes:
>> One of the factors that leads to bad estimates is that the histogram of the
>> values of a column maintained by the planner gets old by time and the data
>> in the column changes. So, the histogram is no longer a quite accu
Kyotaro HORIGUCHI escribió:
> Hi, I confirmed that 82233ce7ea4 surely did it.
>
> At Wed, 19 Mar 2014 09:35:16 -0300, Alvaro Herrera wrote
> > Fujii Masao escribió:
> > > On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas
> > > wrote:
> >
> > > >> 9.4 canceles backup mode even on immediate shut
On Tue, Mar 18, 2014 at 4:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane wrote:
>>> Meh. I think you're putting a bit too much faith in your ability to
>>> predict the locus of bugs that you think aren't there.
>
>> Well, I'm open to suggestions.
>
>
(2014/03/18 18:38), Kyotaro HORIGUCHI wrote:
By the way, Can I have a simple script to build an environment to
run this on?
I built test environment and ran the simple test using
postgres_fdw and got parameterized path from v3 patch on the
following operation as shown there, and v6 also gives o
I've noticed two commits on github.
commit b8199ee3c2506ab81b47a0b440363fc90c0d6956
Author: Peter Geoghegan
Date: Wed Mar 19 02:02:16 2014 -0700
For jsonb_hash_ops, hash less
By limiting the GIN entries to the least-nested level, the delicious.com
sample JSON dataset index shrinks
On Thu, Mar 20, 2014 at 2:34 AM, Jeff Janes wrote:
> In 9.4dev, if the server is started with effective_cache_size = -1, then it
> cannot be changed away from that without a restart. If you change the
> config file and do a reload or pg_reload_conf(), it ignores the change
> without comment in th
On 20/03/14 00:32, Tom Lane wrote:
TBH, if I thought this specific warning was the only one that would ever
be there, I'd probably be arguing to reject this patch altogether.
Of course, nobody assumes that it will be the only one.
Also, adding GUC_LIST_INPUT later is not really cool since i
2014-03-20 9:47 GMT+01:00 Mark Kirkwood :
> On 20/03/14 20:08, Pavel Stehule wrote:
>
>>
>>
>>
>> 2014-03-20 7:25 GMT+01:00 Mark Kirkwood > Also I think this would probably only make sense for TEMPORARY
>> tables - otherwise you can get this sort of thing going on:
>>
>> - you create a
On 20/03/14 20:08, Pavel Stehule wrote:
2014-03-20 7:25 GMT+01:00 Mark Kirkwood
Sorry Pavel - what you have said above is difficult for me to understand
- if the limit is intended as a *session* limit then concurrent activity
from multiple sessions makes it behave - well - strangely to say
On 3/20/14, 12:32 AM, Tom Lane wrote:
Isn't the entire point to create a framework in which more tests will
be added later?
Also, adding GUC_LIST_INPUT later is not really cool since it changes
the parsing behavior for the GUC. If it's going to be a list, it should
be one from day zero.
I'm n
On 03/18/2014 11:39 AM, Simon Riggs wrote:
> On 8 March 2014 11:14, Simon Riggs wrote:
>> On 7 March 2014 09:04, Simon Riggs wrote:
>>
>>> The right thing to do here is to not push to the extremes. If we mess
>>> too much with the ruleutil stuff it will just be buggy. A more
>>> considered analys
2014-03-20 7:25 GMT+01:00 Mark Kirkwood :
> On 20/03/14 13:28, Josh Berkus wrote:
>
> 3. relation limit - possibility to set session limit for maximum size of
>>> relations. Any relation cannot be extended over this limit in session,
>>> when
>>> this value is higher than zero. Motivation - we us
48 matches
Mail list logo
