I'm sorry I misunderstood about the extension you wrote.
Is there some way not to use shared memory for it?
Cheers,
David.
On Sat, Jan 04, 2014 at 11:46:25AM +0400, knizhnik wrote:
> Hi David,
>
> Sorry, but I do not completely understand your suggestions:
>
> 1. IMCS really contains single pa
On 01/04/2014 12:05 PM, David Fetter wrote:
I'm sorry I misunderstood about the extension you wrote.
Is there some way not to use shared memory for it?
No, IMCS ("In-Memory Columnar Store") is storing data in shared memory.
Certainly I could allocate shared memory myself, but due to portabilit
I am not sure it worth reporting but it took me a while to find out
what is wrong with comparing two values returned from
the bitncmp function. It does not return -1, 1 or 0 as it is written
on the comment when n % 8 == 0.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Sat, Jan 4, 2014 at 1:33 AM, Gabriele Bartolini <
gabriele.bartol...@2ndquadrant.it> wrote:
> Hello,
>
> please find attached the patch that adds basic support for the
> pg_stat_archiver system view, which allows users that have continuous
> archiving procedures in place to keep track of some
Presumably "classifyConditions", not "classifyClauses", is meant.
Patch attached.
Regards
Ian Barwick
diff --git a/contrib/postgres_fdw/postgres_fdw.c
b/contrib/postgres_fdw/postgres_fdw.c
index 246a3a9..46ea032 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgre
Hi Magnus,
Il 04/01/14 13:25, Magnus Hagander ha scritto:
> My first reaction was that exactly those two things were missing. And
> then I read your whole email :)
:)
> With those two, I think it would make much sense to have a view like
> this.
Ok, I will prepare version 2 with those.
> I'd s
On Fri, Jan 3, 2014 at 10:12 AM, Andres Freund wrote:
> On 2013-12-12 10:01:21 -0500, Robert Haas wrote:
>> On Thu, Dec 12, 2013 at 7:04 AM, Andres Freund
>> wrote:
>> > I think there'll always be a bit of a difference between slots for
>> > physical and logical data, even if 90% of the implemen
On Fri, Jan 3, 2014 at 9:11 AM, Alvaro Herrera wrote:
> Robert Haas escribió:
>> On Mon, Dec 30, 2013 at 10:59 PM, Alvaro Herrera
>> wrote:
>> > One problem I see is length of time before freezing multis: they live
>> > for far too long, causing the SLRU files to eat way too much disk space.
>> >
On Fri, Jan 03, 2014 at 04:46:23PM +0100, Florian Weimer wrote:
> On 01/03/2014 04:20 PM, Tom Lane wrote:
>
> >I think Florian has a good point there, and the reason is this: what
> >you are talking about will be of exactly zero use to applications that
> >want to see the results of one query befo
Hello
I am thinking how to implement a assertions and tracking to plpgsql. This
area is not strict and clear - everybody would little bit different
functionality - and implementation can be different if someone use a psql
as main client or some GUI. So I am sceptical to implement assertion
directl
Enviado via iPhone
> Em 02/01/2014, às 22:16, Robert Haas escreveu:
>
>> On Thu, Jan 2, 2014 at 4:19 AM, Andres Freund wrote:
>> On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote:
We use the namespace "ext" to the internal code
(src/backend/access/common/reloptions.c) skip some valida
On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello wrote:
>> I continue to think that the case for having this feature at all has
>> not been well-made.
>
> We can use this feature to store any custom GUC for relations, attributes and
> functions also.
>
> Some use cases:
> * extension options
> * c
On 2014-01-04 11:54:46 -0500, Robert Haas wrote:
> On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello
> wrote:
> >> I continue to think that the case for having this feature at all has
> >> not been well-made.
> >
> > We can use this feature to store any custom GUC for relations, attributes
> > and
Robert Haas writes:
> As far as back-patching the GUCs, my thought would be to back-patch
> them but mark them GUC_NOT_IN_SAMPLE in 9.3, so we don't have to touch
> the default postgresql.conf.
That seems bizarre and pointless.
Keep in mind that 9.3 is still wet behind the ears and many many peo
Pavel Stehule writes:
> I propose a enhance the PLpgSQL_plugin struct by a new hook
> void (*pragma)(PLpgSQL_execstate *estate, PLpgSQL_pragma
> *pragma_stmt)
I repeat what I said a couple of days ago: it's a very bad idea to be
enabling more plpgsql plugins as long as the infrastructure c
Andres Freund writes:
> On 2014-01-04 11:54:46 -0500, Robert Haas wrote:
>> Well, as I said before, somebody can make their own configuration
>> table and store stuff there, rather than using pg_class.reloptions.
>> As I recall, the only response to that proposal was "well, they might
>> not want
Emre Hasegeli writes:
> I am not sure it worth reporting but it took me a while to find out
> what is wrong with comparing two values returned from
> the bitncmp function. It does not return -1, 1 or 0 as it is written
> on the comment when n % 8 == 0.
Yeah, should say "<0, >0, or 0", I guess. W
Ian Lawrence Barwick writes:
> Presumably "classifyConditions", not "classifyClauses", is meant.
Hm, I think this got missed in a bout of renaming. Will apply, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
2014/1/4 Tom Lane
> Pavel Stehule writes:
> > I propose a enhance the PLpgSQL_plugin struct by a new hook
> > void (*pragma)(PLpgSQL_execstate *estate, PLpgSQL_pragma
> > *pragma_stmt)
>
> I repeat what I said a couple of days ago: it's a very bad idea to be
> enabling more plpgsql plugin
On 2014-01-04 13:00:03 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-01-04 11:54:46 -0500, Robert Haas wrote:
> >> Well, as I said before, somebody can make their own configuration
> >> table and store stuff there, rather than using pg_class.reloptions.
> >> As I recall, the only resp
Andres Freund writes:
> On 2014-01-04 13:00:03 -0500, Tom Lane wrote:
>> Assuming that such examples are forthcoming, though, I think my main
>> objection to this proposal is the "ext." prefix, which seems precisely
>> 100% useless, not to mention inconsistent with the naming of custom GUCs,
>> wh
On 2014-01-04 14:06:19 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-01-04 13:00:03 -0500, Tom Lane wrote:
> >> Assuming that such examples are forthcoming, though, I think my main
> >> objection to this proposal is the "ext." prefix, which seems precisely
> >> 100% useless, not to me
knizhnik writes:
> On 01/04/2014 12:05 PM, David Fetter wrote:
>> Is there some way not to use shared memory for it?
> No, IMCS ("In-Memory Columnar Store") is storing data in shared memory.
It would probably be better if it made use of the dynamic shared memory
features that exist in HEAD.
Andres Freund writes:
> On 2014-01-04 14:06:19 -0500, Tom Lane wrote:
>> And if we have ext. as a prefix, exactly what prevents conflicts in the
>> second part of the name? Nothing, that's what. It's useless.
> Uh? We are certainly not going to add core code that defines relation
> options with
On 01/04/2014 11:11 PM, Tom Lane wrote:
knizhnik writes:
On 01/04/2014 12:05 PM, David Fetter wrote:
Is there some way not to use shared memory for it?
No, IMCS ("In-Memory Columnar Store") is storing data in shared memory.
It would probably be better if it made use of the dynamic shared mem
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I've committed this after significant editorialization --- most
> Tom> notably, I pushed control of the sort step into the aggregate
> Tom> support functions.
> Initial tests suggest that your version is ~40% slower than ours on
> some
On Fri, Jan 3, 2014 at 9:05 AM, Amit Kapila wrote:
> On Fri, Jan 3, 2014 at 12:51 AM, Heikki Linnakangas
> wrote:
>> On 01/02/2014 02:24 PM, Rushabh Lathia wrote:
>>> Do you think we should detoast the local variable before
>>> RollbackAndReleaseCurrentSubTransaction ? Or any other options ?
>>
From: "Michael Meskes"
On Sat, Dec 28, 2013 at 08:04:09AM +0900, MauMau wrote:
OK, I'll run the ECPG regression test on Solaris without the patch.
Please wait until Jan 6 2014 or so, because we've just entered new
year holidays here in Japan.
Sure, we're no in a particular hurry.
I ran the
From: "Peter Eisentraut"
On 12/25/13, 6:40 AM, MauMau wrote:
pg_regress must wait for postgres to terminate by calling waitpid(),
because it invoked postgres directly. The attached
pg_regress_pg_stop.patch does this. If you like the combination of this
and the original fix for pg_ctl in one p
From: "Noah Misch"
I agree that English consistently beats mojibake. I question whether that
makes up for the loss of translation when encodings do happen to match,
particularly for non-technical errors like a mistyped password. The
everything-UTF8 scenario appears often, perhaps explaining in
On Sun, Jan 5, 2014 at 12:00 PM, Tom Lane wrote:
>
>
> Looking at this example makes me wonder if it wouldn't be worthwhile to
> provide a way to reset and re-use a tuplesort object, instead of redoing
> all the lookup work involved. Or maybe just find a way to cache the
> catalog lookups that ar
31 matches
Mail list logo
