On 10/14/15 1:50 PM, Andres Freund wrote:
> On October 14, 2015 7:45:53 PM GMT+02:00, Alvaro Herrera
> wrote:
>> Amir Rohan wrote:
>>
>>> it does fail the "dependent options" test:
>>> $ postgres -C "archive_mode"
>>> on
>>> $ postgres -C wal_level
>>> minimal
>>>
>>> no errors, great, let's try
On Wed, Oct 14, 2015 at 6:30 AM, Andres Freund wrote:
> On 2015-10-14 01:54:46 +0300, Amir Rohan wrote:
>> Andres, please see upthread for quite a bit on what it doesn't do, and
>> why having it in the server is both an advantages and a shortcoming.
>
> As far as I have skimmed the thread it's onl
IOn 10/14/2015 08:45 PM, Alvaro Herrera wrote:
> Amir Rohan wrote:
>
>> it does fail the "dependent options" test:
>> $ postgres -C "archive_mode"
>> on
>> $ postgres -C wal_level
>> minimal
>>
>> no errors, great, let's try it:
>> $ pg_ctl restart
>>
>> FATAL: WAL archival cannot be enabled whe
On October 14, 2015 7:45:53 PM GMT+02:00, Alvaro Herrera
wrote:
>Amir Rohan wrote:
>
>> it does fail the "dependent options" test:
>> $ postgres -C "archive_mode"
>> on
>> $ postgres -C wal_level
>> minimal
>>
>> no errors, great, let's try it:
>> $ pg_ctl restart
>>
>> FATAL: WAL archival can
Amir Rohan wrote:
> it does fail the "dependent options" test:
> $ postgres -C "archive_mode"
> on
> $ postgres -C wal_level
> minimal
>
> no errors, great, let's try it:
> $ pg_ctl restart
>
> FATAL: WAL archival cannot be enabled when wal_level is "minimal"
This complaint could be fixed we h
On 10/14/2015 07:41 PM, David Fetter wrote:
>> On Wed, Oct 14, 2015 at 01:52:21AM +0300, Amir Rohan wrote:
>>
>> I've considered "vendoring", but it seems like enough code surgery
>> be involved to make this very dubious "reuse". The language is simple
>> enough that writing a parser from scratch
On Wed, Oct 14, 2015 at 01:52:21AM +0300, Amir Rohan wrote:
> On 10/14/2015 01:12 AM, Alvaro Herrera wrote:
> > Amir Rohan wrote:
> >> On 10/14/2015 12:14 AM, Alvaro Herrera wrote:
> >>> Amir Rohan wrote:
> >>>
> I've been considering that. Reusing the parser would ensure no errors
> are
On 10/14/2015 05:55 PM, Andres Freund wrote:
> On 2015-10-14 17:46:25 +0300, Amir Rohan wrote:
>> On 10/14/2015 05:35 PM, Andres Freund wrote:
>>> Then your argument about the CF process doesn't seem to make sense.
>
>> Why? I ask again, what do you mean by "separate process"?
>
> Not going throu
On 2015-10-14 17:46:25 +0300, Amir Rohan wrote:
> On 10/14/2015 05:35 PM, Andres Freund wrote:
> > Then your argument about the CF process doesn't seem to make sense.
> Why? I ask again, what do you mean by "separate process"?
Not going through the CF and normal release process.
> either it's in
On 10/14/2015 05:35 PM, Andres Freund wrote:
> On 2015-10-14 16:50:41 +0300, Amir Rohan wrote:
>>> I don't think we as a community want to do that without review
>>> mechanisms in place, and I personally don't think we want to add
>>> separate processes for this.
>>>
>>
>> That's what "contribute"
On 2015-10-14 16:50:41 +0300, Amir Rohan wrote:
> > I don't think we as a community want to do that without review
> > mechanisms in place, and I personally don't think we want to add
> > separate processes for this.
> >
>
> That's what "contribute" means in my book.
Then your argument about the
On 10/14/2015 04:24 PM, Andres Freund wrote:
> On 2015-10-14 16:17:55 +0300, Amir Rohan wrote:
>> it does fail the "dependent options" test:
>> $ postgres -C "archive_mode"
>> on
>> $ postgres -C wal_level
>> minimal
>
> Yea, because that's currently evaluated outside the config
> mechanism. It'd
On 2015-10-14 16:17:55 +0300, Amir Rohan wrote:
> it does fail the "dependent options" test:
> $ postgres -C "archive_mode"
> on
> $ postgres -C wal_level
> minimal
Yea, because that's currently evaluated outside the config
mechanism. It'd imo would be good to change that independent of this
threa
On 10/14/2015 01:30 PM, Andres Freund wrote:
> On 2015-10-14 01:54:46 +0300, Amir Rohan wrote:
>> Andres, please see upthread for quite a bit on what it doesn't do, and
>> why having it in the server is both an advantages and a shortcoming.
>
> As far as I have skimmed the thread it's only talking
On 2015-10-14 01:54:46 +0300, Amir Rohan wrote:
> Andres, please see upthread for quite a bit on what it doesn't do, and
> why having it in the server is both an advantages and a shortcoming.
As far as I have skimmed the thread it's only talking about shortcoming
in case it requires a running serv
On 10/14/2015 01:16 AM, Andres Freund wrote:
> On October 13, 2015 11:14:19 PM GMT+02:00, Alvaro Herrera
> wrote:
>> Amir Rohan wrote:
>>
>>> I've been considering that. Reusing the parser would ensure no errors
>>> are introduces by having a different implementation, but on the other
>>> hand in
On 10/14/2015 01:12 AM, Alvaro Herrera wrote:
> Amir Rohan wrote:
>> On 10/14/2015 12:14 AM, Alvaro Herrera wrote:
>>> Amir Rohan wrote:
>>>
I've been considering that. Reusing the parser would ensure no errors
are introduces by having a different implementation, but on the other
han
On October 13, 2015 11:14:19 PM GMT+02:00, Alvaro Herrera
wrote:
>Amir Rohan wrote:
>
>> I've been considering that. Reusing the parser would ensure no errors
>> are introduces by having a different implementation, but on the other
>> hand involving the pg build in installation what's intended as
Amir Rohan wrote:
> On 10/14/2015 12:14 AM, Alvaro Herrera wrote:
> > Amir Rohan wrote:
> >
> >> I've been considering that. Reusing the parser would ensure no errors
> >> are introduces by having a different implementation, but on the other
> >> hand involving the pg build in installation what's
On 10/14/2015 12:14 AM, Alvaro Herrera wrote:
> Amir Rohan wrote:
>
>> I've been considering that. Reusing the parser would ensure no errors
>> are introduces by having a different implementation, but on the other
>> hand involving the pg build in installation what's intended as a
>> lightweight,
Amir Rohan wrote:
> I've been considering that. Reusing the parser would ensure no errors
> are introduces by having a different implementation, but on the other
> hand involving the pg build in installation what's intended as a
> lightweight, independent tool would hurt.
> Because it's dubious wh
On 10/13/2015 09:20 PM, Robert Haas wrote:
> On Mon, Oct 12, 2015 at 8:01 PM, Amir Rohan wrote:
>> That wasn't my intention. Perhaps I'm overreacting to a long-standing
>> "Tom Lane's bucket of cold water" tradition. I'm new here.
>> I understand your point and I was only reiterating what in parti
On Mon, Oct 12, 2015 at 8:01 PM, Amir Rohan wrote:
> That wasn't my intention. Perhaps I'm overreacting to a long-standing
> "Tom Lane's bucket of cold water" tradition. I'm new here.
> I understand your point and I was only reiterating what in particular
> makes the conf checker distinctly useful
On 10/13/2015 02:02 AM, Robert Haas wrote:
> On Fri, Oct 9, 2015 at 4:38 PM, Amir Rohan wrote:
>> It does catch bad syntax, but in most cases all you get is
>> "The setting could not be applied". that's not great for enums
>> or a float instead of an int. I guess a future version will fix that
>>
On Fri, Oct 9, 2015 at 4:38 PM, Amir Rohan wrote:
> It does catch bad syntax, but in most cases all you get is
> "The setting could not be applied". that's not great for enums
> or a float instead of an int. I guess a future version will fix that
> (or not).
I expect we would consider patches to
On 10/09/2015 09:55 PM, Robert Haas wrote:
> On Thu, Oct 8, 2015 at 9:06 AM, Amir Rohan wrote:
>> On 10/08/2015 02:38 PM, Tom Lane wrote:
>>> Amir Rohan writes:
Comments?
>>>
>>> ISTM that all of the "functional" parts of this are superseded by
>>> pg_file_settings;
>>
>> To use the new pg_f
On Thu, Oct 8, 2015 at 9:06 AM, Amir Rohan wrote:
> On 10/08/2015 02:38 PM, Tom Lane wrote:
>> Amir Rohan writes:
>>> Comments?
>>
>> ISTM that all of the "functional" parts of this are superseded by
>> pg_file_settings;
>
> To use the new pg_file_settings view you need:
> 1( 9.5+
> 2( a running
On Thu, Oct 8, 2015 at 7:07 AM, Amir Rohan wrote:
> In addition to a simple syntax check, there's a bunch of "config wisdom"
> tidbits I've encountering, which is scattered through talks, commit
> messages, and mailing list discussion, and documentation notes
> (chapter 17, paragraph 12). These co
On 10/08/2015 02:38 PM, Tom Lane wrote:
> Amir Rohan writes:
>> Comments?
>
> ISTM that all of the "functional" parts of this are superseded by
> pg_file_settings;
To use the new pg_file_settings view you need:
1( 9.5+
2( a running server
The feature is describes as follows in a97e0c3354ace5d7
Amir Rohan writes:
> Comments?
ISTM that all of the "functional" parts of this are superseded by
pg_file_settings; or at least, if they aren't, you need to provide a
rationale that doesn't consist only of pointing to pre-9.5 discussions.
The "advice" parts of it maybe are still useful, but a tool
30 matches
Mail list logo