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 patch
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 portability
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
+++
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
On Fri, Jan 3, 2014 at 10:12 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-12-12 10:01:21 -0500, Robert Haas wrote:
On Thu, Dec 12, 2013 at 7:04 AM, Andres Freund and...@2ndquadrant.com
wrote:
I think there'll always be a bit of a difference between slots for
physical and logical
On Fri, Jan 3, 2014 at 9:11 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Robert Haas escribió:
On Mon, Dec 30, 2013 at 10:59 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
One problem I see is length of time before freezing multis: they live
for far too long, causing the SLRU
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 before
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
Enviado via iPhone
Em 02/01/2014, às 22:16, Robert Haas robertmh...@gmail.com escreveu:
On Thu, Jan 2, 2014 at 4:19 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote:
We use the namespace ext to the internal code
On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello fabriziome...@gmail.com 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
On 2014-01-04 11:54:46 -0500, Robert Haas wrote:
On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello fabriziome...@gmail.com
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,
Robert Haas robertmh...@gmail.com 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
Pavel Stehule pavel.steh...@gmail.com 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
Andres Freund and...@2ndquadrant.com 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
Emre Hasegeli e...@hasegeli.com 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
Ian Lawrence Barwick barw...@gmail.com 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)
2014/1/4 Tom Lane t...@sss.pgh.pa.us
Pavel Stehule pavel.steh...@gmail.com 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
On 2014-01-04 13:00:03 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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,
Andres Freund and...@2ndquadrant.com 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
On 2014-01-04 14:06:19 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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,
knizhnik knizh...@garret.ru 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
Andres Freund and...@2ndquadrant.com 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
On 01/04/2014 11:11 PM, Tom Lane wrote:
knizhnik knizh...@garret.ru 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
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us 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
On Fri, Jan 3, 2014 at 9:05 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, Jan 3, 2014 at 12:51 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 01/02/2014 02:24 PM, Rushabh Lathia wrote:
Do you think we should detoast the local variable before
From: Michael Meskes mes...@postgresql.org
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
From: Peter Eisentraut pete...@gmx.net
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
From: Noah Misch n...@leadboat.com
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,
On Sun, Jan 5, 2014 at 12:00 PM, Tom Lane t...@sss.pgh.pa.us 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
31 matches
Mail list logo
