Hi!
Josh Berkus writes:
Now, if we had an OS which could be convinced to handle caching
differently for different physical devices, then I could see wanting
this setting to be per-tablespace. For example, it would make a lot of
sense not to FS-cache any data which is on a ramdisk or
Per discussion at the developer meeting back in Ottawa, attached is an
initial patch that implements reading a directory of configuration
files instead of just one. The idea being that something like a tuning
tool, or pgadmin, for example can drop and modify files in this
directory instead of
On 24 Oct 2009, at 14:41, Magnus Hagander wrote:
Per discussion at the developer meeting back in Ottawa, attached is an
initial patch that implements reading a directory of configuration
files instead of just one. The idea being that something like a tuning
tool, or pgadmin, for example can
On Sat, 2009-10-24 at 15:41 +0200, Magnus Hagander wrote:
Per discussion at the developer meeting back in Ottawa, attached is an
initial patch that implements reading a directory of configuration
files instead of just one. The idea being that something like a tuning
tool, or pgadmin, for
On Aug 31, 2009, at 1:12 AM, Heikki Linnakangas wrote:
...
Is the new date_recv() constraint actually correct?
[looking at the result 0 part, at least]
src/backend/utils/adt/date.c
...
+ /* Limit to the same range that date_in() accepts. */
+ if (result 0 || result
2009/10/24 Grzegorz Jaskiewicz g...@pointblue.com.pl:
On 24 Oct 2009, at 14:41, Magnus Hagander wrote:
Per discussion at the developer meeting back in Ottawa, attached is an
initial patch that implements reading a directory of configuration
files instead of just one. The idea being that
2009/10/24 Simon Riggs si...@2ndquadrant.com:
On Sat, 2009-10-24 at 15:41 +0200, Magnus Hagander wrote:
Per discussion at the developer meeting back in Ottawa, attached is an
initial patch that implements reading a directory of configuration
files instead of just one. The idea being that
On Sat, 2009-10-24 at 18:34 +0200, Magnus Hagander wrote:
Did you look at the patch?
I did, yes. But no docs with it. It would be good to see the proposal,
not just the patch (or a reference to the written proposal from
earlier).
That's basically what it does now, except
it doesn't add a
Magnus Hagander wrote:
I'm happy with the new feature, however, so is there a way to do this?
Could we have a new directive in postgresql.conf that allows you to
specify an includedirectory? Like an include directive but for a whole
directory rather than just a file.
We could do it
2009/10/24 Simon Riggs si...@2ndquadrant.com:
On Sat, 2009-10-24 at 18:34 +0200, Magnus Hagander wrote:
Did you look at the patch?
I did, yes. But no docs with it. It would be good to see the proposal,
not just the patch (or a reference to the written proposal from
earlier).
We discussed
On Sat, 2009-10-24 at 12:52 -0400, Andrew Dunstan wrote:
What bothers me some is that it sounds like a bit of a footgun. A
postgres cluster is a shared resource, and we surely don't want
applications meddling with the shared config. This seems quite different
from, say, an application
On Sat, 2009-10-24 at 18:57 +0200, Magnus Hagander wrote:
That's basically what it does now, except
it doesn't add a parameter in postgresql.conf. If you lkeave the
pg_config directory empty, it will just parse the postgresql.conf file
just like before, and that's it. only if you put
On Fri, Oct 16, 2009 at 01:38:15PM +0300, Peter Eisentraut wrote:
I like the new Unicode tables, but the marking of continuation lines
looks pretty horrible:
List of databases
Name │ Owner │ Encoding │ Collation │ Ctype │ Access
privileges
On Sat, 24 Oct 2009, Andrew Dunstan wrote:
If we're going to do this at all, ISTM the location should be configurable,
just like other file locations are.
...
What bothers me some is that it sounds like a bit of a footgun. A postgres
cluster is a shared resource, and we surely don't want
On Sat, Oct 24, 2009 at 9:41 AM, Magnus Hagander mag...@hagander.net wrote:
Per discussion at the developer meeting back in Ottawa, attached is an
initial patch that implements reading a directory of configuration
files instead of just one. The idea being that something like a tuning
tool, or
phone answering, please forgive style...
--
dim
Le 24 oct. 2009 à 20:10, Robert Haas robertmh...@gmail.com a écrit :
$PGDATA/postgresql.conf
I think the multiple files should go in $PGDATA/postgresql.conf.d
But the only way to solve the problem of
machine-parsing the config file is to
Still on the phone...
--
dim
Le 23 oct. 2009 à 21:16, Tom Lane t...@sss.pgh.pa.us a écrit :
I'd feel more comfortable with being able to add some flags to an
opclass (or more likely an opfamily) that assert that its strategy
numbers agree with some convention or other.
The overlap
James == James Pye li...@jwp.name writes:
James Is the new date_recv() constraint actually correct?
No, it's not:
regression=# create table x (a date);
CREATE TABLE
regression=# insert into x values ('1999-01-01');
INSERT 0 1
regression=# copy x to '/tmp/tst.dmp' binary;
COPY 1
regression=#
On Oct 24, 2009, at 4:01 PM, Dimitri Fontaine dfonta...@hi-media.com
wrote:
Le 24 oct. 2009 à 20:10, Robert Haas robertmh...@gmail.com a écrit
:
$PGDATA/postgresql.conf
I think the multiple files should go in $PGDATA/postgresql.conf.d
But the only way to solve the problem of
On ons, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote:
So, we should always ignore BOM sequence
at the file head no matter what client encoding is used.
I think we can't do that. That byte sequence might be valid user data
in other encodings.
--
Sent via pgsql-hackers mailing list
2009/10/23 João Eugenio Marynowski joa...@gmail.com
I thought this would solve my problems but not yet ...
the block that I found is not presenting error...
find_bad_block
(514708,16)
(1 registro)
blockId / blocks_per_chunk = 514708 / 131072 = 3,9269104
The attached WIP patch revises EvalPlanQual processing along the lines
I've been muttering about for the last little while. It's a fairly
large patch, but it should be a lot more efficient than the existing
code as well as delivering much saner behavior. The key points are:
1. In order to avoid
Robert Haas robertmh...@gmail.com writes:
Supporting an include-directory seems harmless to me, and even
potentially useful. But the only way to solve the problem of
machine-parsing the config file is to remove the instructions (which
can only EVER be parsed by human beings) and put them
On Sat, 24 Oct 2009, Robert Haas wrote:
But the only way to solve the problem of machine-parsing the config file
is to remove the instructions (which can only EVER be parsed by human
beings) and put them somewhere else.
Ah, back to this again already. Your suggestion presumes there is
On Sat, Oct 24, 2009 at 7:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Supporting an include-directory seems harmless to me, and even
potentially useful. But the only way to solve the problem of
machine-parsing the config file is to remove the
Robert Haas robertmh...@gmail.com writes:
I don't believe that the *ability* to have comments is the problem.
It wouldn't hurt anything to ship a file with a general comment block
at the top, with whatever content someone wants to put there. What
makes it impossible to machine-edit this file
Magnus Hagander mag...@hagander.net writes:
2009/10/24 Simon Riggs si...@2ndquadrant.com:
Could we have a new directive in postgresql.conf that allows you to
specify an includedirectory? Like an include directive but for a whole
directory rather than just a file.
We could do it that way, but
On Sat, Oct 24, 2009 at 9:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I don't believe that the *ability* to have comments is the problem.
It wouldn't hurt anything to ship a file with a general comment block
at the top, with whatever content someone
28 matches
Mail list logo
