Hi all,
Sorry for jumping in over 4 months later...
On Sat, Feb 20, 2010 at 8:25 PM, Robert Haas wrote:
> On Sat, Feb 20, 2010 at 8:31 AM, Dimitri Fontaine
> wrote:
>>> This is really a topic for another thread, but at 100,000 feet it
>>> seems to me that the hardest question is - how will you
On fre, 2010-06-25 at 23:44 +0200, Andres Freund wrote:
> Has anybody actually researched if it is safe to run python2 and
> python3 in the same address space?
You can't run plpython2 and plpython3 in the same session, because the
libraries are loaded with dlopen(RTLD_GLOBAL) (with RTLD_LOCAL it w
On Wednesday 23 June 2010 16:30:54 Tom Lane wrote:
> Robert Haas writes:
> > I can reproduce this, here. The problem seems to be that plpython
> > only build either plpython2.so or plython3.so, but both languages
> > expect a call handler called plython_call_handler. So once we load
> > the shar
On http://github.com/pbaros/postgres can be seen changes and my attempt
to implement materialized views. The first commit to the repository
implements following:
Materialized view can be created, dropped and used in SELECT statement.
CREATE MATERIALIZED VIEW mvname AS SELECT ...;
DROP MATERIAL
Robert Haas wrote:
> Kevin Grittner wrote:
>> Heck, I think an even *more* trivial admission control policy
>> which limits the number of active database transactions released
>> to execution might solve a lot of problems.
>
> That wouldn't have any benefit over what you can already do with a
On Mon, Jun 14, 2010 at 10:08 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> Magnus Hagander wrote:
>>> It means that we can't prevent people from configuring their tools to
>>> ignore important warning. We can't prevent them rom ignoring ERROR or
>>> FATAL either...
>
>> My point is that most to
On Fri, Jun 25, 2010 at 3:52 PM, Kevin Grittner
wrote:
> Heck, I think an even *more* trivial admission control policy which
> limits the number of active database transactions released to
> execution might solve a lot of problems.
That wouldn't have any benefit over what you can already do with
On Fri, Jun 25, 2010 at 4:10 PM, Josh Berkus wrote:
> On 6/25/10 12:15 PM, Robert Haas wrote:
>> I think a good admission control system for memory would be huge for
>> us. There are innumerable threads on pgsql-performance where we tell
>> people to set work_mem to a tiny value (like 4MB or 16MB
Josh Berkus wrote:
> Greenplum did this several years ago with the Bizgres project
> However, it [was not] compatible with OLTP workloads.
> the "poor man's admission control" is a waste of time because it
> doesn't actually help performance. We're basically facing doing
> the hard version,
On 6/25/10 12:15 PM, Robert Haas wrote:
> I think a good admission control system for memory would be huge for
> us. There are innumerable threads on pgsql-performance where we tell
> people to set work_mem to a tiny value (like 4MB or 16MB) because any
> higher value risks driving the machine int
On mån, 2010-06-07 at 21:33 +0300, Peter Eisentraut wrote:
> I have developed a patch that partially implements the "functional
> dependency" feature that allows some columns to be omitted from the
> GROUP BY clause if it can be shown that the columns are functionally
> dependent on the columns in
Robert Haas wrote:
> Kevin Grittner wrote:
>> check out section 2.4 of this
> A really trivial admission control system might let you set a
> system-wide limit on work_mem.
Heck, I think an even *more* trivial admission control policy which
limits the number of active database transactions
On fre, 2010-06-11 at 07:00 +0300, Peter Eisentraut wrote:
> The second problem is that the prototype check for accept() fails.
> This
> is because glibc defines the second argument to be a "transparent
> union", apparently to make it look like a lot of things at once.
> clang
> apparently doesn't
On Fri, Jun 25, 2010 at 1:33 PM, Kevin Grittner
wrote:
> Recent discussions involving the possible benefits of a connection
> pool for certain users has reminded me of a brief discussion at The
> Royal Oak last month, where I said I would post a reference a
> concept which might alleviate the need
> You could argue it either way. The number of beta testers with
> plpython3 installations is probably very small, so I'm kinda leaning to
> just changing the code without a catversion bump. OTOH, if we want to
> encourage testing of pg_upgrade ...
FWIW, the last bump has led to a lot of testin
Peter Eisentraut writes:
> On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
>> The fix ought to be to change the function nmes used by plpython3 ...
> Right. What shall we do about the catversion?
You could argue it either way. The number of beta testers with
plpython3 installations is proba
On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > The problem is apparently that when CREATE LANGUAGE creates a language
> > from a pg_pltemplate entry, it creates the proname from the tmplhandler
> > name, and if it finds a fitting proname entry already, it used th
Shouldn't this be backpatched, or was this a new bug in 9.0?
We've always output bytes. I'd have noticed the discrepancy myself if
I'd read the actual docs ;-)
KB would be more useful. And I don't think people have enough scripts
built on this yet to make this break anything. We should
Recent discussions involving the possible benefits of a connection
pool for certain users has reminded me of a brief discussion at The
Royal Oak last month, where I said I would post a reference a
concept which might alleviate the need for external connection
pools. For those interested, check out
On Fri, Jun 25, 2010 at 1:02 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Robert Haas wrote:
>>> Here's an attempt at rewording the sections so that the
>>> information is included in each parameter's description without
>>> taking up a whole sentence.
>>>
>>> Thoughts?
>
>> It makes the po
"Kevin Grittner" writes:
> Robert Haas wrote:
>> Here's an attempt at rewording the sections so that the
>> information is included in each parameter's description without
>> taking up a whole sentence.
>>
>> Thoughts?
> It makes the point without beating one over the head with it. I
> partic
On Wed, Jun 23, 2010 at 4:48 AM, Sander, Ingo (NSN - DE/Munich)
wrote:
> Sql query "select pg_last_xlog_receive_location(); " does not work during
> startup of standby database.
> TestScenario;
> We have a active-standby system with PostgreSQL Streaming Replication beta2.
> If the active database
On http://github.com/pbaros/postgres can be seen changes and my attempt
to implement materialized views. The first commit to the repository
implements following:
Materialized view can be created, dropped and used in SELECT statement.
CREATE MATERIALIZED VIEW mvname AS SELECT ...;
DROP MATERIAL
Hi,
Sql query "select pg_last_xlog_receive_location(); " does not work during
startup of standby database.
TestScenario;
We have a active-standby system with PostgreSQL Streaming Replication beta2. If
the active database is up the database is in use (read/write queries will be
performed). The
On Jun 16, 2010, at 3:37 AM, Dave Page wrote:
>> heh I'm with Robert on that PGXN just sounds and speels weird - PGAN was
>> much easier ;)
>
> +1
Seriously? To me, “pee-gan” just didn't sound nice. And the acronym,
“PostgreSQL Add-on Network,” wasn't as good, since it's mainly
extension-focus
On Fri, 2010-06-25 at 17:25 +0300, Heikki Linnakangas wrote:
> On 25/06/10 16:11, Simon Riggs wrote:
> > Log Message:
> > ---
> > Fix log_temp_files docs and comments to say bytes not kilobytes.
> > stat(2) field st_size returns bytes not kilobytes.
> > Bug found during recent performance t
On 25/06/10 16:11, Simon Riggs wrote:
Log Message:
---
Fix log_temp_files docs and comments to say bytes not kilobytes.
stat(2) field st_size returns bytes not kilobytes.
Bug found during recent performance tuning for PostgreSQL user.
Modified Files:
--
pgsql/doc/src/sgm
Peter Eisentraut writes:
> The problem is apparently that when CREATE LANGUAGE creates a language
> from a pg_pltemplate entry, it creates the proname from the tmplhandler
> name, and if it finds a fitting proname entry already, it used that one.
> So when you create plpython2 first and plpython3
Robert Haas wrote:
> Here's an attempt at rewording the sections so that the
> information is included in each parameter's description without
> taking up a whole sentence.
>
> Thoughts?
It makes the point without beating one over the head with it. I
particularly like the way this patch move
On Thu, Jun 24, 2010 at 11:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 24, 2010 at 1:38 PM, Simon Riggs wrote:
>>> On Thu, 2010-06-24 at 11:15 -0400, Tom Lane wrote:
It might be a good idea to add a sentence to the documentation, though,
just pointing out that these con
30 matches
Mail list logo
