On Tue, Aug 20, 2013 at 10:02 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Stephen Frost escribió:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Well, all the relative paths in include/includedir directives would be
relative to the directory specified by the -c config_file param,
On Wed, Aug 21, 2013 at 7:29 AM, Bruce Momjian br...@momjian.us wrote:
On Tue, Aug 20, 2013 at 08:38:52AM +0530, Amit Kapila wrote:
On Tue, Aug 20, 2013 at 8:27 AM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
If both are okay, then I would like to
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Robert Haas escribió:
On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost sfr...@snowman.net wrote:
A shared catalog which defined which *database* to run the trigger in,
with a way to fire off a new backend worker in that database and tell it
* Amit Kapila (amit.kapil...@gmail.com) wrote:
I think disabling ALTER SYSTEM can be more easily supported if we
choose one of below options:
a. UI into contrib module, people who don't want doesn't include it
b. Have an include file mechanism, so that user can comment the
include in
On Tue, Aug 20, 2013 at 5:49 AM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
I think disabling ALTER SYSTEM can be more easily supported if we
choose one of below options:
a. UI into contrib module, people who don't want doesn't include it
b. Have an
* Amit Kapila (amit.kapil...@gmail.com) wrote:
If both are okay, then I would like to go with second option (include
file mechanism).
I think by default, we should allow auto file to be included and if
user faces any problem or otherwise,
then he can decide to disable it.
If it's enabled by
On Tue, Aug 20, 2013 at 8:27 AM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
If both are okay, then I would like to go with second option (include
file mechanism).
I think by default, we should allow auto file to be included and if
user faces any
* Amit Kapila (amit.kapil...@gmail.com) wrote:
initdb will create the empty auto file. If we don't enable by default,
then if user uses
ALTER SYSTEM and do sighup/restart, changed config parameter values
will not come into affect
until he manually enables it by removing '#' from '#include'.
On Tue, Aug 20, 2013 at 8:43 AM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
initdb will create the empty auto file. If we don't enable by default,
then if user uses
ALTER SYSTEM and do sighup/restart, changed config parameter values
will not come
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Do you mean to say, that when user uses ALTER SYSTEM and include is
disabled, then we can give ERROR in
ALTER SYSTEM, that to reflect the values, he need to enable it?
Actually in previous version of patch, there was WARNING on such a
On Tue, Aug 20, 2013 at 9:33 AM, Stephen Frost sfr...@snowman.net wrote:
* Amit Kapila (amit.kapil...@gmail.com) wrote:
Do you mean to say, that when user uses ALTER SYSTEM and include is
disabled, then we can give ERROR in
ALTER SYSTEM, that to reflect the values, he need to enable it?
Amit Kapila escribió:
3. postgresql.conf will contain include directive in below form:
#include = 'postgresql.auto.conf'
Whenever user wants to use Alter System, he needs to enable it
after first time using ALTER SYSTEM.
This seems wrong to me. If the auto file is read by
On Tue, Aug 20, 2013 at 10:26 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Amit Kapila escribió:
3. postgresql.conf will contain include directive in below form:
#include = 'postgresql.auto.conf'
Whenever user wants to use Alter System, he needs to enable it
after
On Fri, Aug 16, 2013 at 11:12 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas escribió:
On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost sfr...@snowman.net wrote:
A shared catalog which defined which *database* to run the trigger in,
with a way to fire off a new backend worker in
On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Sun, Aug 4, 2013 at 4:26 PM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
What I'm yet unsure about is that there's a consensus that the use cases
are worthy of a new
Robert Haas escribió:
On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost sfr...@snowman.net wrote:
A shared catalog which defined which *database* to run the trigger in,
with a way to fire off a new backend worker in that database and tell it
to run the trigger, might be interesting and would
* Robert Haas (robertmh...@gmail.com) wrote:
On Sun, Aug 4, 2013 at 4:26 PM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
What I'm yet unsure about is that there's a consensus that the use cases
are worthy of a new shared catalog in the system. Also I didn't look how
hard it is to
Stephen Frost sfr...@snowman.net writes:
A shared catalog which defined which *database* to run the trigger in,
with a way to fire off a new backend worker in that database and tell it
to run the trigger, might be interesting and would deal with the issue
that the trigger would behave
On Fri, Aug 09, 2013 at 03:08:45PM +0200, Dimitri Fontaine wrote:
Stephen Frost sfr...@snowman.net writes:
A shared catalog which defined which *database* to run the trigger
in, with a way to fire off a new backend worker in that database
and tell it to run the trigger, might be interesting
On Sun, Aug 4, 2013 at 4:26 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I remind you that event triggers are not fired for global objects
such as databases and roles. Do you intend to lift that restriction?
That's not on my TODO list for
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I remind you that event triggers are not fired for global objects
such as databases and roles. Do you intend to lift that restriction?
That's not on my TODO list for 9.4. My understanding about implementing
that is:
- we agree that it would be
On Friday, August 02, 2013 4:34 AM Dimitri Fontaine wrote:
Andres Freund and...@2ndquadrant.com writes:
They would need a setting that disables ALTER (DATABASE|USER) ... SET
... as well though. At least for some settings.
I don't think enforcing things on that level makes much sense.
On 7/29/13 3:46 PM, Josh Berkus wrote:
Based on the ongoing discussion of this patch, I have moved it to 9.4CF2
(9-2013).
Mind you, it would be good to commit some version of it before September.
Quite a bit of the patch adds some refactored GUC parameter validation
code that seems necessary
Dimitri Fontaine escribió:
Andres Freund and...@2ndquadrant.com writes:
They would need a setting that disables ALTER (DATABASE|USER) ... SET
... as well though. At least for some settings.
I don't think enforcing things on that level makes much sense.
If only we could trigger some
On Tuesday, July 30, 2013 10:25 PM Josh Berkus wrote:
Amit,
I had already sent the updated patch based on recent suggestions.
Yes, but there is no consensus yet on certain fundamental issues, such
as:
1. what directory should postgresql.auto.conf live in?
Current situation is that
On 07/26/2013 12:19 PM, Stephen Frost wrote:
Agreed. To continue that thought, I find it *very* unlikely that a
given environment would use *both* a tool like puppet to manage the
files in their conf.d *and* have people using ALTER SYSTEM SET. You're
going to do one or the other, almost
On 2013-08-01 10:13:37 -0700, Josh Berkus wrote:
On 07/26/2013 12:19 PM, Stephen Frost wrote:
Agreed. To continue that thought, I find it *very* unlikely that a
given environment would use *both* a tool like puppet to manage the
files in their conf.d *and* have people using ALTER SYSTEM
Andres Freund and...@2ndquadrant.com writes:
They would need a setting that disables ALTER (DATABASE|USER) ... SET
... as well though. At least for some settings.
I don't think enforcing things on that level makes much sense.
If only we could trigger some actions when a command is about to be
Le lundi 29 juillet 2013 18:03:21, Alvaro Herrera a écrit :
Why not harcode in ParseConfigFp() that we should parse the auto.conf
file at the end (and/or if USE_AUTO_CONF is not OFF) instead of
hacking ProcessConfigFile() with data_directory ? (data_directory should
be set at this point)
Le mardi 30 juillet 2013 05:27:12, Amit Kapila a écrit :
On Monday, July 29, 2013 7:15 PM Cédric Villemain wrote:
Le lundi 29 juillet 2013 13:47:57, Amit Kapila a écrit :
On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
Alvaro
On 7/28/13 10:49 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I think if we can design conf.d separately for config files of management
tools, then
it is better to have postgresql.auto.conf to be in $PGDATA rather than in
$PGDATA/conf.d
One of the biggest current complaints
Amit,
I had already sent the updated patch based on recent suggestions.
Yes, but there is no consensus yet on certain fundamental issues, such as:
1. what directory should postgresql.auto.conf live in?
2. should admins be able to turn it off?
Once we have consensus on these issues, then
Josh Berkus escribió:
Amit,
I had already sent the updated patch based on recent suggestions.
Yes, but there is no consensus yet on certain fundamental issues, such as:
1. what directory should postgresql.auto.conf live in?
2. should admins be able to turn it off?
Once we have
On 07/30/2013 10:10 AM, Alvaro Herrera wrote:
Once we have consensus on these issues, then hopefully we can commit
your patch. I don't *think* anyone is arguing with the code at this stage.
There's one other thing, raised by Cédric upthread, about the multiple
files vs. single file. We
On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
The main contention point I see is where conf.d lives;
the two options are in $PGDATA or together with postgresql.conf.
Tom
and Robert,
Le lundi 29 juillet 2013 13:47:57, Amit Kapila a écrit :
On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
The main contention point I see is where conf.d lives;
the two options are in
Why not harcode in ParseConfigFp() that we should parse the auto.conf file at
the end (and/or if USE_AUTO_CONF is not OFF) instead of hacking
ProcessConfigFile() with data_directory ? (data_directory should be set at
this
point) ... just thinking, a very convenient way to enable/disable
All,
Based on the ongoing discussion of this patch, I have moved it to 9.4CF2
(9-2013).
Mind you, it would be good to commit some version of it before September.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 18-07-2013 17:02, Alvaro Herrera wrote:
I think we should just put the config directives of ALTER SYSTEM into a
file, not dir, alongside postgresql.conf; I would suggest
postgresql.auto.conf. This file is parsed automatically after
postgresql.conf, without requiring an include directive in
On Monday, July 29, 2013 7:15 PM Cédric Villemain wrote:
Le lundi 29 juillet 2013 13:47:57, Amit Kapila a écrit :
On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
The main
On Tuesday, July 30, 2013 1:17 AM Josh Berkus wrote:
On Tuesday, July 30, 2013 1:17 AM Amit kapila wrote:
All,
Based on the ongoing discussion of this patch, I have moved it to
9.4CF2
(9-2013).
I had already sent the updated patch based on recent suggestions.
I am really not sure if
I think if we can design conf.d separately for config files of management
tools, then
it is better to have postgresql.auto.conf to be in $PGDATA rather than in
$PGDATA/conf.d
One of the biggest current complaints about recovery.conf from
Debian/Ubuntu users is the fact that it lives in
Josh Berkus j...@agliodbs.com writes:
I think if we can design conf.d separately for config files of management
tools, then
it is better to have postgresql.auto.conf to be in $PGDATA rather than in
$PGDATA/conf.d
One of the biggest current complaints about recovery.conf from
Debian/Ubuntu
Tom Lane t...@sss.pgh.pa.us writes:
One of the biggest current complaints about recovery.conf from
Debian/Ubuntu users is the fact that it lives in $PGDATA. Won't we just
get the same thing here?
I don't think so, see below.
I don't think that's the same case, but ... why exactly don't they
Tom Lane t...@sss.pgh.pa.us writes:
Come to think of it, maybe part of the reason we're having such a hard
time getting to consensus is that people are conflating the snippet
part with the writable part? I mean, if you are thinking you want
system-management tools to be able to drop in
On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
The main contention point I see is where conf.d lives;
the two options are in $PGDATA or together with postgresql.conf. Tom
and Robert, above, say it should be in $PGDATA; but this goes against
On Friday, July 26, 2013 10:35 AM Alvaro Herrera wrote:
Josh Berkus escribió:
On 07/25/2013 02:02 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
My thought is that people might put postgresql.conf in a directory
that only contains configuration files and isn't
Alvaro Herrera alvhe...@2ndquadrant.com writes:
The main contention point I see is where conf.d lives;
the two options are in $PGDATA or together with postgresql.conf. Tom
and Robert, above, say it should be in $PGDATA; but this goes against
Debian packaging and the Linux FHS (or whatever
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Come to think of it, maybe part of the reason we're having such a hard
time getting to consensus is that people are conflating the snippet
part with the writable part? I mean, if you are thinking you want
system-management tools to be able to drop in
On Thu, Jul 18, 2013 at 6:03 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Josh Berkus escribió:
We are missing one feature, which is the ability to relocate the
postgresql.auto.conf file if relocating it is desireable according to
some sysadmin spec. This kind of ties into another
On Mon, Jul 22, 2013 at 7:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
Christophe just discovered something with include files which is going
to cause issues with ALTER SYSTEM SET.
So, take as a hypothetical that you use the default postgresql.conf
file,
Robert Haas escribió:
On Mon, Jul 22, 2013 at 7:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be inclined to think that ALTER SYSTEM SET should not be allowed to
modify any PGC_POSTMASTER parameters.
That significantly decreases the usefulness of ALTER SYSTEM without
actually preventing
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribió:
On Mon, Jul 22, 2013 at 7:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be inclined to think that ALTER SYSTEM SET should not be allowed to
modify any PGC_POSTMASTER parameters.
That significantly decreases the usefulness
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 18, 2013 at 6:03 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Josh Berkus escribió:
We are missing one feature, which is the ability to relocate the
postgresql.auto.conf file if relocating it is desireable according to
some sysadmin
On 07/25/2013 02:02 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 18, 2013 at 6:03 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Josh Berkus escribi�:
We are missing one feature, which is the ability to relocate the
postgresql.auto.conf file if relocating it
Josh Berkus escribió:
On 07/25/2013 02:02 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
My thought is that people might put postgresql.conf in a directory
that only contains configuration files and isn't writeable by the
postgres user. So I would expect to find
Everything was already *not* hunky-dory as soon as you did that, since
a SIGHUP would have had the same problem.
I'd be inclined to think that ALTER SYSTEM SET should not be allowed to
modify any PGC_POSTMASTER parameters.
That makes alter system set a bunch less useful, but might be
On Tuesday, July 23, 2013 5:06 AM Josh Berkus wrote:
All,
Christophe just discovered something with include files which is going
to cause issues with ALTER SYSTEM SET.
So, take as a hypothetical that you use the default postgresql.conf
file, which sets shared_buffers = 32MB.
Instead of
On 7/22/13 12:58 PM, Amit kapila wrote:
As per discussion, updated patch contains following changes:
1. Regression tests for Alter System are removed
2. Parsed the auto file automatically after parsing postgresql.conf
3. Removed addition of include directive in postgresql.conf
4. Removed error
Greg Smith escribió:
On 7/22/13 12:58 PM, Amit kapila wrote:
As per discussion, updated patch contains following changes:
1. Regression tests for Alter System are removed
2. Parsed the auto file automatically after parsing postgresql.conf
3. Removed addition of include directive in
All,
Christophe just discovered something with include files which is going
to cause issues with ALTER SYSTEM SET.
So, take as a hypothetical that you use the default postgresql.conf
file, which sets shared_buffers = 32MB.
Instead of editing this file, you do ALTER SYSTEM SET shared_buffers =
Josh Berkus j...@agliodbs.com writes:
Christophe just discovered something with include files which is going
to cause issues with ALTER SYSTEM SET.
So, take as a hypothetical that you use the default postgresql.conf
file, which sets shared_buffers = 32MB.
Instead of editing this file, you
On Tuesday, July 23, 2013 5:26 AM Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Christophe just discovered something with include files which is
going
to cause issues with ALTER SYSTEM SET.
So, take as a hypothetical that you use the default postgresql.conf
file, which sets
On Thursday, July 18, 2013 12:38 AM Josh Berkus wrote:
On 07/17/2013 12:01 PM, Alvaro Herrera wrote:
Both of these seem like they would make troubleshooters' lives more
difficult. I think we should just parse the auto file automatically
after parsing postgresql.conf, without requiring the
On 07/18/2013 04:25 AM, Amit Kapila wrote:
On Thursday, July 18, 2013 12:38 AM Josh Berkus wrote:
On 07/17/2013 12:01 PM, Alvaro Herrera wrote:
Both of these seem like they would make troubleshooters' lives more
difficult. I think we should just parse the auto file automatically
after
On Fri, Jul 19, 2013 at 2:45 AM, Josh Berkus j...@agliodbs.com wrote:
On 07/18/2013 04:25 AM, Amit Kapila wrote:
On Thursday, July 18, 2013 12:38 AM Josh Berkus wrote:
On 07/17/2013 12:01 PM, Alvaro Herrera wrote:
Both of these seem like they would make troubleshooters' lives more
difficult.
Fujii Masao escribió:
On Fri, Jul 19, 2013 at 2:45 AM, Josh Berkus j...@agliodbs.com wrote:
On 07/18/2013 04:25 AM, Amit Kapila wrote:
On Thursday, July 18, 2013 12:38 AM Josh Berkus wrote:
On 07/17/2013 12:01 PM, Alvaro Herrera wrote:
Both of these seem like they would make
Alvaro,
I think the only drawback of this is that there's no way to disable
ALTER SYSTEM (i.e. there's no directory you can remove to prevent the
thing from working). But is this a desirable property? I mean, if we
want to disallow ALTER SYSTEM I think we should provide a direct way to
do
Josh Berkus escribió:
We are missing one feature, which is the ability to relocate the
postgresql.auto.conf file if relocating it is desireable according to
some sysadmin spec. This kind of ties into another patch which was
discussed on this list -- the ability to relocate the recovery.conf
On 7/18/13 4:02 PM, Alvaro Herrera wrote:
I think we should just put the config directives of ALTER SYSTEM into a
file, not dir, alongside postgresql.conf; I would suggest
postgresql.auto.conf. This file is parsed automatically after
postgresql.conf, without requiring an include directive in
Greg,
I thought this was a good spot to try and re-draw this line because I
don't want just one program that is able to create new configuration
entries easily. I want to see a whole universe of them. ALTER SYSTEM
SET, tuning helpers, replication helpers, logging helpers, vacuum
On Friday, July 19, 2013 1:33 AM Alvaro Herrera wrote:
Fujii Masao escribió:
On Fri, Jul 19, 2013 at 2:45 AM, Josh Berkus j...@agliodbs.com
wrote:
On 07/18/2013 04:25 AM, Amit Kapila wrote:
On Thursday, July 18, 2013 12:38 AM Josh Berkus wrote:
On 07/17/2013 12:01 PM, Alvaro Herrera
Amit kapila escribió:
+# This includes the default configuration directory included to support
+# ALTER SYSTEM statement.
+#
+# WARNING: User should not remove below include_dir or directory config,
+# as both are required to make ALTER SYSTEM command work.
+# Any
On 07/17/2013 12:01 PM, Alvaro Herrera wrote:
Both of these seem like they would make troubleshooters' lives more
difficult. I think we should just parse the auto file automatically
after parsing postgresql.conf, without requiring the include directive
to be there.
Wait, I thought the auto
On Fri, Jul 12, 2013 at 9:15 AM, Amit kapila amit.kap...@huawei.com wrote:
The sleep is used to ensure the effects of pg_reload_conf() can be visible.
That strikes me as almost certain to result in random regression test
failures. My experience, as a man who helps to maintain a very large
suite
Robert Haas escribió:
This feature doesn't strike me as a good candidate for regression
testing anyway. Keep in mind that people are intended to be able to
run make installcheck against a deployed system without messing it up.
This is my opinion as well.
--
Álvaro Herrera
On 2013-07-17 17:05:40 -0400, Alvaro Herrera wrote:
Robert Haas escribió:
This feature doesn't strike me as a good candidate for regression
testing anyway. Keep in mind that people are intended to be able to
run make installcheck against a deployed system without messing it up.
This
On 07/17/2013 03:17 PM, Andres Freund wrote:
On 2013-07-17 17:05:40 -0400, Alvaro Herrera wrote:
Robert Haas escribió:
This feature doesn't strike me as a good candidate for regression
testing anyway. Keep in mind that people are intended to be able to
run make installcheck against a
If we are going to add ALTER SYSTEM, then I'd like to consider recasting
ALTER ROLE ALL SET in terms of ALTER SYSTEM as well, because the ALTER
ROLE ALL syntax was a hack. At least it should be possible to consider
various levels of system. Who knows, maybe a future version will
allow
On Tue, 2013-07-16 at 04:23 +, Amit kapila wrote:
Why do we need to expose this setting to a user?
a) This can be a knob to turn this feature off. This has been asked by
few people,
one of the mail link is mentioned below (refer towards end of mail
in the link):
On Thursday, July 18, 2013 2:36 AM Alvaro Herrera wrote:
Robert Haas escribió:
This feature doesn't strike me as a good candidate for regression
testing anyway. Keep in mind that people are intended to be able to
run make installcheck against a deployed system without messing it
up.
On Thursday, July 18, 2013 12:31 AM Alvaro Herrera wrote:
Amit kapila escribió:
+# This includes the default configuration directory included to
support
+# ALTER SYSTEM statement.
+#
+# WARNING: User should not remove below include_dir or directory
config,
+# as both
On Mon, Jul 15, 2013 at 10:43 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Friday, July 12, 2013 6:46 PM Amit kapila wrote:
On Friday, July 12, 2013 12:02 AM Fujii Masao wrote:
On Fri, Jul 5, 2013 at 2:19 PM, Amit Kapila amit.kap...@huawei.com
wrote:
On Wednesday, July 03, 2013 2:58 AM
On Monday, July 15, 2013 11:51 PM Fujii Masao wrote:
On Mon, Jul 15, 2013 at 10:43 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Friday, July 12, 2013 6:46 PM Amit kapila wrote:
On Friday, July 12, 2013 12:02 AM Fujii Masao wrote:
On Fri, Jul 5, 2013 at 2:19 PM, Amit Kapila
On Friday, July 12, 2013 12:02 AM Fujii Masao wrote:
On Fri, Jul 5, 2013 at 2:19 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Wednesday, July 03, 2013 2:58 AM Alvaro Herrera wrote:
Amit Kapila escribió:
I got the following compile warnings.
guc.c:5187: warning: no previous prototype for
On 07/12/2013 09:15 AM, Amit kapila wrote:
guc.c:5187: warning: no previous prototype for 'validate_conf_option'
preproc.y:7746.2-31: warning: type clash on default action: str !=
I generally use windows as dev environment, it hasn't shown these warnings.
Hackers, please take note.
On 07/12/2013 06:15 AM, Amit kapila wrote:
I generally use windows as dev environment, it hasn't shown these warnings.
I shall check in linux and correct the same.
Really? Hey, I'm gonna send you a lot of Windows-specific patches for
testing in the future ...
--
Josh Berkus
PostgreSQL
On Friday, July 12, 2013 10:07 PM Josh Berkus wrote:
On 07/12/2013 06:15 AM, Amit kapila wrote:
I generally use windows as dev environment, it hasn't shown these warnings.
I shall check in linux and correct the same.
Really?
Yes.
Hey, I'm gonna send you a lot of Windows-specific patches
On Fri, Jul 5, 2013 at 2:19 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Wednesday, July 03, 2013 2:58 AM Alvaro Herrera wrote:
Amit Kapila escribió:
I have changed the file name to postgresql.auto.conf and I have
changed the
name of SetPersistentLock to AutoFileLock.
Zoltan,
On 22 June 2013 05:17, Amit kapila amit.kap...@huawei.com wrote:
On Friday, June 21, 2013 11:48 PM Robert Haas wrote:
On Thu, Jun 20, 2013 at 12:18 AM, Amit Kapila amit.kap...@huawei.com
wrote:
Auto.conf- 1 Vote (Josh)
System.auto.conf - 1 Vote (Josh)
Postgresql.auto.conf
On Wednesday, July 03, 2013 11:42 AM Simon Riggs wrote:
On 22 June 2013 05:17, Amit kapila amit.kap...@huawei.com wrote:
On Friday, June 21, 2013 11:48 PM Robert Haas wrote:
On Thu, Jun 20, 2013 at 12:18 AM, Amit Kapila amit.kap...@huawei.com
wrote:
Auto.conf - 1 Vote (Josh)
On Wednesday, July 03, 2013 2:58 AM Alvaro Herrera wrote:
Amit Kapila escribió:
I have changed the file name to postgresql.auto.conf and I have
changed the
name of SetPersistentLock to AutoFileLock.
Zoltan,
Could you please once check the attached Patch if you have time, as
now
On 3 July 2013 07:45, Amit Kapila amit.kap...@huawei.com wrote:
postgresql.auto.conf is similar enough to postgresql.conf that it will
prevent tab completion from working as it does now. As a result it will
cause
people to bring that file up for editing when we wish to avoid that.
This
On Wednesday, July 03, 2013 6:29 PM Simon Riggs wrote:
On 3 July 2013 07:45, Amit Kapila amit.kap...@huawei.com wrote:
postgresql.auto.conf is similar enough to postgresql.conf that it will
prevent tab completion from working as it does now. As a result it will
cause
people to bring that file
Amit Kapila escribió:
I have changed the file name to postgresql.auto.conf and I have changed the
name of SetPersistentLock to AutoFileLock.
Zoltan,
Could you please once check the attached Patch if you have time, as now all
the things are resolved except for small doubt in syntax
I'll also vote for postgresql.auto.conf.
Thanks to all of you for suggesting meaningful names. I will change the
name of file to postgresql.auto.conf.
Kindly let me know if there is any objection to it.
There is no name you could come up with for which there would not be an
objection.
On Wednesday, June 26, 2013 5:03 AM Josh Berkus wrote:
I'll also vote for postgresql.auto.conf.
Thanks to all of you for suggesting meaningful names. I will change
the name of file to postgresql.auto.conf.
Kindly let me know if there is any objection to it.
There is no name you
On Thu, Jun 20, 2013 at 12:18 AM, Amit Kapila amit.kap...@huawei.com wrote:
Auto.conf- 1 Vote (Josh)
System.auto.conf - 1 Vote (Josh)
Postgresql.auto.conf - 2 Votes (Zoltan, Amit)
Persistent.auto.conf - 0 Vote
generated_by_server.conf - 1 Vote (Peter E)
System.conf
On Friday, June 21, 2013 11:48 PM Robert Haas wrote:
On Thu, Jun 20, 2013 at 12:18 AM, Amit Kapila amit.kap...@huawei.com wrote:
Auto.conf- 1 Vote (Josh)
System.auto.conf - 1 Vote (Josh)
Postgresql.auto.conf - 2 Votes (Zoltan, Amit)
Persistent.auto.conf - 0 Vote
On Tuesday, June 18, 2013 11:25 PM Josh Berkus wrote:
Amit,
I think, the decision of name, we can leave to committer with below
possibilities,
as it is very difficult to build consensus on any particular name.
Auto.conf
System.auto.conf
Postgresql.auto.conf
Persistent.auto.conf
101 - 200 of 216 matches
Mail list logo
