At 2014-06-18 15:33:37 +0200, dep...@gmail.com wrote:
>
> Hi,
>
> In September 2013, there was patch sent by Stas Kelvich (
> http://www.postgresql.org/message-id/9e07e159-e405-41e2-9889-a04f534fc...@gmail.com)
> that adds indexable kNN searches to cube contrib module.
>
> What is needed so that
On 06/18/2014 09:34 AM, Tom Lane wrote:
Craig Ringer writes:
I posted about a possible packaging issue with RHEL 6 PGDG packages for
9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a
prior mail asking about what happened with moving to git hasn't had a
response).
http://www.p
From: "Fujii Masao"
On Wed, Jun 18, 2014 at 7:47 PM, MauMau wrote:
I marked this as ready for committer. The patch is good because it
matches
the description in the following page:
http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html
ISTM that this patch has already been
Craig Ringer writes:
> I posted about a possible packaging issue with RHEL 6 PGDG packages for
> 9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a
> prior mail asking about what happened with moving to git hasn't had a
> response).
> http://www.postgresql.org/message-id/53a10ef9.
Hi,
In September 2013, there was patch sent by Stas Kelvich (
http://www.postgresql.org/message-id/9e07e159-e405-41e2-9889-a04f534fc...@gmail.com)
that adds indexable kNN searches to cube contrib module.
What is needed so that it could get committed?
Regards,
depesz
On 06/18/2014 09:12 PM, Robert Haas wrote:
> No. Otherwise, one of those bits could get changed after a backend
> takes a snapshot and before it finishes using it - so that the
> transaction snapshot is in effect changing underneath it. You could
> avoid that by memorizing the contents of CLOG wh
On Tue, Jun 17, 2014 at 9:45 PM, Brightwell, Adam
wrote:
> I absolutely appreciate all of the feedback that has been provided. It has
> been educational. To your point above, I started putting together a wiki
> page, as Stephen has spoken to, that is meant to capture these concerns and
> conside
Stephen Frost writes:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> I think I'd rather just say "for many data types" or something along
>> those lines, rather than imply that there is some obvious rule that
>> users should be able to intuit.
> Perhaps with a link to where the informaiton ab
On Tue, Jun 17, 2014 at 5:40 PM, Michael Paquier
wrote:
> On Wed, Jun 18, 2014 at 1:40 AM, Robert Haas wrote:
>> On Mon, Jun 2, 2014 at 8:55 AM, Michael Paquier
>> wrote:
>> I'm not sure if this is reasonably possible, but one thing that would
>> make this tool a whole lot easier to use would be
On Tue, Jun 17, 2014 at 9:00 PM, Craig Ringer wrote:
> On 06/18/2014 12:41 AM, Robert Haas wrote:
>> On Mon, Jun 16, 2014 at 12:58 AM, Craig Ringer wrote:
>>> > On 05/30/2014 11:14 PM, Heikki Linnakangas wrote:
>> Yeah. To recap, the failure mode is that if the master crashes and
>> res
On Wed, Jun 18, 2014 at 6:25 PM, Abhijit Menon-Sen
wrote:
> At 2014-06-18 18:10:34 +0530, rahilasye...@gmail.com wrote:
> >
> > palloc() is disallowed in critical sections and we are already in CS
> > while executing this code. So we use malloc().
>
> Are these allocations actually inside a criti
At 2014-06-18 18:25:34 +0530, a...@2ndquadrant.com wrote:
>
> Are these allocations actually inside a critical section? It seems to me
> that the critical section starts further down, but perhaps I am missing
> something.
OK, I was missing that XLogInsert() itself can be called from inside a
criti
At 2014-06-18 18:10:34 +0530, rahilasye...@gmail.com wrote:
>
> palloc() is disallowed in critical sections and we are already in CS
> while executing this code. So we use malloc().
Are these allocations actually inside a critical section? It seems to me
that the critical section starts further do
On 2014-06-18 18:10:34 +0530, Rahila Syed wrote:
> Hello ,
>
> >I have a few preliminary comments about your patch
> Thank you for review comments.
>
> >the patch creates src/common/lz4/.travis.yml, which it shouldn't.
> Agree. I will remove it.
>
> >Shouldn't this use palloc?
> palloc() is disa
Hello ,
>I have a few preliminary comments about your patch
Thank you for review comments.
>the patch creates src/common/lz4/.travis.yml, which it shouldn't.
Agree. I will remove it.
>Shouldn't this use palloc?
palloc() is disallowed in critical sections and we are already in CS while
executing
On Wed, Jun 18, 2014 at 7:47 PM, MauMau wrote:
> From: "Rajeev rastogi"
>
>> Please find the attached patch with only documentation change.
>
>
> I marked this as ready for committer. The patch is good because it matches
> the description in the following page:
>
> http://www.postgresql.org/docs
On Tue, Jun 17, 2014 at 2:16 PM, Andres Freund wrote:
>> But I'm not trying to say that we absolutely have to support that kind
>> of thing; what I am trying to say is that there should be a README or
>> a mailing list post or some such that says: "We thought about how
>> generic to make this. We
* Andrew Dunstan (and...@dunslane.net) wrote:
> I think I'd rather just say "for many data types" or something along
> those lines, rather than imply that there is some obvious rule that
> users should be able to intuit.
Perhaps with a link to where the informaiton about which exist is
available..
* Matheus de Oliveira (matioli.math...@gmail.com) wrote:
> Hi Hackers,
Having read only the subject- +1 from me on the idea. Maybe +1000.
> I was facing a situation were we wanted to set temp_tablespaces to a
> tablespace on a ephemeral disk (yes, it is AWS ephemeral disk), and I know
> many use
On 06/18/2014 01:46 PM, Andres Freund wrote:
On 2014-06-18 12:18:26 +0300, Heikki Linnakangas wrote:
The main problem with using it for geometric types is that you can't easily
CLUSTER the table to make the minmax index effective again. But there are
ways around that.
Which are? Sure you can t
* Peter Geoghegan (p...@heroku.com) wrote:
> On Tue, Jun 17, 2014 at 5:11 PM, Robert Haas wrote:
> > Now, we could. We could come up with an extensible syntax, like this:
> >
> > CHECK relation [ USING { checktype [ '(' arg [, ...] '}' [, ...] ];
>
> That's what I had in mind. Using the same tri
From: "Michael Paquier"
When doing some work on Windows, I noticed that the mkvc specs in
src/tools/msvc use wsock32.lib, which is as far as I understand an
old, obsolete version of the Windows socket library. Wouldn't it make
sense to update the specs to build only with ws2_32.lib like in the
p
On 2014-06-17 16:48:07 -0700, Greg Stark wrote:
> On Tue, Jun 17, 2014 at 11:16 AM, Andres Freund
> wrote:
> > Well, it might be doable to correlate them along one axis, but along
> > both? That's more complicated... And even alongside one axis you
> > already get into problems if your geometrie
On 2014-06-18 12:18:26 +0300, Heikki Linnakangas wrote:
> On 06/17/2014 09:16 PM, Andres Freund wrote:
> >Well, it might be doable to correlate them along one axis, but along
> >both? That's more complicated... And even alongside one axis you
> >already get into problems if your geometries are irr
From: "Rajeev rastogi"
Please find the attached patch with only documentation change.
I marked this as ready for committer. The patch is good because it matches
the description in the following page:
http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html
Regards
MauMau
Hi all
I posted about a possible packaging issue with RHEL 6 PGDG packages for
9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a
prior mail asking about what happened with moving to git hasn't had a
response).
Given that time is a concern with 9.4, I thought I'd raise it here.
Thanks, I've marked this ready for committer.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 06/17/2014 09:16 PM, Andres Freund wrote:
On 2014-06-17 12:14:00 -0400, Robert Haas wrote:
On Tue, Jun 17, 2014 at 12:04 PM, Andres Freund wrote:
Well, I'm not the guy who does things with geometric data, but I don't
want to ignore the significant percentage of our users who are. As
you mu
I wanted to check the patch last time and found a bug effecting
MVC vs MVC part of the join selectivity. Fixed version attached.
Emre Hasegeli :
> Comparing the lists with each other slows down the function when
> statistics set to higher values. To avoid this problem I only use
> log(n) values of
On 06/18/2014 03:30 PM, Craig Ringer wrote:
> There is, IMO, a significant oversight with the include_dir feature.
>
> If a distributor wants to enable it by default at initdb time, they
> can't just turn it on in postgresql.conf.sample, because initdb will die
> when the postgres backend refuses
On Tue, Jun 17, 2014 at 12:30 AM, Abhijit Menon-Sen
wrote:
> (Cc: to pgsql-bugs dropped.)
>
> At 2014-03-17 18:24:55 +1100, kommi.harib...@gmail.com wrote:
>>
>> *** a/doc/src/sgml/xfunc.sgml
>> --- b/doc/src/sgml/xfunc.sgml
>> ***
>> *** 153,159 SELECT clean_emp();
>> --- 153,18
There is, IMO, a significant oversight with the include_dir feature.
If a distributor wants to enable it by default at initdb time, they
can't just turn it on in postgresql.conf.sample, because initdb will die
when the postgres backend refuses to start because the configdir is missing.
Yet the co
On Wed, Jun 18, 2014 at 10:00 AM, Tom Lane wrote:
> Amit Kapila writes:
> > Won't it be possible if we convert malloc calls in backend code to
> > go through wrapper, we already have some precedents of same like
> > guc_malloc, pg_malloc?
>
> We do not have control over mallocs done by third-part
101 - 133 of 133 matches
Mail list logo
