Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-14 Thread Amir Rohan
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 "s

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-14 Thread Amir Rohan
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. >

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-14 Thread Amir Rohan
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

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-14 Thread Amir Rohan
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

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-14 Thread Amir Rohan
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

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-14 Thread Amir Rohan
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

[HACKERS] Re: Memory prefetching while sequentially fetching from SortTuple array, tuplestore

2015-10-13 Thread Amir Rohan
On 10/11/2015 03:20 AM, Peter Geoghegan wrote: > On Thu, Sep 3, 2015 at 5:35 PM, David Rowley > wrote: >> My test cases are: > > Note that my text caching and unsigned integer comparison patches have > moved the baseline down quite noticeably. I think that my mobile

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-13 Thread Amir Rohan
On 10/13/2015 09:20 PM, Robert Haas wrote: > On Mon, Oct 12, 2015 at 8:01 PM, Amir Rohan <amir.ro...@zoho.com> 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

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-13 Thread Amir Rohan
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 inte

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-13 Thread Amir Rohan
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

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-13 Thread Amir Rohan
On 10/14/2015 01:16 AM, Andres Freund wrote: > On October 13, 2015 11:14:19 PM GMT+02:00, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: >> Amir Rohan wrote: >> >>> I've been considering that. Reusing the parser would ensure no errors >>> are intro

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-12 Thread Amir Rohan
On 10/13/2015 02:02 AM, Robert Haas wrote: > On Fri, Oct 9, 2015 at 4:38 PM, Amir Rohan <amir.ro...@zoho.com> 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 floa

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-11 Thread Amir Rohan
On 10/11/2015 01:19 PM, Michael Paquier wrote: > On Sun, Oct 11, 2015 at 4:44 PM, Amir Rohan wrote: >> On 10/11/2015 02:47 AM, Michael Paquier wrote: >> I apologize -- that didn't came out right. >> What I meant to suggest was "open an issue" to track >> a

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-11 Thread Amir Rohan
On 10/11/2015 02:47 AM, Michael Paquier wrote: > On Sat, Oct 10, 2015 at 10:52 PM, Amir Rohan <amir.ro...@zoho.com> wrote: >> On 10/10/2015 04:32 PM, Michael Paquier wrote: >> I was arguing that it's an on-going task that would do >> better if it had a TODO list,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-10 Thread Amir Rohan
On 10/10/2015 04:32 PM, Michael Paquier wrote: > On Sat, Oct 10, 2015 at 9:04 PM, Amir Rohan wrote: >> Now that v9 fixes the problem, here's a summary from going over the >> entire thread one last time: > > Thanks a lot for the summary of the events. > >> # Windows

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-10 Thread Amir Rohan
On 10/10/2015 02:43 PM, Michael Paquier wrote: > On Fri, Oct 9, 2015 at 8:53 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Fri, Oct 9, 2015 at 8:47 PM, Amir Rohan wrote: >>> Ok, I've put myself down as reviewer in cfapp. I don't think I can >>&

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-10 Thread Amir Rohan
On 10/10/2015 04:32 PM, Michael Paquier wrote: > On Sat, Oct 10, 2015 at 9:04 PM, Amir Rohan wrote: >> The patch focuses on providing facilities, while providing new coverage >> for several features. There should be a TODO list on the wiki (bug >> tracker, actually), wh

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-09 Thread Amir Rohan
On 10/09/2015 09:55 PM, Robert Haas wrote: > On Thu, Oct 8, 2015 at 9:06 AM, Amir Rohan <amir.ro...@zoho.com> wrote: >> On 10/08/2015 02:38 PM, Tom Lane wrote: >>> Amir Rohan <amir.ro...@zoho.com> writes: >>>> Comments? >>> >>> IS

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-09 Thread Amir Rohan
On 10/09/2015 02:12 PM, Michael Paquier wrote: > On Fri, Oct 9, 2015 at 8:25 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Thu, Oct 8, 2015 at 11:28 PM, Amir Rohan wrote: >>> Wouldn't this work? >>> 1) start timer >>> 2) Grab pg_sta

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-08 Thread Amir Rohan
On 10/08/2015 08:19 AM, Michael Paquier wrote: > On Wed, Oct 7, 2015 at 5:44 PM, Amir Rohan wrote: >> On 10/07/2015 10:29 AM, Michael Paquier wrote: >>> On Wed, Oct 7, 2015 at 4:16 PM, Amir Rohan wrote: >>>> Also, the removal of poll_query_until from pg_rewind looks

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-08 Thread Amir Rohan
On 10/08/2015 10:39 AM, Michael Paquier wrote: > On Thu, Oct 8, 2015 at 3:59 PM, Amir Rohan <amir.ro...@zoho.com> wrote: >> On 10/08/2015 08:19 AM, Michael Paquier wrote: >>> On Wed, Oct 7, 2015 at 5:44 PM, Amir Rohan wrote: >>>> On 10/07/2015 10:29 AM, Michae

[HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-08 Thread Amir Rohan
Hi, Related SO question from '13: https://stackoverflow.com/questions/1619/how-to-syntax-check-postgresql-config-files Peter Eisentraut answered: > There is no way to do this that is similar to apache2ctl. If you reload > the configuration files and there is a syntax error, the PostgreSQL

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-08 Thread Amir Rohan
On 10/08/2015 04:47 PM, Michael Paquier wrote: > On Thu, Oct 8, 2015 at 6:03 PM, Amir Rohan wrote: >> On 10/08/2015 10:39 AM, Michael Paquier wrote: >>>> Someone mentioned a daisy chain setup which sounds fun. Anything else in >>>> particular? Also, it woul

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

2015-10-08 Thread Amir Rohan
On 10/08/2015 02:38 PM, Tom Lane wrote: > Amir Rohan <amir.ro...@zoho.com> 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 runnin

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-07 Thread Amir Rohan
On 10/07/2015 09:27 AM, Michael Paquier wrote: > On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier > wrote: >> On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier >> wrote: >>> On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote: On Sat, Oct 3,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-07 Thread Amir Rohan
On 10/07/2015 10:29 AM, Michael Paquier wrote: > On Wed, Oct 7, 2015 at 4:16 PM, Amir Rohan <amir.ro...@zoho.com> wrote: >> On 10/07/2015 09:27 AM, Michael Paquier wrote: >>> On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier >>> <michael.paqu...@gmail.com> wro

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-04 Thread Amir Rohan
On 10/04/2015 04:29 PM, Andres Freund wrote: > On October 4, 2015 3:27:00 PM GMT+02:00, Amir Rohan <amir.ro...@zoho.com> > wrote: > >> Perhaps it would help a little if you posted the latest patch here as >> well? So that at least the app picks it up again. > &

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-04 Thread Amir Rohan
On 10/02/2015 03:33 PM, Michael Paquier wrote: > > Michael, I'm afraid my email bungling has damaged your thread. I didn't include an "In-reply-To" header when I posted: trinity-b4a8035d-59af-4c42-a37e-258f0f28e44a-1443795007012@3capp-mailcom-lxa08. And we subsequently had our discussion over

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-03 Thread Amir Rohan
On 10/03/2015 03:50 PM, Amir Rohan wrote: > On 10/03/2015 02:38 PM, Michael Paquier wrote: >> On Fri, Oct 2, 2015 at 11:10 PM, Amir Rohan wrote: >>> On 10/02/2015 03:33 PM, Michael Paquier wrote: >>> >>> Granted, you have to try fairly hard to shoot yourself in

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-03 Thread Amir Rohan
On 10/03/2015 02:38 PM, Michael Paquier wrote: > On Fri, Oct 2, 2015 at 11:10 PM, Amir Rohan wrote: >> On 10/02/2015 03:33 PM, Michael Paquier wrote: >>> Any server instances created during the tests should never use a >>> user-defined port for portability. Hence using t

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-10-02 Thread Amir Rohan
On 10/02/2015 03:33 PM, Michael Paquier wrote: > Any server instances created during the tests should never use a > user-defined port for portability. Hence using those ports as keys > just made sense. We could have for example custom names, that have > port values assigned to them, but that's

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

2015-10-01 Thread Amir Rohan
> On 09/30/2015 03:27 PM, Tom Lane wrote: >> Josh Berkus writes: >>> On 09/30/2015 03:10 PM, Tom Lane wrote: I'd be feeling a lot more positive about this whole thread if any people had stepped up and said "yes, *I* will put in a lot of grunt-work to make

[HACKERS] Patch: Revised documentation on base backups

2015-09-27 Thread Amir Rohan
On 09/28/2015 06:33 AM, Michael Paquier wrote: > On Sun, Sep 27, 2015 at 11:27 AM, Amir Rohan wrote: >> Further editing. See attached V3. > > I think that you should consider adding this patch to the next commit > fest so as we do not lose track of it: > https://commit

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-09-25 Thread Amir Rohan
On 09/25/2015 01:47 PM, Michael Paquier wrote: > On Fri, Sep 25, 2015 at 5:57 PM, Amir Rohan <amir.ro...@mail.com> wrote: >> > That's the kind of thing that each serious developer on this mailing > list already has in a rather different shape but with the same final > re

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-09-25 Thread Amir Rohan
On 08/14/2015 06:32 AM, Michael Paquier wrote: > On Fri, Aug 14, 2015 at 12:54 AM, Michael Paquier > wrote: >> On Mon, Jun 29, 2015 at 10:11 PM, Michael Paquier >> wrote: >>> On Wed, Mar 18, 2015 at 1:59 PM, Michael Paquier >>>

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

2015-09-25 Thread Amir Rohan
On 09/25/2015 09:29 AM, Michael Paquier wrote: > > > On Fri, Sep 25, 2015 at 3:11 PM, Amir Rohan <amir.ro...@mail.com > <mailto:amir.ro...@mail.com>> wrote: > > On 08/14/2015 06:32 AM, Michael Paquier wrote: > > I am rather happy with the s

Re: [HACKERS] Support for N synchronous standby servers - take 2

2015-09-23 Thread Amir Rohan
> Sent: Thursday, September 24, 2015 at 3:11 AM > > From: "Tom Lane" > Robert Haas writes: > > Well, I think that if we create our own mini-language, it may well be > > possible to make the configuration for this compact enough to fit on > > one line.

Re: [HACKERS] Support for N synchronous standby servers - take 2

2015-09-22 Thread Amir Rohan
>On 07/16/15, Robert Haas wrote: >     >>> * Developers will immediately understand the format >> >>I doubt it.  I think any format that we pick will have to be carefully >>documented.  People may know what JSON looks like in general, but they >>will not immediately know what bells and whistles