Can't really blame Windows on that. On Windows, we don't require that the
encoding and LC_CTYPE's charset match. The OP used UTF-8 encoding in the
server, but LC_CTYPE=English_United Kingdom.1252, ie. LC_CTYPE implies
WIN1252 encoding. We allow that and it generally works on Windows
because
On 6/3/13 8:19 PM, Peter Geoghegan wrote:
On Mon, May 13, 2013 at 3:22 PM, Peter Geoghegan p...@heroku.com 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.
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 the new
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 p...@heroku.com wrote:
Attached patch renders all loaded library... messages DEBUG1,
regardless of whether local_preload_libraries or
On Tue, Jun 4, 2013 at 12:57 AM, Ben Zeev, Lior lior.ben-z...@hp.com 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
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
On 4 June 2013 01:54, Noah Misch n...@leadboat.com 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
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 msal...@redhat.com
Date: Tue, 4 Jun 2013
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
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:
\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
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
On Tue, Jun 4, 2013 at 5:46 AM, Andres Freund and...@2ndquadrant.com 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
On 4 June 2013 16:54, Peter Eisentraut pete...@gmx.net 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
On Tue, Jun 4, 2013 at 11:48 AM, Pavel Raiskup prais...@redhat.com 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]
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 bit of
Oliver Charles ol...@ocharles.org.uk 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 4, 2013 at 11:48 AM, Pavel Raiskup prais...@redhat.com 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
On Tue, 2013-06-04 at 13:40 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 4, 2013 at 11:48 AM, Pavel Raiskup prais...@redhat.com wrote:
Oh, I see now it was already consulted here:
http://www.postgresql.org/message-id/1368448758.23422.12.ca...@t520.redhat.com
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
problem
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
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 get
Mark Salter msal...@redhat.com 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
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
Josh Berkus j...@agliodbs.com 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
On 2013-06-04 13:25:10 -0400, Tom Lane wrote:
Oliver Charles ol...@ocharles.org.uk 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
I wrote:
Mark Salter msal...@redhat.com 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.
Andres Freund and...@2ndquadrant.com 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
Sean Chittenden s...@chittenden.org 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
- On Sat, Jun 1, 2013 at 3:57 PM, Andres Freund and...@2ndquadrant.comwrote:
-
- 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
On 2013-06-04 16:07:23 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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 what you get
Andres Freund and...@2ndquadrant.com 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
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
On 2013-06-04 16:24:07 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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 benefits
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
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
Sean Chittenden s...@chittenden.org 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 Wed, Jun 5, 2013 at 12:59 AM, Peter Eisentraut pete...@gmx.net 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
- Original Message -
From: Peter Eisentraut pete...@gmx.net
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
On 5 June 2013 05:58, Andres Freund and...@2ndquadrant.com 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
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 *didn't*
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 the
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-line PG
45 matches
Mail list logo
