Tom Lane wrote:
> Bruce Momjian writes:
> > I have applied the attached patch to mention the debugger. OK?
>
> > Server developers should consider using the configure options
> > --enable-cassert and --enable-debug to
> > enhance the
> > ability to detect and debug serv
Bruce Momjian writes:
> I have applied the attached patch to mention the debugger. OK?
> Server developers should consider using the configure options
> --enable-cassert and --enable-debug to enhance
> the
> ability to detect and debug server errors. They should also c
Robert Haas wrote:
> On Tue, Nov 29, 2011 at 7:13 PM, Bruce Momjian wrote:
> >> Yes. ?-O0 is really a pretty horrid default choice, and we should NOT be
> >> recommending it, especially not with no discussion of the disadvantages.
> >
> > I have applied the attached patch to mention the debugger.
On Tue, Nov 29, 2011 at 7:13 PM, Bruce Momjian wrote:
>> Yes. -O0 is really a pretty horrid default choice, and we should NOT be
>> recommending it, especially not with no discussion of the disadvantages.
>
> I have applied the attached patch to mention the debugger. OK?
Not really. That's sti
Tom Lane wrote:
> Peter Eisentraut writes:
> > On tis, 2011-11-29 at 16:32 -0500, Bruce Momjian wrote:
> >> I have applied the attached patch to help make suggestsions for server
> >> developers. I didn't reproduce most of the text because it was already
> >> listed with the options. Let me know
Peter Eisentraut writes:
> On tis, 2011-11-29 at 16:32 -0500, Bruce Momjian wrote:
>> I have applied the attached patch to help make suggestsions for server
>> developers. I didn't reproduce most of the text because it was already
>> listed with the options. Let me know if you want additional te
On tis, 2011-11-29 at 16:32 -0500, Bruce Momjian wrote:
> I have applied the attached patch to help make suggestsions for server
> developers. I didn't reproduce most of the text because it was already
> listed with the options. Let me know if you want additional text.
Advising "server developer
I have applied the attached patch to help make suggestsions for server
developers. I didn't reproduce most of the text because it was already
listed with the options. Let me know if you want additional text.
---
Greg Smith
On 06/20/2011 01:34 PM, Tom Lane wrote:
I was trying to illustrate how to have minimal turnaround time
when testing a small code change. Rebuilding from scratch is slow
enough that you lose focus while waiting. (Or I do, anyway.)
I just keep upgrading to the fastest CPU I can possibly jus
Alvaro Herrera writes:
> Excerpts from Greg Smith's message of lun jun 20 00:25:08 -0400 2011:
>> The peg utility script I use makes a reinstall as simple as:
>>
>> stop
>> peg build
> But you're building the entire server there, which was Tom's point --
> you only need to build and reinstall th
Excerpts from Greg Smith's message of lun jun 20 00:25:08 -0400 2011:
> Greg Stark wrote:
> > I've always wondered what other people do to iterate quickly.
>
> I'd have bet money you had an elisp program for this by now!
Yeah :-)
> The peg utility script I use makes a reinstall as simple as:
>
Greg Stark Monday 20 of June 2011 03:39:12
> On Thu, Jun 16, 2011 at 9:00 PM, Tom Lane wrote:
> > BTW, if you're hacking Postgres code and don't already have a
> > "reinstall" script, you need one. Mine is basically
> >
> >pg_ctl stop
> >cd $PGBLDROOT/src/backend
> >make
Greg Stark wrote:
I've always wondered what other people do to iterate quickly.
I'd have bet money you had an elisp program for this by now!
The peg utility script I use makes a reinstall as simple as:
stop
peg build
The UI for peg is still is a little rough around switching to another
proj
On Thu, Jun 16, 2011 at 9:00 PM, Tom Lane wrote:
> BTW, if you're hacking Postgres code and don't already have a
> "reinstall" script, you need one. Mine is basically
>
> pg_ctl stop
> cd $PGBLDROOT/src/backend
> make install-bin
> pg_ctl start
I've always wondered wh
On Thu, 16 Jun 2011 16:00:21 -0400, Tom Lane wrote:
Alvaro Herrera writes:
I disagree with this change. Debug builds are very useful to have
in
production, and you don't want to be running -O0 there. I have
found
that you can use a src/Makefile.custom like this for those times
when you
wan
Alvaro Herrera writes:
> I disagree with this change. Debug builds are very useful to have in
> production, and you don't want to be running -O0 there. I have found
> that you can use a src/Makefile.custom like this for those times when you
> want to debug stuff in a particular set of files:
>
Excerpts from Bernd Helmle's message of jue jun 16 09:37:24 -0400 2011:
>
>
> --On 16. Juni 2011 14:30:27 +0200 Radosław Smogura
> wrote:
>
> > Hello,
> >
> > I'm sending following patch which disables optimization when
> > --enable-debug
> > is passed. It was nasty (for me, at least) that
Excerpts from Radosław Smogura's message of jue jun 16 08:30:27 -0400 2011:
> Hello,
>
> I'm sending following patch which disables optimization when
> --enable-debug is passed. It was nasty (for me, at least) that debug
> build required passing of CFLAGS with -O0 to get nice traceable code.
On 06/16/2011 10:10 AM, Tom Lane wrote:
I could see providing some other nonstandard configure switch that
changed the default -O level ... but realistically, would that do
anything that you couldn't already do by setting CFLAGS, ie
./configure CFLAGS="-O0 -g"
I think a small discu
On Jun16, 2011, at 16:10 , Tom Lane wrote:
> Florian Pflug writes:
>> I usually use -O1 for debug builds, these are usually still at least
>> somewhat debuggable with gdb.
>
> I tend to do that too, but I still think that folding it into
> --enable-debug would be a mistake.
+1.
I didn't mean to
Florian Pflug writes:
> On Jun16, 2011, at 14:30 , RadosÅaw Smogura wrote:
>> I'm sending following patch which disables optimization when --enable-debug
>> is passed. It was nasty (for me, at least) that debug build required passing
>> of CFLAGS with -O0 to get nice traceable code.
> Unfortun
--On 16. Juni 2011 14:30:27 +0200 Radosław Smogura
wrote:
Hello,
I'm sending following patch which disables optimization when --enable-debug
is passed. It was nasty (for me, at least) that debug build required passing
of CFLAGS with -O0 to get nice traceable code.
-O0 hides bugs in
On Jun16, 2011, at 14:30 , Radosław Smogura wrote:
> I'm sending following patch which disables optimization when --enable-debug
> is passed. It was nasty (for me, at least) that debug build required passing
> of CFLAGS with -O0 to get nice traceable code.
Unfortunately, with some compilers (gcc
On Thu, 16 Jun 2011 14:30:27 +0200, Radosław Smogura wrote:
Hello,
I'm sending following patch which disables optimization when
--enable-debug is passed. It was nasty (for me, at least) that debug
build required passing of CFLAGS with -O0 to get nice traceable code.
Regards,
Radek
Sorry for m
Hello,
I'm sending following patch which disables optimization when
--enable-debug is passed. It was nasty (for me, at least) that debug
build required passing of CFLAGS with -O0 to get nice traceable code.
Regards,
Radekdiff --git a/configure.in b/configure.in
old mode 100644
new mode 100755
25 matches
Mail list logo
