Excerpts from Dimitri Fontaine's message of vie oct 22 16:43:56 -0300 2010:
> Dimitri Fontaine writes:
> > For information, when we talk about performance problem, please note
> > that on my workstation with a default setup (not that it's important
> > here) we're talking about 86,420 ms for a loo
Le 25 oct. 2010 à 17:26, Alvaro Herrera a écrit :
> Ah, some reading of the patch reveals that the "script" defaults to the
> control file name, but it can be overridden.
Yes, that's new in v10. In v11 I've kept that and removed the name property in
the control file, so that we have:
cat contri
Le 25 oct. 2010 à 17:26, Alvaro Herrera a écrit :
> Ah, some reading of the patch reveals that the "script" defaults to the
> control file name, but it can be overridden.
Yes, that's new in v10. In v11 I've kept that and removed the name property in
the control file, so that we have:
cat contri
On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine wrote:
> Ah yes, thinking it's an easy patch is not helping. Please find attached
> a revised version of it.
I checked cfparser.v2.patch.
It exports the static parseRecoveryCommandFileLine() in xlog.c
as the global cfParseOneLine() in cfparser.c wi
On Sun, Nov 21, 2010 at 8:10 PM, Itagaki Takahiro
wrote:
> On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine
> wrote:
>> Ah yes, thinking it's an easy patch is not helping. Please find attached
>> a revised version of it.
>
> I checked cfparser.v2.patch.
>
> It exports the static parseRecoveryComm
Itagaki Takahiro writes:
> I checked cfparser.v2.patch.
Thanks for reviewing it!
> It exports the static parseRecoveryCommandFileLine() in xlog.c
> as the global cfParseOneLine() in cfparser.c without modification.
>
> It generates one warning, but it can be easily fixed.
> cfparser.c:34: warn
On Mon, Nov 22, 2010 at 18:36, Dimitri Fontaine wrote:
>> * Can we export ParseConfigFile() in guc-file.l rather than
>> parseRecoveryCommandFileLine()?
>
> Should we then consider recovery.conf entries as ordinary GUCs? That
> would allow to connect to a standby and issue 'show primary_conninf
Itagaki Takahiro writes:
> No. My suggestion was just to use the internal parser.
What about something like the attached, cfparser.v3.patch?
If that looks ok, do we want to add some documentation about the new
lexer capabilities? Also, for what good reason would we want to prevent
people from us
Excerpts from Dimitri Fontaine's message of lun nov 22 18:12:39 -0300 2010:
> Itagaki Takahiro writes:
> > No. My suggestion was just to use the internal parser.
>
> What about something like the attached, cfparser.v3.patch?
>
> If that looks ok, do we want to add some documentation about the ne
Excerpts from Alvaro Herrera's message of lun nov 22 18:59:52 -0300 2010:
> Hmm, the first thought that comes to mind is that the GucContext param
> to ParseConfigFile is unused and can be removed. This is probably an
> oversight from when include files were introduced in 2006.
Committed and pus
Excerpts from Dimitri Fontaine's message of lun nov 22 18:12:39 -0300 2010:
> Itagaki Takahiro writes:
> > No. My suggestion was just to use the internal parser.
>
> What about something like the attached, cfparser.v3.patch?
the handling of relative vs absolute paths is bogus here. I think it'd
Alvaro Herrera writes:
> Hmm, the first thought that comes to mind is that the GucContext param
> to ParseConfigFile is unused and can be removed. This is probably an
> oversight from when include files were introduced in 2006.
Thanks for caring about that part.
> I don't like the fact that thi
Alvaro Herrera writes:
> the handling of relative vs absolute paths is bogus here. I think it'd
> make more sense to have a bool "are we including"; and if that's false and
> the path is not absolute, then the file is relative to CWD; or maybe we
> make it absolute by prepending PGDATA; maybe som
On 22.11.2010 03:35, Robert Haas wrote:
On Sun, Nov 21, 2010 at 8:10 PM, Itagaki Takahiro
wrote:
On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine wrote:
Ah yes, thinking it's an easy patch is not helping. Please find attached
a revised version of it.
I checked cfparser.v2.patch.
It exports
On Tue, Nov 23, 2010 at 18:19, Dimitri Fontaine wrote:
> Please find that done in attached v4 of the cfparser patch.
RECOVERY_COMMAND_FILE is opened twice in the patch. The first time
is for checking the existence, and the second time is for parsing.
Instead of the repeat, how about adding FILE*
Itagaki Takahiro writes:
> RECOVERY_COMMAND_FILE is opened twice in the patch. The first time
> is for checking the existence, and the second time is for parsing.
> Instead of the repeat, how about adding FILE* version of parser?
> It will be also called from ParseConfigFile() as a sub routine.
>
On Thu, Nov 25, 2010 at 05:02, Dimitri Fontaine wrote:
> Something like the attached, version 5 of the patch? I've been using the
> function name ParseConfigFp because the internal parameter was called fp
> in the previous function body. I suppose that could easily be changed at
> commit time if n
Itagaki Takahiro writes:
> Thanks. I'll move the patch to Ready for Committer.
Thanks!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
On Thu, Nov 25, 2010 at 4:06 PM, Dimitri Fontaine
wrote:
> Itagaki Takahiro writes:
>> Thanks. I'll move the patch to Ready for Committer.
>
> Thanks!
I have committed the cfparser patch to which the above comments refer.
One patch per thread makes things easier!
I adopted most of Itagaki Taka
Robert Haas writes:
> I have committed the cfparser patch to which the above comments refer.
Excellent, thank you! On to merging that into the extension's main
branch, will still wait until after pg_execute_sql_file() is in to
produce extension.v15.patch, unless advised otherwise.
Regards,
--
D
101 - 120 of 120 matches
Mail list logo
