Gokulakannan Somasundaram wrote:
> Hi,
> As you all know, Index Organized tables are a way by which we can
> automatically cluster the data based on the primary key. While i was
> thinking about an implementation for postgres, it looks like an impossible
> with the current ideologies. In an IOT
On Fri, Feb 19, 2010 at 7:54 PM, Heikki Linnakangas
wrote:
> Heikki Linnakangas wrote:
>> Magnus Hagander wrote:
>>> Well, it's going to make the process that reads the WAL cause actual
>>> physical I/O... That'll take a chunk out of your total available I/O,
>>> which is likely to push you to the
Fujii Masao writes:
> + Free(xldir);
> s/Free/FreeDir ?
Yeah, that too. I think it's all good now, but please test.
One thing I was wondering was whether the stat-wrong-file problem
could explain the buildfarm failures that we thought were evidence
of a portability issue. I was tempted to
It is currently 22:21:59 EST here. At 21:50 I committed a fix to
copydir.c that cleaned up a couple of thinkos by Greg, including
a misspelling that had been making all the builds fail for several
hours. I went to see if any of the buildfarm had gone green yet,
and indeed half a dozen members had
On Thu, Feb 18, 2010 at 01:51:08PM -0800, David Fetter wrote:
> Folks,
>
> While hacking on PL/Parrot, I ran across an issue where when trying
> to load PL/pgsql, it's done unconditionally and fails. How do we
> fix pg_regress to be a little more subtle about this?
For now, and for the archives,
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Attached is a draft patch (no doc changes) that implements CREATE OR
> >> REPLACE LANGUAGE
>
> > How is pg_migrator affected by this? It always loads the the dump as
> > the super-user. How will the pg_dump use CREATE OR REPLACE L
Bruce Momjian writes:
> Tom Lane wrote:
>> Attached is a draft patch (no doc changes) that implements CREATE OR
>> REPLACE LANGUAGE
> How is pg_migrator affected by this? It always loads the the dump as
> the super-user. How will the pg_dump use CREATE OR REPLACE LANGUAGE?
pg_dump would issue
Robert Haas writes:
> On Sun, Feb 21, 2010 at 1:21 PM, Tom Lane wrote:
>> It will be owned by the bootstrap superuser, so the case is exactly
>> the one that a non-superuser DBA would be faced with.
> Or even a superuser other than the bootstrap superuser, no? I dump
> out the DB on my 8.4 serv
Simon Riggs writes:
> There is currently no way to run a separate daemon process that runs
> user code as part of Postgres, so that the startup code gets run
> immediately we startup, re-run if we crash and shut down cleanly when
> the server does. If there were some way to run arbitrary code in a
Tom Lane wrote:
> Robert Haas writes:
> > On Feb 20, 2010, at 10:56 PM, Tom Lane wrote:
> >> There is a very clear set of behaviors that CORL ought to have given
> >> the precedents of our other COR commands. If we don't make it do
> >> things that way then we are going to surprise users, and we
Hi,
As you all know, Index Organized tables are a way by which we can
automatically cluster the data based on the primary key. While i was
thinking about an implementation for postgres, it looks like an impossible
with the current ideologies. In an IOT, if a record gets updated, we need to
mark
On Sun, Feb 21, 2010 at 1:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I'm a big fan of CREATE OR REPLACE anything so I like the patch
>> regardless of whether it solves the current problem, but having said
>> that, I'm not clear on whether it does in fact solve the current
>> problem.
Robert Haas writes:
> Well, I'm a big fan of CREATE OR REPLACE anything so I like the patch
> regardless of whether it solves the current problem, but having said
> that, I'm not clear on whether it does in fact solve the current
> problem. When PL/pgsql is installed by default, is it going to en
On Sun, Feb 21, 2010 at 12:54 PM, Simon Riggs wrote:
> We've just rejected Knn-gist indexes as "not enough time for 9.0", which
> is a considerable disappointment for many people.
>
> We already have a pluggable index API, but not one that supports
> recoverability.
>
> It is a simple patch to add
Simon Riggs writes:
> We already have a pluggable index API, but not one that supports
> recoverability.
> It is a simple patch to add recoverability to the index API, if we have
> the will to do so.
I suggest you go re-read the archives before asserting this is a simple
no-thought-required fix.
On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs wrote:
> On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
>> Dimitri Fontaine writes:
>> > Dave Page writes:
>> >> Why not just use pgAgent? It's far more flexible than the design
>> >> you've suggested, and already exists.
>>
>> > What would it tak
On Sun, Feb 21, 2010 at 1:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Feb 21, 2010 at 10:17 AM, Lucas wrote:
>>> I wonder if the scheduler already existed before the
>>> implementation of the autovacuum, its implementation would
>>> not be a function executed by the in-core schedul
On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
> Dimitri Fontaine writes:
> > Dave Page writes:
> >> Why not just use pgAgent? It's far more flexible than the design
> >> you've suggested, and already exists.
>
> > What would it take to have it included in core,
>
> I don't think this reall
On Sun, Feb 21, 2010 at 12:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Feb 20, 2010, at 10:56 PM, Tom Lane wrote:
>>> There is a very clear set of behaviors that CORL ought to have given
>>> the precedents of our other COR commands. If we don't make it do
>>> things that way then we are
Robert Haas writes:
> On Sun, Feb 21, 2010 at 10:17 AM, Lucas wrote:
>> I wonder if the scheduler already existed before the
>> implementation of the autovacuum, its implementation would
>> not be a function executed by the in-core scheduler?
> The real genius of autovacuum is that it works ou
On Sun, Feb 21, 2010 at 10:17 AM, Lucas wrote:
> I wonder if the scheduler already existed before the
> implementation of the autovacuum, its implementation would
> not be a function executed by the in-core scheduler?
The real genius of autovacuum is that it works out when there has been
enough
Robert Haas wrote:
On Sun, Feb 21, 2010 at 9:26 AM, Tom Lane wrote:
Robert Haas writes:
http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items currently
lists no open items,
um ... are we looking at the same page? I see 8 open items there,
not counting the links to the separate HS and SR
We've just rejected Knn-gist indexes as "not enough time for 9.0", which
is a considerable disappointment for many people.
We already have a pluggable index API, but not one that supports
recoverability.
It is a simple patch to add recoverability to the index API, if we have
the will to do so.
On Sun, Feb 21, 2010 at 12:33 PM, Tom Lane wrote:
> Ron Mayer writes:
>> Is the real need here for a convenient way to enable and/or
>> recommend packagers to install some non-core modules by default?
>
> It would certainly help us resist assorted requests to put everything
> including the kitche
On Sun, Feb 21, 2010 at 9:26 AM, Tom Lane wrote:
> Robert Haas writes:
>> http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items currently
>> lists no open items,
>
> um ... are we looking at the same page? I see 8 open items there,
> not counting the links to the separate HS and SR pages.
I
Hello
I am looking on code in pl_exec.c file.
I see one issue:
/* --
* exec_run_select Execute a select query
* --
*/
static int
exec_run_select(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr, long maxtuples, Portal
*portalP
Ron Mayer writes:
> Is the real need here for a convenient way to enable and/or
> recommend packagers to install some non-core modules by default?
It would certainly help us resist assorted requests to put everything
including the kitchen sink into core.
regards, tom lane
Robert Haas writes:
> On Feb 20, 2010, at 10:56 PM, Tom Lane wrote:
>> There is a very clear set of behaviors that CORL ought to have given
>> the precedents of our other COR commands. If we don't make it do
>> things that way then we are going to surprise users, and we are also
>> going to pain
Lucas wrote:
> I believe that "in core" may be "installed by default" in case of
Those seem like totally orthogonal concepts to me.
A feature may be "in core" but not "installed by default" (like many PLs).
A feature might not be "in core" but "installed" by many installers (say
postgis).
I
2010/2/20 Andrew Dunstan
>
> We're not going to change that because some companies have
> insane corporate policies.
I agree, Andrew...
This is an outside benefit...
not a reason or justification...
I believe that a general purpose scheduler is similar to
the autovacuum... it is not really nee
Tom Lane wrote:
> Robert Haas writes:
> > http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items currently
> > lists no open items,
>
> um ... are we looking at the same page? I see 8 open items there,
> not counting the links to the separate HS and SR pages.
>
> > My suspicion is that the r
Pavel Stehule wrote:
> 2010/2/21 Andrew Dunstan :
> >> ? ?I believe that "in core" may be "installed by default" in case of
> >> ? ?the pgAgent or similar solution...
> >>
> >> ? ?Many big companies does not allow the developers to configure and
> >> ? ?install components we need to request eve
Robert Haas writes:
> http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items currently
> lists no open items,
um ... are we looking at the same page? I see 8 open items there,
not counting the links to the separate HS and SR pages.
> My suspicion is that the real situation is more complicate
Pavel Stehule writes:
> * Last two months I spent some time with preparing workshops about SQL
> injection. PostgreSQL has only one issue related to this topic. It
> allows multi queries. With this feature any successful injection can
> have much more destructive impact. Now we have a GUC per user
Pavel Stehule wrote:
This reasoning just doesn't fly in the PostgreSQL world. PostgreSQL is
designed to be extensible, not a monolithic product. We're not going to
change that because some companies have insane corporate policies. The
answer, as Jefferson said in another context, is to "inform
On Sun, Feb 21, 2010 at 3:25 AM, Robert Haas wrote:
> What kinds of things would be
> sensible to hand off in this way? Well, you'd want to find nodes that
> are not likely to be repeatedly re-executed with different parameters,
> like subplans or inner-indexscans, because otherwise you'll get
>
On Wed, Feb 17, 2010 at 5:52 PM, Jeroen Vermeulen wrote:
> I may have cut this out of my original email for brevity... my impression is
> that the planner's estimate is likely to err on the side of scalability, not
> best-case response time; and that this is more likely to happen than an
> optimis
Now that PostgreSQL 9.0 alpha4 is bundled (though apparently not quite
out the door yet), it seems like a good time to think about what we'll
need to do to get to beta. Any thoughts?
http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items currently
lists no open items, and the Hot Standby TODO
Hello,
* Now I am working on migration of plpgpsm to plpgsql 9.0 base. I hope
so I understand SQL/PSM well so I am able to write production quality
implementation. If you like, I can integrate it to core. It can share
about 40-50% code with plpgpsm. The behave of plpgpsm is same as
plpgsql - witho
Robert Haas writes:
> Probably. For one thing, you can't use fork(), because it won't work
> on Windows.
[...]
> query. IOW, we're going to need, well, a connection pool in core.
> *ducks, runs for cover*
Well, in fact, you're slowly getting to the interesting^W crazy part of
it.
Now that you
Greg Stark wrote:
So in principle I agree with this idea. I think a conservative value
for the constant would be more like 100x though. If I told you we had
an easy way to speed all your queries up by 10% by caching queries but
were just choosing not to then I think you would be unhappy. Whereas
Jeff Davis wrote:
libpq has a PQclientEncoding() function that takes a connection object.
However, the client encoding is, in some cases, a property of the result
object. For instance, if your client_encoding changes, but you keep the
result object around, you have no way to determine later wha
Greg Stark writes:
> It'll always be another (set of) processes even if it's "in core". All
> it means to be "in core" is that it will be harder to make
> modifications and you'll be tied to the Postgres release cycle.
Another set of processes all right, but that postmaster is responsible
of, tha
"Joshua D. Drake" writes:
> On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
>> Dimitri Fontaine writes:
>> > What would it take to have it included in core,
>>
>> I don't think this really makes sense. There's basically no argument
>> for having it in core other than "I'm too lazy to install
44 matches
Mail list logo
