Hi,
On 08/09/2010 12:04 AM, Mark Wong wrote:
I've been playing around with a process based parallel quicksort
(http://github.com/markwkm/quicksort) and I tried to shoehorn it into
postgres because I wanted to see if I could sort more than integers.
I've attached a patch that creates a new GUC to
2010/8/8 Tom Lane
> Itagaki Takahiro writes:
> > "Accessor functions to get so far collected statistics for the current
> > transaction"
> > https://commitfest.postgresql.org/action/patch_view?id=301
>
> > The only issue in the patch is too long view and function names:
> > - pg_stat_transacti
Hello
I was confused when I though so I found a solution of 1 shift/reduce conflict :(
All identificators used for buildin functions have to be a
col_name_keywords or reserved keyword. There is conflict with our
(probably obsolete) feature SELECT colname(tabname). So for this
moment the real solu
On Mon, Aug 9, 2010 at 1:18 AM, Jaime Casanova wrote:
> A few months ago Bruce was doing a hunting of personal Copyrights
> notices, but i still found a lot of files copyrighted to: Regents of
> the University of California and other files copyrighted to
> individuals (ej: almost everything inside
Hello
I am working on Grouping Sets support. The first issue is "cube"
keyword. Contrib module "cube" define a few functions "cube". So if we
want to continue in support this function, then "cube" have to be a
unreserved keyword. But then we have a gram conflict with mentioned
obsolete syntax. I a
On Sun, Aug 8, 2010 at 11:38 PM, Tom Lane wrote:
> Um, but \sf *doesn't* give you anything that's usefully copy and
> pasteable.
Works for me.
\sf ts_debug(regconfig, text)
> And if that were the goal, why doesn't it have an option to
> write to a file?
Well, you cut-and-paste from a terminal
2010/8/9 Robert Haas :
> On Sun, Aug 8, 2010 at 11:38 PM, Tom Lane wrote:
>> Um, but \sf *doesn't* give you anything that's usefully copy and
>> pasteable.
>
> Works for me.
>
> \sf ts_debug(regconfig, text)
>
>> And if that were the goal, why doesn't it have an option to
>> write to a file?
>
> W
On 07/08/10 10:58, Boxuan Zhai wrote:
I have just finished a new patch, with the following feature:
Please include the regression tests in the patch too. Also, I note that
there's a few merge conflicts when applied over CVS HEAD from today, can
you please fix the bitrot?
--
Heikki Linnaka
On 09/08/10 14:47, Heikki Linnakangas wrote:
On 07/08/10 10:58, Boxuan Zhai wrote:
I have just finished a new patch, with the following feature:
Please include the regression tests in the patch too
And the docs changes too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprised
On Mon, Aug 09, 2010 at 12:18:33PM +0200, Pavel Stehule wrote:
> Hello
>
> I am working on Grouping Sets support. The first issue is "cube"
> keyword. Contrib module "cube" define a few functions "cube". So if we
> want to continue in support this function, then "cube" have to be a
> unreserved ke
On Mon, Aug 09, 2010 at 02:27:50PM +0900, Tatsuo Ishii wrote:
> > A few months ago Bruce was doing a hunting of personal Copyrights
> > notices, but i still found a lot of files copyrighted to: Regents
> > of the University of California and other files copyrighted to
> > individuals (ej: almost ev
On Mon, Aug 9, 2010 at 2:02 PM, David Fetter wrote:
>> I am working on Grouping Sets support. The first issue is "cube"
>> keyword. Contrib module "cube" define a few functions "cube". So if we
>> want to continue in support this function, then "cube" have to be a
>> unreserved keyword.
>
> The "c
On Mon, Aug 09, 2010 at 02:23:55PM +0100, Greg Stark wrote:
> On Mon, Aug 9, 2010 at 2:02 PM, David Fetter wrote:
> >> I am working on Grouping Sets support. The first issue is "cube"
> >> keyword. Contrib module "cube" define a few functions "cube". So
> >> if we want to continue in support this
2010/8/9 Greg Stark :
> On Mon, Aug 9, 2010 at 2:02 PM, David Fetter wrote:
>>> I am working on Grouping Sets support. The first issue is "cube"
>>> keyword. Contrib module "cube" define a few functions "cube". So if we
>>> want to continue in support this function, then "cube" have to be a
>>> un
Greg Stark writes:
> Personally I think cube is uncommonly used and CUBE an important
> enough SQL feature that we should just bite the bullet and kill/rename
> the contrib module.
Yeah. It looks to me like CUBE will have to be a type_function_name
keyword (but hopefully not fully reserved), whi
Jaime Casanova writes:
> A few months ago Bruce was doing a hunting of personal Copyrights
> notices, but i still found a lot of files copyrighted to: Regents of
> the University of California and other files copyrighted to
> individuals (ej: almost everything inside src/backend/regex is
> copyrig
Mike Fowler writes:
> Turns out the bug was filed in 2005 (see
> https://bugzilla.gnome.org/show_bug.cgi?id=307061). They are currently
> taking a fairly loose interpretation of the XSLT spec. However that was
> only one aspect of the concern. The other was that no errors were being
> reported
On Mon, Aug 9, 2010 at 10:14 AM, Tom Lane wrote:
> Mike Fowler writes:
>> Turns out the bug was filed in 2005 (see
>> https://bugzilla.gnome.org/show_bug.cgi?id=307061). They are currently
>> taking a fairly loose interpretation of the XSLT spec. However that was
>> only one aspect of the concern
On lör, 2010-08-07 at 16:47 +0100, Mike Fowler wrote:
> To be honest I'm happiest with returning a boolean, even if there is
> some confusion over content only being valid. Though changing the
> return
> value to DOCUMENT/CONTENT/NULL makes things a touch more explicit,
> the
> same results can
Pavel Stehule writes:
> I am working on Grouping Sets support. The first issue is "cube"
> keyword. Contrib module "cube" define a few functions "cube". So if we
> want to continue in support this function, then "cube" have to be a
> unreserved keyword. But then we have a gram conflict with mentio
Robert Haas writes:
> Right. So, what about Mike's idea of extracting this into a new
> contrib module, perhaps contrib/xslt? That might also provide a good
> excuse to jettison any details of the existing interfaces that we
> happen to find unfortunate.
Seems like mostly make-work to me --- we
On Mon, Aug 9, 2010 at 10:20 AM, Peter Eisentraut wrote:
> On lör, 2010-08-07 at 16:47 +0100, Mike Fowler wrote:
>> To be honest I'm happiest with returning a boolean, even if there is
>> some confusion over content only being valid. Though changing the
>> return
>> value to DOCUMENT/CONTENT/NULL
2010/8/9 Tom Lane :
> Pavel Stehule writes:
>> I am working on Grouping Sets support. The first issue is "cube"
>> keyword. Contrib module "cube" define a few functions "cube". So if we
>> want to continue in support this function, then "cube" have to be a
>> unreserved keyword. But then we have a
On Mon, Aug 9, 2010 at 10:45 AM, Pavel Stehule wrote:
> 2010/8/9 Tom Lane :
>> Pavel Stehule writes:
>>> I am working on Grouping Sets support. The first issue is "cube"
>>> keyword. Contrib module "cube" define a few functions "cube". So if we
>>> want to continue in support this function, then
Markus Wanner wrote:
> Hi,
>
> On 07/26/2010 07:16 PM, Robert Haas wrote:
> > Of course, there are other parts of the system (a whole bunch of them)
> > that used shared memory also, and perhaps some of those could be
> > modified to use the dynamic allocator as well. But they're getting by
> > w
2010/8/9 Tom Lane :
> Greg Stark writes:
>> Personally I think cube is uncommonly used and CUBE an important
>> enough SQL feature that we should just bite the bullet and kill/rename
>> the contrib module.
>
> Yeah. It looks to me like CUBE will have to be a type_function_name
> keyword (but hope
Hi,
I have created regular table t1 and temp table t1. Regclass and \d
command do not seem to distinguish them. Is this normal?
test=# create table t1(i int);
CREATE TABLE
test=# select 't1'::regclass::oid;
oid
-
1470776
(1 row)
test=# create temp table t1(i int, j int);
CREATE TA
On Mon, Aug 9, 2010 at 11:02 AM, Bruce Momjian wrote:
> I am not sure threads would greatly help us. The major problem is that
> all of our our structures are currently contiguous in memory for quick
> access. I don't see how threading would help with that. We could use
> realloc(), but we can
On Mon, Aug 9, 2010 at 11:06 AM, Pavel Stehule wrote:
> 2010/8/9 Tom Lane :
>> Greg Stark writes:
>>> Personally I think cube is uncommonly used and CUBE an important
>>> enough SQL feature that we should just bite the bullet and kill/rename
>>> the contrib module.
>>
>> Yeah. It looks to me lik
Tatsuo Ishii writes:
> I have created regular table t1 and temp table t1. Regclass and \d
> command do not seem to distinguish them. Is this normal?
It works for me. Are you using clean sources?
regression=# create table t1(i int);
CREATE TABLE
regression=# select 't1'::regclass::oid;
oid
2010/8/9 Robert Haas :
> On Mon, Aug 9, 2010 at 11:06 AM, Pavel Stehule
> wrote:
>> 2010/8/9 Tom Lane :
>>> Greg Stark writes:
Personally I think cube is uncommonly used and CUBE an important
enough SQL feature that we should just bite the bullet and kill/rename
the contrib module
> It works for me. Are you using clean sources?
>
> regression=# create table t1(i int);
> CREATE TABLE
> regression=# select 't1'::regclass::oid;
> oid
>
> 127671
> (1 row)
>
> regression=# create temp table t1(i int, j int);
> CREATE TABLE
> regression=# select 't1'::regclass::o
On Aug 8, 2010, at 8:38 PM, Tom Lane wrote:
> Um, but \sf *doesn't* give you anything that's usefully copy and
> pasteable. And if that were the goal, why doesn't it have an option to
> write to a file?
>
> But it's really the line numbers shoved in front that I'm on about here.
> I can't see *a
2010/8/9 David E. Wheeler :
> On Aug 8, 2010, at 8:38 PM, Tom Lane wrote:
>
>> Um, but \sf *doesn't* give you anything that's usefully copy and
>> pasteable. And if that were the goal, why doesn't it have an option to
>> write to a file?
>>
>> But it's really the line numbers shoved in front that
Hi,
On 08/09/2010 05:02 PM, Bruce Momjian wrote:
[ Sorry to be jumping into this thread late.]
No problem at all.
I am not sure threads would greatly help us.
Note that I'm absolutely, certainly not advocating the use of threads
for Postgres.
The major problem is that
all of our our st
Robert Haas writes:
> So imagine that thread-or-process A allocates allocates a new chunk of
> memory and then writes a pointer to the new chunk in a previously
> allocated section of memory. Thread-or-process B then follows the
> pointer. In a threaded model, this is guaranteed to be safe. In
Robert Haas wrote:
> On Mon, Aug 9, 2010 at 11:02 AM, Bruce Momjian wrote:
> > I am not sure threads would greatly help us. ?The major problem is that
> > all of our our structures are currently contiguous in memory for quick
> > access. ?I don't see how threading would help with that. ?We could u
Markus Wanner wrote:
> Hi,
>
> On 08/09/2010 05:02 PM, Bruce Momjian wrote:
> > [ Sorry to be jumping into this thread late.]
>
> No problem at all.
>
> > I am not sure threads would greatly help us.
>
> Note that I'm absolutely, certainly not advocating the use of threads
> for Postgres.
>
>
Tom Lane wrote:
> Dave Page writes:
> > On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane wrote:
> >> I've applied a (rather hurried) patch for this for 9.0beta4.
>
> > Thanks. Bruce seemed to think it affected 8.4.4 as well - would that
> > be the case, or is it something else?
>
> He's mistaken. Th
Dear developers,
I'm PhD candidate in Brazil and a newbie on postgresql developement, sorry
for any silly questions. I implemented a new algorithm for range search
using universal b-tree but I don't have a clue how to integrate it into
postgresql.
Where I can find the resources about it?
I don't
Bruce Momjian wrote:
> > With our process-based design, the default is private memory (i.e. not
> > shared). If you need shared memory, you must specify a certain amount in
> > advance. That chunk of shared memory then is reserved and can't ever be
> > used by another subsystem. Even if you bare
Bruce Momjian writes:
> Tom Lane wrote:
>> Dave Page writes:
>>> Thanks. Bruce seemed to think it affected 8.4.4 as well - would that
>>> be the case, or is it something else?
>>
>> He's mistaken. The bug is in all the branches, but there have been no
>> releases with it except 9.0beta3. I wil
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Dave Page writes:
> >>> Thanks. Bruce seemed to think it affected 8.4.4 as well - would that
> >>> be the case, or is it something else?
> >>
> >> He's mistaken. The bug is in all the branches, but there have been no
> >> releases
Pavel Stehule wrote:
> 2010/7/21 Itagaki Takahiro :
> > 2010/7/20 Pavel Stehule :
> >> here is a new version - new these functions are not a strict and
> >> function to_string is marked as stable.
> >
> > We have array_to_string(anyarray, text) and string_to_array(text, text),
> > and you'll introd
On Mon, Aug 9, 2010 at 5:31 PM, Daniel Oliveira
wrote:
> I don't need to change B-tree estructure. I just need integrate my encode
> function that transforms multiple keys into one key by bit-interleaving and
> to acess elements given several intervals (range search).
You could build a "expressio
Apparently, the message I sent (quoted below) didn't make it to
-hackers. I know that Pavel received the message, as he replied to
it. I'm calling shenanigans on the mailing list server, but in the
meantime, here are those diffs again.
On 31 July 2010 07:37, Brendan Jurd wrote:
> Hi Pavel,
>
>
In gist consitent method support only filtering strategies. For such
strategies consistent method returns true if subtree can contain matching
node and false otherwise. Knngist introduce also order by strategies. For
filtering strategies knngist consistent method returns 0 if subtree can
contain m
For research purpose, I think that expression index is a good idea. I just
want to do a proof of concept.
The other issue is that my algorithm break a z-order interval into several
intervals that represents the query box. How should I create it without
creating any overhead?
Best regards,
daniel
On Mon, 2010-08-09 at 11:41 -0400, Tom Lane wrote:
> Robert Haas writes:
> > So imagine that thread-or-process A allocates allocates a new chunk of
> > memory and then writes a pointer to the new chunk in a previously
> > allocated section of memory. Thread-or-process B then follows the
> > point
On Sat, 2010-08-07 at 16:11 -0700, Gordon Shannon wrote:
> So, I guess my real question here is, what happened to the "missing"
> 100 items? If it was HOT prune, can anyone summarize what that does?
Itagaki already explained that the second DELETE would have removed the
100 dead rows you conside
On Mon, Aug 9, 2010 at 11:24 AM, Pavel Stehule wrote:
>> They name to be type_func_keywords, perhaps, but not fully reserved.
>> And they'd still need that treatment anyway. Even if cube(whatever)
>> can't mean "extract a column called cube from table whatever", it can
>> still mean "call a funct
2010/8/9 Robert Haas :
> On Mon, Aug 9, 2010 at 11:24 AM, Pavel Stehule
> wrote:
>>> They name to be type_func_keywords, perhaps, but not fully reserved.
>>> And they'd still need that treatment anyway. Even if cube(whatever)
>>> can't mean "extract a column called cube from table whatever", it
Hi,
On 08/09/2010 05:41 PM, Tom Lane wrote:
... and on some platforms, it'll be flat out impossible. We looked at
this years ago and concluded that changing the size of the shmem segment
after postmaster start was impractical from a portability standpoint.
I have not seen anything to change tha
Hi,
On 08/09/2010 06:10 PM, Bruce Momjian wrote:
My point is that you can treat malloc the same as "add shared memory",
to some extent, with the same limiations.
Once one of the SLRU buffers is full, it cannot currently allocate from
another SLRU buffer's unused memory area. That memory there
On Mon, Aug 9, 2010 at 11:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> So imagine that thread-or-process A allocates allocates a new chunk of
>> memory and then writes a pointer to the new chunk in a previously
>> allocated section of memory. Thread-or-process B then follows the
>> pointer.
On Mon, Aug 9, 2010 at 12:03 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Aug 9, 2010 at 11:02 AM, Bruce Momjian wrote:
>> > I am not sure threads would greatly help us. ?The major problem is that
>> > all of our our structures are currently contiguous in memory for quick
>> > access.
On Mon, Aug 9, 2010 at 12:31 PM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> > With our process-based design, the default is private memory (i.e. not
>> > shared). If you need shared memory, you must specify a certain amount in
>> > advance. That chunk of shared memory then is reserved and can'
On Mon, Aug 9, 2010 at 1:50 PM, Simon Riggs wrote:
> On Sat, 2010-08-07 at 16:11 -0700, Gordon Shannon wrote:
>
>> So, I guess my real question here is, what happened to the "missing"
>> 100 items? If it was HOT prune, can anyone summarize what that does?
>
> Itagaki already explained that the se
On 09/08/10 21:21, Robert Haas wrote:
On Mon, Aug 9, 2010 at 1:50 PM, Simon Riggs wrote:
Any SQL statement that reads a block can do HOT pruning, if the block is
otherwise unlocked.
Where does heap_page_prune() get called from in the DELETE path?
heapgetpage()
--
Heikki Linnakangas
Ent
On Mon, Aug 9, 2010 at 2:23 PM, Heikki Linnakangas
wrote:
> On 09/08/10 21:21, Robert Haas wrote:
>>
>> On Mon, Aug 9, 2010 at 1:50 PM, Simon Riggs wrote:
>>>
>>> Any SQL statement that reads a block can do HOT pruning, if the block is
>>> otherwise unlocked.
>>
>> Where does heap_page_prune() ge
Hi,
On 08/09/2010 06:31 PM, Bruce Momjian wrote:
Let me be more concrete. Suppose you are using threads, and you want to
increase your shared memory from 20MB to 30MB. How do you do that?
There's absolutely no need to pre-allocate 20 MB in advance in a
threaded environment. You just allocat
On Sun, Aug 8, 2010 at 4:28 PM, Alexander Korotkov wrote:
> In gist consitent method support only filtering strategies. For such
> strategies consistent method returns true if subtree can contain matching
> node and false otherwise. Knngist introduce also order by strategies. For
> filtering strat
Markus Wanner wrote:
> Hi,
>
> On 08/09/2010 06:10 PM, Bruce Momjian wrote:
> > My point is that you can treat malloc the same as "add shared memory",
> > to some extent, with the same limiations.
>
> Once one of the SLRU buffers is full, it cannot currently allocate from
> another SLRU buffer's
Robert Haas wrote:
> On Mon, Aug 9, 2010 at 12:31 PM, Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >> > With our process-based design, the default is private memory (i.e. not
> >> > shared). If you need shared memory, you must specify a certain amount in
> >> > advance. That chunk of shared mem
Markus Wanner wrote:
> Hi,
>
> On 08/09/2010 06:31 PM, Bruce Momjian wrote:
> > Let me be more concrete. Suppose you are using threads, and you want to
> > increase your shared memory from 20MB to 30MB. How do you do that?
>
> There's absolutely no need to pre-allocate 20 MB in advance in a
>
On 08/09/2010 08:33 PM, Bruce Momjian wrote:
Robert Haas wrote:
You probably wouldn't do either of those things. You'd just allocate
small chunks here and there for whatever you need them for.
Well, then we do that with shared memory then --- my point is that it is
the same problem with threa
On Mon, Aug 9, 2010 at 2:28 PM, Markus Wanner wrote:
> Another issue to be discussed would be the limits of sharing free memory
> between subsystems. Maybe we even reach the conclusion that we absolutely
> *want* fixed maximum sizes for every single subsystem so as to be able to
> guarantee a cert
Here is a patch for host name support in pg_hba.conf. I have reviewed
various past threads about this, and there appeared to have been a 50/50
split of for and against reverse lookup. I went with the reverse
lookup, because
0) I like it.
1) It is more secure.
2) It allows extending it to wildc
On Mon, Aug 9, 2010 at 2:33 PM, Bruce Momjian wrote:
>> > Let me be more concrete. ?Suppose you are using threads, and you want to
>> > increase your shared memory from 20MB to 30MB. ?How do you do that? ?If
>> > you want it contiguous, you have to use realloc, which might move the
>> > pointer. ?
On Sat, 7 Aug 2010, Kris Jurka wrote:
On Fri, 6 Aug 2010, James William Pye wrote:
I think there's a snag in the patch:
postgres=# COPY data FROM '/Users/jwp/DATA.bcopy' WITH BINARY;
ERROR: row field count is -1, expected 1
CONTEXT: COPY data, line 4
Probably a quick/small fix away, I im
Markus Wanner wrote:
> On 08/09/2010 08:33 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> You probably wouldn't do either of those things. You'd just allocate
> >> small chunks here and there for whatever you need them for.
> >
> > Well, then we do that with shared memory then --- my point i
Robert Haas wrote:
> On Mon, Aug 9, 2010 at 2:33 PM, Bruce Momjian wrote:
> >> > Let me be more concrete. ?Suppose you are using threads, and you want to
> >> > increase your shared memory from 20MB to 30MB. ?How do you do that? ?If
> >> > you want it contiguous, you have to use realloc, which mig
Peter Eisentraut wrote:
> The client's IP address (known from the kernel)
Some machines have several IP addresses; how is that handled?
> is reverse looked up, which results in a host name.
Some IP addresses have several host names, including in reverse
lookup; how is that handled?
-Kevi
On 9 August 2010 19:47, Peter Eisentraut wrote:
> Here is a patch for host name support in pg_hba.conf. I have reviewed
> various past threads about this, and there appeared to have been a 50/50
> split of for and against reverse lookup. I went with the reverse
> lookup, because
>
> 0) I like it
On 08/09/2010 08:49 PM, Bruce Momjian wrote:
Markus Wanner wrote:
That's what my patch allows you to do, yes. Currently you are bound to
pre-allocate shared memory at startup. Or how would you allocate small
chunks from shared memory at the moment?
We don't --- we allocate it all at startup.
On Mon, Aug 9, 2010 at 2:50 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Aug 9, 2010 at 2:33 PM, Bruce Momjian wrote:
>> >> > Let me be more concrete. ?Suppose you are using threads, and you want to
>> >> > increase your shared memory from 20MB to 30MB. ?How do you do that? ?If
>> >>
Robert Haas wrote:
> On Mon, Aug 9, 2010 at 2:50 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Mon, Aug 9, 2010 at 2:33 PM, Bruce Momjian wrote:
> >> >> > Let me be more concrete. ?Suppose you are using threads, and you want
> >> >> > to
> >> >> > increase your shared memory from 20MB
On 08/09/2010 08:50 PM, Bruce Momjian wrote:
You effectively have to add infrastructure to add/remove shared memory
segments to match memory requests. It is another step, but it is the
same behavior.
That's of no use without a dynamic allocator, I think. Or else it is a
vague description of a
On Mon, Aug 9, 2010 at 2:47 PM, Peter Eisentraut wrote:
> Here is a patch for host name support in pg_hba.conf. I have reviewed
> various past threads about this, and there appeared to have been a 50/50
> split of for and against reverse lookup. I went with the reverse
> lookup, because
>
> 0) I
On 08/09/2010 09:00 PM, Bruce Momjian wrote:
You could allocate shared memory in chunks and then pass that out to
requestors, the same way sbrk() does it.
sbrk() is described [1] as a "low-level memory allocator", which "is
typically only used by the high-level malloc memory allocator
impleme
On Mon, Aug 9, 2010 at 3:00 PM, Bruce Momjian wrote:
>> That would be one way to tackle the problem, but there are
>> difficulties. If we just created new shared memory segments at need,
>> we might end up with a lot of shared memory segments. I suspect that
>> would get complicated and present
Hi,
On 08/09/2010 08:45 PM, Robert Haas wrote:
Yeah, I think that's a real concern. I think we need to distinguish
memory needs from memory wants. Ideally, we'd like our entire
database to be cached in RAM. But that may or may not be feasible, so
we page what we can into shared_buffers and pa
Markus Wanner writes:
> However, I'd like to get back to the original intent of the posted
> patch. Which is about dynamically allocating memory *within a fixed size
> pool*.
> That's something SRLU or shared_buffers do to some extent, but with lots
> of limitations. And without the ability to
Robert Haas writes:
> On Mon, Aug 9, 2010 at 11:41 AM, Tom Lane wrote:
>> ... and on some platforms, it'll be flat out impossible. We looked at
>> this years ago and concluded that changing the size of the shmem segment
>> after postmaster start was impractical from a portability standpoint.
>>
Peter Eisentraut writes:
> Here is a patch for host name support in pg_hba.conf.
My recollection is that the previous discussions got stuck on the cost
of doing DNS lookups for every connect; and the obvious solution of
trying to cache the names was shot down on the basis of not knowing when
to f
Hi,
On 08/09/2010 09:14 PM, Tom Lane wrote:
As far as SLRU is concerned, the already-agreed-to plan is to get rid of
the separate arenas for SLRU and merge those things into the main shared
buffers arena.
I didn't know about that plan. Sounds good. (I'm personally thinking
this is trying to s
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> > The client's IP address (known from the kernel)
>
> Some machines have several IP addresses; how is that handled?
Sounds like he already described it, or I read it wrong. The fact that
some machines have several IP addresses hardly matte
2010/7/26 KaiGai Kohei :
> The attached patches are revised ones, as follows.
I think this is pretty good, and I'm generally in favor of committing
it. Some concerns:
1. Since nobody has violently objected to the comment.c refactoring
patch I recently proposed, I'm hopeful that can go in. And i
Brendan Jurd writes:
>> I have attached v4 of the patch against HEAD, and also an incremental
>> patch showing just my changes against v3.
>>
>> I'll mark this as ready for committer.
Looking at this, I want to question the implode/explode naming. I think
those names are too cute by half, not p
On Mon, Aug 9, 2010 at 3:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 9, 2010 at 11:41 AM, Tom Lane wrote:
>>> ... and on some platforms, it'll be flat out impossible. We looked at
>>> this years ago and concluded that changing the size of the shmem segment
>>> after postmaster s
On Mon, Aug 9, 2010 at 4:08 PM, Tom Lane wrote:
> Brendan Jurd writes:
>>> I have attached v4 of the patch against HEAD, and also an incremental
>>> patch showing just my changes against v3.
>>>
>>> I'll mark this as ready for committer.
>
> Looking at this, I want to question the implode/explode
Robert Haas writes:
> On Mon, Aug 9, 2010 at 3:20 PM, Tom Lane wrote:
>> It's not portable. That's exactly what we were looking into back when.
> Uggh, that sucks. Can you provide any more details?
You don't really have to go further than consulting the relevant
standards, eg SUS says at
http
On Mon, Aug 9, 2010 at 4:08 PM, Tom Lane wrote:
> Brendan Jurd writes:
>>> I have attached v4 of the patch against HEAD, and also an incremental
>>> patch showing just my changes against v3.
>>>
>>> I'll mark this as ready for committer.
>
> Looking at this, I want to question the implode/explode
LinkedIn
Hector Beyers souhaite se connecter à vous sur LinkedIn :
--
Amine,
I'd like to add you to my professional network on LinkedIn.
- Hector Beyers
Accepter l'invitation de Hector Beyers
http://www.linkedin.com/e/cm7uxn-gcns21oh-6h/VWCdri
Robert Haas wrote:
> I don't think it's going to be too easy to provide, short of (as
> Tom says) moving to the MySQL model of many threads working in a
> single process.
Well, it's a bit misleading to refer to it as the MySQL model. It's
used by Microsoft SQL Server, MySQL, Informix, and Syb
Merlin Moncure writes:
> Is there any reason why array functions need the type prefix when
> other type conversion functions don't? Why didn't we name unnest()
> array_unnest()?
UNNEST() is in the standard, IIRC, so you'd have to ask the SQL
committee that. (And no, they're not exactly being co
On Aug 9, 2010, at 1:10 PM, Robert Haas wrote:
>> My first thought is that we should go back to the string_to_array and
>> array_to_string names. The key reason not to use those names was the
>> conflict with the old functions if you didn't specify a third argument,
>> but where is the advantage
On Mon, Aug 9, 2010 at 4:34 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Is there any reason why array functions need the type prefix when
>> other type conversion functions don't? Why didn't we name unnest()
>> array_unnest()?
>
> UNNEST() is in the standard, IIRC, so you'd have to ask the S
On Mon, Aug 9, 2010 at 4:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 9, 2010 at 3:20 PM, Tom Lane wrote:
>>> It's not portable. That's exactly what we were looking into back when.
>
>> Uggh, that sucks. Can you provide any more details?
>
> You don't really have to go further t
On 05/08/10 17:14, Fujii Masao wrote:
I'm thinking to make users register and unregister each standbys via SQL
functions like register_standby() and unregister_standby():
The register/unregister facility should be accessible from the streaming
replication connection, so that you don't need to
1 - 100 of 140 matches
Mail list logo
