On Mon, 2009-10-26 at 10:12 -0700, Greg Stark wrote:
> While i agree this looks nicer I wonder what it does to things like
> excel/gnumeric/ooffice auto-recognizing table layouts and importing
> files. I'm not sure our old format was so great for this so maybe this
> is actually an improvement I'm
It sounds like there's a consensus brewing here on what should get done
with this particular patch now. Let me try to summarize:
-The new feature should be activated by allowing you to specify a
directory to include in the postgresql.conf like this:
includedir 'conf'
With the same basic s
Kiswono Prayogo wrote:
plv8js is a procedural language add-on for PostgreSQL, which means you
can define Javascript functions that run inside a PostgreSQL server
using google V8 Engine.
anyone who want to contribute in plv8js please visit this group ^^
http://code.google.com/p/plv8js/
i'm stil
plv8js is a procedural language add-on for PostgreSQL, which means you
can define Javascript functions that run inside a PostgreSQL server
using google V8 Engine.
anyone who want to contribute in plv8js please visit this group ^^
http://code.google.com/p/plv8js/
i'm still new in postgresql and v8,
Greg Smith writes:
> On Mon, 26 Oct 2009, Greg Stark wrote:
>> When scanning postgresql.conf.d we should follow the Apache/Debian
>> standard of scanning only files which match a single simple hard-coded
>> template.
> If the default glob pattern is *.conf, won't all those already be screened
On Mon, Oct 26, 2009 at 6:55 PM, Greg Smith wrote:
> If the default glob pattern is *.conf, won't all those already be screened
> out? I can see your point that letting it be adustable will inevitably
> result in some fool one day writing a bad matching pattern that does grab
> backup/lock files.
Andres Freund writes:
> On Tuesday 27 October 2009 00:42:39 Tom Lane wrote:
>> I think a design that is limited to a prespecified set of GUCs is
>> broken by definition. It'd be better to make it work like
>> ALTER DATABASE SET.
> How should that work if there are conflicting settings in two tab
On Mon, 26 Oct 2009, Greg Stark wrote:
When scanning postgresql.conf.d we should follow the Apache/Debian
standard of scanning only files which match a single simple hard-coded
template. I think the convention is basically the regexp
^[0-9a-zA-Z-]*.conf$. It's important that it exclude typical
Dear Greg Stark,
Totally, right. I want to record the all updated region.
So, doing some work is not doing a little work.
But, I am trying to not touch the existing codes as much as I can.
Therefore, I mostly added my code, I didn't changed markDirtyBuffer function at
all, but, of course, I have
On Oct 26, 2009, at 5:24 PM, Itagaki Takahiro wrote:
Hmmm, hashtext() returns int32. ,
Can you reduce the collision issue if we had hashtext64()?
That would certainly reduce the chance of a collison considerably,
assuming the right algorithm.
--
-- Christophe Pettus
x...@thebuild.com
On Mon, 26 Oct 2009, Kevin Grittner wrote:
We do find the include capabilities useful. For example, for our 72
production servers for county Circuit Court systems, we copy an
identical postgresql.conf file to each county, with the last line
being an include to an overrides conf file in /etc/.
Hi,
In the gram.y, under a_expr rule
under the subrule "a_expr NOT SIMILAR TO a_expr%prec SIMILAR"
the action is as follows
{
FuncCall *n = makeNode(FuncCall);
n->funcname = SystemFuncName("similar_escape");
n->args
Josh Berkus wrote:
> > Why aren't you satisfied with hashtext('foo') ?
>
> Collisions, mostly.
Hmmm, hashtext() returns int32. ,
Can you reduce the collision issue if we had hashtext64()?
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list
Jeff Davis wrote:
> http://www.postgresql.org/docs/8.4/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS
> Looking at that page briefly I would assume that it could be set.
Oops, I forgot to fix the description when I disable toast.fillfactor.
Please just remove it from documentati
Tom Lane escribió:
> Greg Stark writes:
> > Still far from convinced on that one. But effective_io_concurrency
> > should be included even in the first pass.
>
> I think a design that is limited to a prespecified set of GUCs is
> broken by definition. It'd be better to make it work like
> ALTER
Hi,
On Tuesday 27 October 2009 00:42:39 Tom Lane wrote:
> Greg Stark writes:
> > Still far from convinced on that one. But effective_io_concurrency
> > should be included even in the first pass.
> I think a design that is limited to a prespecified set of GUCs is
> broken by definition. It'd be b
Greg Stark writes:
> Still far from convinced on that one. But effective_io_concurrency
> should be included even in the first pass.
I think a design that is limited to a prespecified set of GUCs is
broken by definition. It'd be better to make it work like
ALTER DATABASE SET.
On Mon, Oct 26, 2009 at 3:30 PM, Josh Berkus wrote:
> Greg,
>
>> This actually seems like a bad idea to me.
>
> You write your tool your way, I'll write my tool mine. We'll see which
> one works the best in the field.
Yeah actually I meant to but YMMV on that comment and forgot.
>
>> Well you'r
On Mon, Oct 26, 2009 at 3:05 PM, Josh Berkus wrote:
> I'm thinking an array, in case we want to make other tablespace cost
> parameters in the future.* Or, better, whatever structure we're
> currently using for ROLEs.
>
> (* for example, if someone does manage a filesystem with a separate
> cache
On Mon, Oct 26, 2009 at 07:19:24PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> > On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
> >> Yeah. We can do what we like with the UTF8 format but I'm considerably
> >> more worried about the aspect of making random changes to the
> >> plain-A
Pavel Stehule wrote:
2009/10/26 David E. Wheeler :
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an expression. Thus argume
Roger Leigh writes:
> On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
>> Yeah. We can do what we like with the UTF8 format but I'm considerably
>> more worried about the aspect of making random changes to the
>> plain-ASCII output.
> I checked (using strace)
> gnumeric (via libgda and
On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
> Greg Stark writes:
> > While i agree this looks nicer I wonder what it does to things like
> > excel/gnumeric/ooffice auto-recognizing table layouts and importing
> > files. I'm not sure our old format was so great for this so maybe this
2009/10/26 David E. Wheeler :
> On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
>
>> it should be light relation. 'DO' should be parametrised, and psql can
>> use own variables as 'DO' parameters.
>
> I see, because `DO` is a statement, not an expression. Thus arguments don't
> really make much s
Boszormenyi Zoltan writes:
> INSERT INTO product.t_product_inv
> SELECT word, array_accum_1(price, id) FROM product.t_product_inv0
> GROUP BY word ORDER BY word, price NULLS FIRST, id;
> However, I get an error:
> ERROR: column "t_product_inv0.price" must appear in the GROUP BY clause
> or be u
Greg,
> This actually seems like a bad idea to me.
You write your tool your way, I'll write my tool mine. We'll see which
one works the best in the field.
> Well you're assuming there's only one tool generating this config? We
> have at least two and possibly more. initdb generates an initial
On Mon, 2009-10-26 at 19:11 -0300, Alvaro Herrera wrote:
> We explicitely disallow setting fillfactor on toast tables.
So should that be made more clear in the documentation?
http://www.postgresql.org/docs/8.4/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS
Looking at that page br
Boszormenyi Zoltan wrote:
> Hi,
>
> I tried to utilize the advertised feature of 8.4, the
> separate fillfactor setting for the toast table.
>
> o=# create table t2 (id serial primary key, t text) with (fillfactor=75,
> toast.fillfactor=60);
> NOTICE: CREATE TABLE will create implicit sequence "
Robert,
> As to (1), my thought is to add two new float8 columns to
> pg_tablespace. The naming is a little awkward, because
> random_page_cost and seq_page_cost would not fit with our (rather odd)
> convention for naming system catalog columns. I'm tempted to call
> them spcrandompagecost and s
David E. Wheeler wrote:
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an expression. Thus arguments
don't really make much sense (I wish
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an expression. Thus arguments
don't really make much sense (I wish it was an expression!).
Hi,
I tried to utilize the advertised feature of 8.4, the
separate fillfactor setting for the toast table.
o=# create table t2 (id serial primary key, t text) with (fillfactor=75,
toast.fillfactor=60);
NOTICE: CREATE TABLE will create implicit sequence "t2_id_seq" for
serial column "t2.id"
ERROR
On Mon, 26 Oct 2009, Greg Stark wrote:
Actually I think the include directory came from another use case
which we've also discussed. Namely modules which need some
configuration themselves. So for example when you install PostGIS it
could drop a postgis.conf in the directory which you could th
Hi,
we have come across a problem where we need an inverted index,
an array of IDs ordered by another condition. We came up
with this scheme:
-- final inverted index
CREATE TABLE product.t_product_inv (
wordtextprimary key not null,
ids bigint[]
);
-- transition table
+1
Would you make it +2?
--
dim
Le 26 oct. 2009 à 19:15, Greg Stark a écrit :
On Sat, Oct 24, 2009 at 6:55 PM, Tom Lane wrote:
I think we should have an explicit include-directory directive, and
the
reason I think so is that it makes it fairly easy for the user to
control the relati
On Mon, Oct 26, 2009 at 1:40 PM, Josh Berkus wrote:
>
> Different issue, really, which is that some people (including me) would
> like to break up PostgreSQL configuration into 7 or 8 files based on
> functional area (e.g. memory.conf, logging.conf, custom_options.conf
> ...). I do this with my A
2009/10/26 David E. Wheeler :
> On Oct 26, 2009, at 1:16 PM, Pavel Stehule wrote:
>
>> I have a idea about migration of outer (psql) variables, and custom
>> shell variables.
>>
>> some like:
>>
>> psql --allow_custom_variables --table_name=mytable
>>
>> inside psql we should to use :table_name var
On Mon, Oct 26, 2009 at 4:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not sure whether you're saying that I'm bringing this issue up in
>> the wrong thread, or whether you disagree with the basic suggestion.
>
> The former --- whether we want to trim down the commentary in
> postgresql.co
On Mon, Oct 26, 2009 at 8:07 AM, Tom Lane wrote:
> (BTW, why do we actually need an includedir mechanism for this?
> A simple include of a persistent.conf file seems like it would be
> enough.)
Actually I think the include directory came from another use case
which we've also discussed. Namely mo
On Oct 26, 2009, at 1:21 PM, Tom Lane wrote:
A lambda facility would require being able to pass arguments and
return
results, which we intentionally left out of DO to keep it simple. By
the time you add all that notation, it's far from clear that you
shouldn't just define a function.
Well s
On Oct 26, 2009, at 1:16 PM, Pavel Stehule wrote:
I have a idea about migration of outer (psql) variables, and custom
shell variables.
some like:
psql --allow_custom_variables --table_name=mytable
inside psql we should to use :table_name variable with "mytable" as
content.
then we can us
>>>"Jonah H. Harris" wrote:
> Joshua D. Drake wrote:
>
>> This reply is wholly inappropriate for a Pg list. We are here to
>> help people. If you have a consultancy, please feel free to list
>> that but any discussion of rates is just plain rude. Please use
>> better discretion in the future.
>>
On mån, 2009-10-26 at 09:08 -0700, David E. Wheeler wrote:
> On Oct 24, 2009, at 10:44 AM, Peter Eisentraut wrote:
>
> > More detail is available in the Release Notes included with each
> > alpha:
> > http://developer.postgresql.org/pgdocs/postgres/release-8.5.html
>
> That seems to just have a
On 10/26/09 9:01 AM, Robert Haas wrote:
>> (BTW, why do we actually need an includedir mechanism for this?
>> > A simple include of a persistent.conf file seems like it would be
>> > enough.)
>
> I was starting to wonder that, too.
Different issue, really, which is that some people (including me)
Robert Haas writes:
> I'm not sure whether you're saying that I'm bringing this issue up in
> the wrong thread, or whether you disagree with the basic suggestion.
The former --- whether we want to trim down the commentary in
postgresql.conf seems to me to have nothing to do with what's
being disc
> Why aren't you satisfied with hashtext('foo') ?
Collisions, mostly.
> The restriction comes from LOCKTAG struct, in which
> we can use only 3 * uint32 and 1 * uint16 for lock descriptor.
Yeah, that's a pretty hard limit. NM, we'll have to figure out some way
around it.
--Josh Berkus
--
S
Andrew Dunstan writes:
> David E. Wheeler wrote:
>> Very excited about the new `DO` command in 8.5a2. I read through the
>> patch review thread and found that, like me, Dim had expected it to
>> behave more like a lambda than a simple command.
> It was discussed and rejected, at least for now.
Hello
I have a idea about migration of outer (psql) variables, and custom
shell variables.
some like:
psql --allow_custom_variables --table_name=mytable
inside psql we should to use :table_name variable with "mytable" as content.
then we can use syntax
do (table_name varchar) $$
begin
rais
David E. Wheeler wrote:
Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to m
On Mon, Oct 26, 2009 at 12:55 PM, Joshua D. Drake wrote:
> This reply is wholly inappropriate for a Pg list. We are here to help
> people. If you have a consultancy, please feel free to list that but any
> discussion of rates is just plain rude. Please use better discretion in
> the future.
>
Per
On Mon, 2009-10-26 at 10:19 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
> > automatic comment "# overridden in persistent.conf" and put a comment
> > marker in front of the original line. That way the user is led to the
> >
On Mon, Oct 26, 2009 at 7:25 AM, Alvaro Herrera
wrote:
> I agree, except that some things are defined in postgresql.conf by
> initdb and you probably want to be able to change them by SET PERSISTENT
> anyway (e.g. lc_messages, listen_addresses, shared_buffers)
These things should go into a postgr
On Mon, Oct 26, 2009 at 7:06 AM, Alvaro Herrera
wrote:
> Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
> automatic comment "# overridden in persistent.conf" and put a comment
> marker in front of the original line. That way the user is led to the
> actual authoritative source.
On Sat, Oct 24, 2009 at 6:55 PM, Tom Lane wrote:
>
> I think we should have an explicit include-directory directive, and the
> reason I think so is that it makes it fairly easy for the user to
> control the relative precedence of the manual settings (presumed to
> still be kept in postgresql.conf)
Greg Stark writes:
> On Sun, Oct 25, 2009 at 7:34 PM, Tom Lane wrote:
>> All that we have to do to fix the first one is to put the LockRows node
>> below the Limit node instead of above it. The solution for the second
>> one is to also put LockRows underneath the Sort node, and to regard its
>>
On Sun, Oct 25, 2009 at 7:34 PM, Tom Lane wrote:
> All that we have to do to fix the first one is to put the LockRows node
> below the Limit node instead of above it. The solution for the second
> one is to also put LockRows underneath the Sort node, and to regard its
> output as unsorted so that
On Mon, Oct 26, 2009 at 9:46 AM, Simon Riggs wrote:
> On Mon, 2009-10-26 at 13:28 +, Dean Rasheed wrote:
>
>> It works for all kinds of trigger events,
>> and is intended as a complete drop-in replacement for the after
>> triggers queue.
>
>> > All of those seem false in the general case. What
Greg Stark writes:
> While i agree this looks nicer I wonder what it does to things like
> excel/gnumeric/ooffice auto-recognizing table layouts and importing
> files. I'm not sure our old format was so great for this so maybe this
> is actually an improvement I'm asking for.
Yeah. We can do wha
On Mon, Oct 26, 2009 at 10:47 AM, Tom Lane wrote:
> Robert Haas writes:
>> What am I missing here?
>
> You're still attacking the wrong straw man. Whether the file contains a
> lot of commentary by default is NOT the problem, and removing the
> commentary is NOT the solution.
Wow, not only am
2009/10/26 Jeff Davis :
> On Mon, 2009-10-26 at 13:41 +, Dean Rasheed wrote:
>> I did a quick bit of testing, and I think that there is a
>> locking/concurrency problem :-(
>
> Unfortunately I can't reproduce the problem on my machine; it always
> passes.
>
That's odd. It happens every time on
On Sun, Oct 25, 2009 at 9:37 AM, 노홍찬 wrote:
> What I am trying to do now is to examine the real dirty portion of buffer
> pages to be flushed like the following.
>
> page 1
> -
> | | dportion1 (real dirty portion 1) ranges between 20 ~ 80
> | dportion1 |
> | |
Le samedi 24 octobre 2009 01:04:19, Josh Berkus a écrit :
> Cedric,
>
> > ase is a table containing 29 GB of bytea in a database of 52 GB. Every
> > row on the 29GB table is grab only few times. And it will just renew OS
> > cache memory every time (the server have only 8GB of ram).
> > So when I
2009/10/25 Roger Leigh :
> rleigh=# \l
> List of databases
> Name │ Owner │ Encoding │ Collation │ Ctype │ Access
> privileges
> ─┼──┼──┼─┼─┼───
> merkelpb
2009/10/26 Simon Riggs :
> On Mon, 2009-10-26 at 13:28 +, Dean Rasheed wrote:
>
>> It works for all kinds of trigger events,
>> and is intended as a complete drop-in replacement for the after
>> triggers queue.
>
>> > All of those seem false in the general case. What will you do?
>>
>> At this
On Mon, 2009-10-26 at 13:41 +, Dean Rasheed wrote:
> I did a quick bit of testing, and I think that there is a
> locking/concurrency problem :-(
Unfortunately I can't reproduce the problem on my machine; it always
passes.
If you have a minute, can you try to determine if the problem can happe
On Mon, 2009-10-26 at 09:14 -0400, Jonah H. Harris wrote:
> On Thu, Oct 22, 2009 at 7:16 PM, Joshua D. Drake
> wrote:
> On Thu, 2009-10-22 at 14:28 -0200, João Eugenio Marynowski
> wrote:
> > Hi
> >
> Repair? Not likely. Get past? Maybe.
>
> I don't know ho
Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to make such
extensions po
On Mon, Oct 26, 2009 at 4:25 PM, Tom Lane wrote:
> Dave Page writes:
>> On Mon, Oct 26, 2009 at 4:15 PM, Jaime Casanova
>> wrote:
>>> to tell someone we no longer label our license as "simplified BSD" but
>>> as MIT is, in the eyes and mind of users, changing the license... even
>>> if the wordi
Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to make such
extensions po
Dave Page writes:
> On Mon, Oct 26, 2009 at 4:15 PM, Jaime Casanova
> wrote:
>> to tell someone we no longer label our license as "simplified BSD" but
>> as MIT is, in the eyes and mind of users, changing the license... even
>> if the wording doesn't change...
> So what do you suggest? Burying o
On Mon, Oct 26, 2009 at 4:15 PM, Jaime Casanova
wrote:
> On Mon, Oct 26, 2009 at 10:40 AM, Dave Page wrote:
>> On Mon, Oct 26, 2009 at 3:36 PM, Jaime Casanova
>> wrote:
>>> On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs wrote:
ISTM we should apply to OSI for approval of our licence, so
On Mon, Oct 26, 2009 at 10:40 AM, Dave Page wrote:
> On Mon, Oct 26, 2009 at 3:36 PM, Jaime Casanova
> wrote:
>> On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs wrote:
>>>
>>> ISTM we should apply to OSI for approval of our licence, so we can then
>>> refer to it as the PostgreSQL licence.
>>>
>>
>
On Sun, Oct 25, 2009 at 9:05 AM, Robert Haas wrote:
> Arguably, you would expect parameters set using this syntax to be
> stored similar to reloptions - that is, as text[]. But as we're going
> to need these values multiple times per table to plan any non-trivial
> query, I don't want to inject u
On Oct 24, 2009, at 10:44 AM, Peter Eisentraut wrote:
More detail is available in the Release Notes included with each
alpha:
http://developer.postgresql.org/pgdocs/postgres/release-8.5.html
That seems to just have alpha1 at the moment.
Best,
David
--
Sent via pgsql-hackers mailing list (
I wrote:
> Robert Haas writes:
>> Could the desired behavior be obtained using a CTE?
> Nope, we push FOR UPDATE into WITHs too. I don't really see any way to
> deal with this without some sort of semantic changes.
... although on reflection, I'm not sure *why* we push FOR UPDATE into
WITHs. T
On Mon, Oct 26, 2009 at 11:07 AM, Tom Lane wrote:
> Greg Smith writes:
>> People who want to continue managing just the giant postgresql.conf are
>> free to collapse the initdb.conf back into the larger file instead. If we
>> wanted to make that transition easier, an option to initdb saying "do
Robert Haas writes:
> On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane wrote:
>> One problem with this is that there isn't any good way for someone to
>> get back the old behavior if they want to. Which might be a perfectly
>> reasonable thing, eg if they know that no concurrent update is supposed
>>
On sön, 2009-10-25 at 23:48 +, Roger Leigh wrote:
> Just for reference, this is what the output looks like (abridged)
> using the attached patch. Should display fine if your mail client handles
> UTF-8 messages correctly:
>
> rleigh=# \l
> List of database
On Mon, 26 Oct 2009, Tom Lane wrote:
When and if there is some evidence of people actually getting confused,
we could consider trying to auto-comment-out duplicate settings. But
I've never heard of any other tool doing that, and fail to see why we
should think Postgres needs to.
It's what p
On Mon, 26 Oct 2009, Tom Lane wrote:
BTW, why do we actually need an includedir mechanism for this?
A simple include of a persistent.conf file seems like it would be
enough.
Sure, you could do it that way. This patch is more about elegance rather
than being strictly required. The general co
On Mon, Oct 26, 2009 at 3:36 PM, Jaime Casanova
wrote:
> On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs wrote:
>>
>> ISTM we should apply to OSI for approval of our licence, so we can then
>> refer to it as the PostgreSQL licence.
>>
>
> IMHO and not being a lawyer, this is the only reason for anyo
On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs wrote:
>
> ISTM we should apply to OSI for approval of our licence, so we can then
> refer to it as the PostgreSQL licence.
>
IMHO and not being a lawyer, this is the only reason for anyone to
think in change our license i think...
even in the case bot
Greg Smith writes:
> I think the whole idea of making tools find duplicates and comment them
> out as part of making their changes is fundamentally broken, and it's just
> going to get worse when switching to use more config files.
Quite. There seems to me to be a whole lot of solving of hypot
On Mon, 26 Oct 2009, Alvaro Herrera wrote:
But to me this also says that SET PERSISTENT has to go over
00initdb.conf and add a comment mark to the setting.
Now you're back to being screwed if the server won't start because of your
change, because you've lost the original working setting.
I
On Mon, 26 Oct 2009, Alvaro Herrera wrote:
some things are defined in postgresql.conf by initdb and you probably
want to be able to change them by SET PERSISTENT anyway (e.g.
lc_messages, listen_addresses, shared_buffers)
An obvious next step once the directory parsing is committed is to chan
Greg Smith writes:
> People who want to continue managing just the giant postgresql.conf are
> free to collapse the initdb.conf back into the larger file instead. If we
> wanted to make that transition easier, an option to initdb saying "do
> things the old way" might make sense. I think the
Robert Haas wrote:
> I realize that the current file format is an old and familiar
> friend; it is for me, too. But I think it's standing in the way of
> progress. Being able to type a SQL command to update postgresql.conf
> would be more substantially convenient than logging in as root,
> usin
> "Heikki" == Heikki Linnakangas
> writes:
Heikki> Oops, you're right. The check is indeed confusing julian day
Heikki> numbers, with epoch at 23th of Nov 4714 BC, with
Heikki> postgres-reckoning day numbers, with epoch at 1th of Jan
Heikki> 2000. Thanks, will fix.
Which reminds me:
Alvaro Herrera writes:
> (But to me this also says that SET PERSISTENT has to go over
> 00initdb.conf and add a comment mark to the setting.)
Why? As you yourself pointed out, pg_settings will show exactly where
the active value came from. Moreover, should we then conclude that any
edit to any
Tom Lane escribió:
> Alvaro Herrera writes:
> > Tom Lane escribi�:
> >> Personally I think this is just a matter of usage. If you want to use
> >> SET PERSISTENT, don't set values manually in postgresql.conf.
>
> > I agree, except that some things are defined in postgresql.conf by
> > initdb and
Robert Haas writes:
> What am I missing here?
You're still attacking the wrong straw man. Whether the file contains a
lot of commentary by default is NOT the problem, and removing the
commentary is NOT the solution.
regards, tom lane
--
Sent via pgsql-hackers mailing
Alvaro Herrera writes:
> Tom Lane escribió:
>> Personally I think this is just a matter of usage. If you want to use
>> SET PERSISTENT, don't set values manually in postgresql.conf.
> I agree, except that some things are defined in postgresql.conf by
> initdb and you probably want to be able to
On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane escribió:
>>> Yeah, it could definitely run slower than the existing code --- in
>>> particular the combination of all three (FOR UPDATE ORDER BY LIMIT)
>>> would tend to become a seqscan-and-sort rather than p
On Mon, Oct 26, 2009 at 9:51 AM, Peter Eisentraut wrote:
> On Mon, 2009-10-26 at 09:04 -0400, Robert Haas wrote:
>> On Mon, Oct 26, 2009 at 12:46 AM, Josh Berkus wrote:
>> > On 10/25/09 5:33 PM, Robert Haas wrote:
>> >> Greg believes that it
>> >> isn't politically feasible to change the default
Alvaro Herrera wrote:
> Christophe Pettus wrote:
>
>> API Changes:
>>
>> Overloading the various advisory lock functions to take a suitable
>> string type (varchar(64)?) in addition to the bigint / 2 x int
>> variations. As with the bigint / 2 x int forms, this string
>> namespace would be disjoi
Tom Lane escribió:
> Alvaro Herrera writes:
> > Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
> > automatic comment "# overridden in persistent.conf" and put a comment
> > marker in front of the original line. That way the user is led to the
> > actual authoritative source.
>
Alvaro Herrera writes:
> Tom Lane escribió:
>> Yeah, it could definitely run slower than the existing code --- in
>> particular the combination of all three (FOR UPDATE ORDER BY LIMIT)
>> would tend to become a seqscan-and-sort rather than possibly just
>> reading one end of an index. However, I
Alvaro Herrera writes:
> Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
> automatic comment "# overridden in persistent.conf" and put a comment
> marker in front of the original line. That way the user is led to the
> actual authoritative source.
Doesn't that require the same A
Christophe Pettus writes:
> I'd like to propose a potential patch, and wanted to get preliminary
> feedback on it before I started looking into the design.
> Summary:Add a string key space to the advisory lock functionality.
Your chances of making the LOCKTAG struct bigger for this are non
Robert Haas escribió:
> On Mon, Oct 26, 2009 at 12:18 AM, Greg Smith wrote:
> > It actually makes it completely trivial to implement. SET PERSISTENT can
> > now write all the changes out to a new file in the include directory. Just
> > ship the database with a persistent.conf in there that looks
1 - 100 of 118 matches
Mail list logo
