On 06/04/2013 10:16:20 PM, Peter Eisentraut wrote:
> On Tue, 2013-05-07 at 23:18 -0400, Alvaro Herrera wrote:
> > Peter Eisentraut wrote:
> > > On Tue, 2013-05-07 at 00:32 -0500, Karl O. Pinc wrote:
> > > > Attached is a documentation patch against head which makes
> > > > static the targets of the
On Tue, 2013-05-07 at 23:18 -0400, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
> > On Tue, 2013-05-07 at 00:32 -0500, Karl O. Pinc wrote:
> > > Attached is a documentation patch against head which makes
> > > static the targets of the on-line PG html documentation that
> > > are referenced by t
On Tue, Jun 4, 2013 at 01:55:27PM -0700, Josh Berkus wrote:
> On 05/28/2013 11:32 AM, Bruce Momjian wrote:
> > I think Simon has a good point, as VMWare has asserted patents on some
> > changes to their version of Postgres in the past, so if the copyright
>
> ... which I'll point out that they *d
On 5 June 2013 05:58, Andres Freund wrote:
> Yea, I know of Dimitri's work ;). But I really would like this to work
> for C extensions as well. For me personally its no problem at all that
> this wouldn't work on conservatively configured machines. Heck, I
> *don't* want it to work on production
- Original Message -
> From: Peter Eisentraut
> I have never actually used symbolic-ref, but after playing with it a
> little bit, it seems it should work fine for this purpose.
>
> Comments?
+1
its should work fine, because any how we just going to add symbolic-ref which
contain
On Wed, Jun 5, 2013 at 12:59 AM, Peter Eisentraut wrote:
> I was looking for a way in which the average psql user could learn
> whether a view is updatable. I was expecting something in \d, \d+, \dv,
> \dv+, or a NOTICE from CREATE VIEW. So far, the only way appears to be
> through the informat
Sean Chittenden writes:
>> Seems like we ought to use the same message (and SQLSTATE) as in
>> namespace.c, since nobody's complained about that one.
> Sounds good to me and is clear enough that it would unblock me w/o having to
> resort to the source tree. -sc
OK, done that way.
On 06/04/2013 01:55 PM, Josh Berkus wrote:
That seems rather like a catch-22 Bruce. If they don't check with the
legal department, it's dangerous, but if they do check, it's dangerous?
Presumably if they checked with the legal department, it's cleared. We
should be wary of stuff contributed
On 6/4/13 12:08 PM, Thom Brown wrote:
> It doesn't sound useful whether it's 0 or NULL in that output. Why
> have the column in the first place when it can't have a value? Is it
> somehow required for inclusion in the output of \d+ ?
\dv is just a special case of \dvti...
--
Sent via pgsql-ha
On 05/28/2013 11:32 AM, Bruce Momjian wrote:
> I think Simon has a good point, as VMWare has asserted patents on some
> changes to their version of Postgres in the past, so if the copyright
... which I'll point out that they *didn't* contribute, and which may
yet get resolved in a way that benefit
On 2013-06-04 16:24:07 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't really care much about Oliver's usecase TBH, but I would very much
> > welcome making it easier for application developers to package part of
> > ther in-database application code as extensions without either requiri
On 06/04/2013 09:07 PM, Tom Lane wrote:
It presumably wouldn't be terribly hard for Oliver to patch the sources
to look in something other than SHAREDIR/extension/, but I'm not sure
I see the point of inventing a platform-specific name for that
directory; seems like it would mostly just confuse u
Andres Freund writes:
> I don't really care much about Oliver's usecase TBH, but I would very much
> welcome making it easier for application developers to package part of
> ther in-database application code as extensions without either requiring
> a selfcompiled postgres with a custom extension d
>>> "ERROR: XX000: no schemas in search_path are available for CREATE
>>> EXTENSION"
>
> Hm, I'm not sure that's much better than the existing wording. The
> bigger point here though is that if we consider this to be a user-facing
> error case, it ought to be ereport not elog.
>
> I checked wh
On 2013-06-04 16:07:23 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The only argument with a good bit of merit I can see is that it could
> > lead to unexpected extensions being loaded if e.g. hstore isn't
> > installed in the normal extension directory but another extension with
> > the sam
- On Sat, Jun 1, 2013 at 3:57 PM, Andres Freund wrote:
-
- > On 2013-06-01 13:04:55 +0200, Martijn van Oosterhout wrote:
- > To get the actual relfilenode you actually need to do something like:
- > SELECT relname, pg_relation_filenode(pg_class.oid) FROM pg_class;
-
- Dear Andres
-
- You are rig
Sean Chittenden writes:
> I ran in to the following situation:
>> SET search_path = ENOENT, also_does_not_exist;
>> CREATE EXTENSION pg_repack;
>> ERROR: XX000: there is no default creation target
>> LOCATION: CreateExtension, extension.c:1395
> Which left me checking out the source code to fig
Andres Freund writes:
> The only argument with a good bit of merit I can see is that it could
> lead to unexpected extensions being loaded if e.g. hstore isn't
> installed in the normal extension directory but another extension with
> the same name somewhere else.
And just think about the fun you
I wrote:
> Mark Salter writes:
>> On Tue, 2013-06-04 at 13:40 -0400, Tom Lane wrote:
>>> We got no response to the question of whether it couldn't be merged with
>>> the existing ARM32 code block. I'd prefer not to have essentially
>>> duplicate sections in s_lock.h if it's not necessary.
>> Of
On 2013-06-04 13:25:10 -0400, Tom Lane wrote:
> Oliver Charles writes:
> > I am working with the NixOS Linux Distribution [nixos], which has a
> > fairly radical approach to package management. If you aren't familiar
> > with it, essentially all packages are installed in isolation - such that
>
Josh Berkus writes:
> On 06/04/2013 10:25 AM, Tom Lane wrote:
>> Basically, none of those are likely to get accepted because of security
>> concerns. We *don't* want this path to be run-time adjustable.
> Really? I don't see a security concern in having a postgresql.conf
> option which requires
I'd like to propose a feature that allows extensions to replace a part
of plan-tree underlying PlannedStmt
by self-defined exec node being associated with several callback
functions implemented at extension
module.
Right now, about 30 built-in exec nodes are implemented, and all the
query execution
Mark Salter writes:
> On Tue, 2013-06-04 at 13:40 -0400, Tom Lane wrote:
>> We got no response to the question of whether it couldn't be merged with
>> the existing ARM32 code block. I'd prefer not to have essentially
>> duplicate sections in s_lock.h if it's not necessary.
> Of course it could
On 06/04/2013 10:25 AM, Tom Lane wrote:
>> > What wolud work best for us is to allow this path to be configurable,
>> > ideally through either an environment variable, command line switch, or
>> > (and this is the least desirable) a postgresql.conf option.
> Basically, none of those are likely to
On 06/04/2013 06:25 PM, Tom Lane wrote:
What wolud work best for us is to allow this path to be configurable,
ideally through either an environment variable, command line switch, or
(and this is the least desirable) a postgresql.conf option.
Basically, none of those are likely to get accepted be
I ran in to the following situation:
> SET search_path = ENOENT, also_does_not_exist;
> CREATE EXTENSION pg_repack;
> ERROR: XX000: there is no default creation target
> LOCATION: CreateExtension, extension.c:1395
Which left me checking out the source code to figure out exactly what the
proble
On Tue, 2013-06-04 at 13:40 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jun 4, 2013 at 11:48 AM, Pavel Raiskup wrote:
> >> Oh, I see now it was already consulted here:
> >> http://www.postgresql.org/message-id/1368448758.23422.12.ca...@t520.redhat.com
>
> > I think we should go ahea
Robert Haas writes:
> On Tue, Jun 4, 2013 at 11:48 AM, Pavel Raiskup wrote:
>> Oh, I see now it was already consulted here:
>> http://www.postgresql.org/message-id/1368448758.23422.12.ca...@t520.redhat.com
> I think we should go ahead and commit this patch, or some variant of
> it. Having a bui
Oliver Charles writes:
> I am working with the NixOS Linux Distribution [nixos], which has a
> fairly radical approach to package management. If you aren't familiar
> with it, essentially all packages are installed in isolation - such that
> packages cannot interfere with each other.
Maybe you
Hello
> I am working with the NixOS Linux Distribution [nixos], which has a
> fairly radical approach to package management. If you aren't familiar
> with it, essentially all packages are installed in isolation - such that
> packages cannot interfere with each other.
good.
> This is causing a bi
On Tue, Jun 4, 2013 at 11:48 AM, Pavel Raiskup wrote:
> On Tuesday, June 04, 2013 05:28:09 PM Pavel Raiskup wrote:
>> Hi, I was asked [1] to add following patch downstream, could it be
>> considered upstream also? Thanks, Pavel.
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=970661
>
> Oh,
On 4 June 2013 16:54, Peter Eisentraut wrote:
> \dv+ shows the size of views as "0 bytes". This doesn't make any sense;
> I think it should show null. Maybe this is even the fault of the
> backend functions for returning a number to display in the first place.
It doesn't sound useful whether it
On Tue, Jun 4, 2013 at 5:46 AM, Andres Freund wrote:
> I don't really see a point in delaying it towards 9.4.
Me neither, obviously. It's not as if someone was willing to speak in
defense of the current behavior.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
I was looking for a way in which the average psql user could learn
whether a view is updatable. I was expecting something in \d, \d+, \dv,
\dv+, or a NOTICE from CREATE VIEW. So far, the only way appears to be
through the information schema or the underlying pg_view_is_updatable
function. Not ev
\dv+ shows the size of views as "0 bytes". This doesn't make any sense;
I think it should show null. Maybe this is even the fault of the
backend functions for returning a number to display in the first place.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Tuesday, June 04, 2013 05:28:09 PM Pavel Raiskup wrote:
> Hi, I was asked [1] to add following patch downstream, could it be
> considered upstream also? Thanks, Pavel.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=970661
Oh, I see now it was already consulted here:
http://www.postgr
Hello,
I am working with the NixOS Linux Distribution [nixos], which has a
fairly radical approach to package management. If you aren't familiar
with it, essentially all packages are installed in isolation - such that
packages cannot interfere with each other.
This is causing a bit of a prob
Hi, I was asked [1] to add following patch downstream, could it be
considered upstream also? Thanks, Pavel.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=970661
>From ed791f40aa117d4fc273e4b96d9295ee9571fc96 Mon Sep 17 00:00:00 2001
From: Mark Salter
Date: Tue, 4 Jun 2013 17:23:01 +0200
Subje
On 4 June 2013 01:54, Noah Misch wrote:
> On Sun, Jun 02, 2013 at 10:45:21AM +0100, Simon Riggs wrote:
>> For clarity the 4 problems are
>> 1. SQL execution overhead
>> 2. Memory usage
>> 3. Memory scrolling
>> 4. Locking overhead, specifically FPWs and WAL records from FK checks
>> probably in th
No it isn't a typo,
All the tables are empty and all the indexes are empty
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Tuesday, June 04, 2013 16:10
To: Ben Zeev, Lior
Cc: Atri Sharma; Stephen Frost; Pg Hackers
Subject: Re: [HACKERS] PostgreSQL Process memory
On Tue, Jun 4, 2013 at 12:57 AM, Ben Zeev, Lior wrote:
> No matter how I try to redesign the schema the indexes consume large amount
> of memory,
> About 8KB per index.
8KB per index -- is that a typo? that doesn't seem like a lot to me.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-
On 2013-06-04 08:39:18 -0400, Peter Eisentraut wrote:
> On 6/3/13 8:19 PM, Peter Geoghegan wrote:
> > On Mon, May 13, 2013 at 3:22 PM, Peter Geoghegan wrote:
> >> Attached patch renders all "loaded library..." messages DEBUG1,
> >> regardless of whether local_preload_libraries or
> >> shared_prelo
On 6/3/13 9:43 PM, Andrew Dunstan wrote:
>
> On 06/03/2013 09:30 PM, Peter Eisentraut wrote:
>> I suppose we'll be branching off 9.3 in a few weeks. That event always
>> creates a service gap in the build farm and similar services, and a race
>> in the NLS service to get everything adjusted to th
On 6/3/13 8:19 PM, Peter Geoghegan wrote:
> On Mon, May 13, 2013 at 3:22 PM, Peter Geoghegan wrote:
>> Attached patch renders all "loaded library..." messages DEBUG1,
>> regardless of whether local_preload_libraries or
>> shared_preload_libraries is involved, and regardless of EXEC_BACKEND.
>
> C
44 matches
Mail list logo
