Bruce Momjian wrote:
I had to change the draft flag for SGML from 'gmake draft html' to
'gmake DRAFT=Y html'. Internally the code used to recurse with
DRAFT=Y, but I found there is no way to exit the makefile after the
recursion returned,
exit 0 ?
so I had to use this new syntax. Though
Pavan Deolasee [EMAIL PROTECTED] writes:
Attached is a patch which should marginally improve the ctid chain followin
code path when current and the next tuple in the chain are in the same
block.
It looks to me that you have introduced a buffer leak into
heap_get_latest_tid ... which is quite
Peter Eisentraut wrote:
Bruce Momjian wrote:
I had to change the draft flag for SGML from 'gmake draft html' to
'gmake DRAFT=Y html'. Internally the code used to recurse with
DRAFT=Y, but I found there is no way to exit the makefile after the
recursion returned,
exit 0 ?
I tried
Bruce Momjian wrote:
Nothing, but the point is that draft is a modifier and it isn't clear
from that syntax that draft is a modifier and not a target.
Anyway, certainly you could write this to preserve the target:
draft:
$(MAKE) html DRAFT=Y
The problem is that the 'gmake'
Here's a patch along the same lines as the fix for plperl committed
earlier today, that allows passing type aliases to spi_prepare as well
as types named in pg_type. It also removes the mention of the previous
limitation in the pltcl docs. Unlike the plperl and pltcl cases, I
didn't use the
On 1/27/07, Tom Lane [EMAIL PROTECTED] wrote:
It looks to me that you have introduced a buffer leak into
heap_get_latest_tid ...
I can't spot that. A previously pinned buffer is released at the start
of the loop if we are moving to a different block. Otherwise, the buffer
is released at all
Peter Eisentraut wrote:
Bruce Momjian wrote:
Nothing, but the point is that draft is a modifier and it isn't clear
from that syntax that draft is a modifier and not a target.
Anyway, certainly you could write this to preserve the target:
draft:
$(MAKE) html DRAFT=Y
The
Bruce Momjian wrote:
Well, if 'draft' was only for html, I could see suggesting just 'gmake
draft', but 'draft' can be used for Postscript and PDF too.
The maybe have targets draft-html, draft-postscript and draft-pdf ?
cheers
andrew
---(end of
Neil Conway [EMAIL PROTECTED] writes:
Attached is a patch that fixes this, by making bigcheck and bigtest
depend on the all target. Along the way, I removed some old Makefile
targets that were just aliases for existing targets, and refactored the
code for setting up the tablespace directory to
Pavan Deolasee [EMAIL PROTECTED] writes:
On 1/27/07, Tom Lane [EMAIL PROTECTED] wrote:
It looks to me that you have introduced a buffer leak into
heap_get_latest_tid ...
I can't spot that.
No, you're right, my apologies. I was thinking that the patch ought to
introduce an
Bruce Momjian [EMAIL PROTECTED] writes:
Well, if 'draft' was only for html, I could see suggesting just 'gmake
draft', but 'draft' can be used for Postscript and PDF too.
But those aren't cases where saving some typing is useful (in fact,
I'd bet money that no one will ever use them). Draft
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, if 'draft' was only for html, I could see suggesting just 'gmake
draft', but 'draft' can be used for Postscript and PDF too.
But those aren't cases where saving some typing is useful (in fact,
I'd bet money that no one will
This version of the patch includes documentation changes. Please
review...
--
The more things change, the more they stay insane.Index: doc/src/sgml/catalogs.sgml
===
RCS file:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Is there no API to return the name of signals?
There is, but it's not portable. If someone wants to perform an
exercise in writing configure code, look for strsignal() and
sys_siglist[].
Good idea. I only have sys_siglist[] on BSD/OS, and
New log output will look like:
LOG: server process (PID 29304) was terminated by signal: Bus error (10)
---
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Is there no API to return the name of
Bruce Momjian [EMAIL PROTECTED] writes:
Good idea. I only have sys_siglist[] on BSD/OS, and Linux and FreeBSD
have that too, so I only used that. We will now print both signal
descriptions and numbers for backend error exits, and descriptions only
for pclose() because we only have a
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Good idea. I only have sys_siglist[] on BSD/OS, and Linux and FreeBSD
have that too, so I only used that. We will now print both signal
descriptions and numbers for backend error exits, and descriptions only
for pclose() because we
Neil Conway wrote:
On Fri, 2007-01-26 at 13:11 +0100, Gevik Babakhani wrote:
As commented by Peter, I have done some re-styling.
Some additional tests and format checking have been added to this patch.
Barring any objections, I'll apply a revised version of this patch
tomorrow. We need
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
This patch has broken much of the buildfarm.
I think it is because I didn't have #include signal.h in exec.c. Added.
Doesn't seem to have helped ...
regards, tom lane
---(end of
19 matches
Mail list logo