Attached patch fixes two problems:
1) gendef works from inside visual studio - use a tempfile instead of
redirection, because for some reason you can't redirect dumpbin from
inside (patch from Joachim Wieland)
2) gendef must process only *.obj, or you get weird errors in some build
scenarios when
On 1/9/07, Gurjeet Singh <[EMAIL PROTECTED]> wrote:
I have another idea for making the hooks a bit more cleaner; I will try
that and run it through you guys later today.
Please find attached the latest version of the patch. It applies cleanly on
REL8_2_STABLE.
The following restrictions are
Patch withdrawn by author.
---
Simon Riggs wrote:
> http://archives.postgresql.org/pgsql-hackers/2006-10/msg01172.php
>
> As discussed on -hackers, its possible to avoid writing any WAL at all
> for COPY in these circumstan
This patch enables verbose output when building all projects. This is
the same output level that was used when building a single project
before, and really needed to get reasonable information about what
happens (non-verbose just says "starting build of foo" and "done
building foo", more or less).
VERSION 2, with all changed made as requested to date.
As discussed on -hackers, its possible to avoid writing any WAL at all
for COPY in these circumstances:
http://archives.postgresql.org/pgsql-hackers/2006-10/msg01172.php
and again recently.
BEGIN;
CREATE TABLE foo..
COPY foo...
COMMIT;
In response to Bruce Momjian <[EMAIL PROTECTED]>:
>
> I have applied a modified version of your patch. I renamed the
> parameter to 'log_temp_files', for consistency, added documentation, and
> improved the wording, particularly mentioning that the logging happens
> at file deletion time.
Thanks
Patch applied. Thanks.
I added a comment about the unused bits in the header file.
---
Heikki Linnakangas wrote:
> Hi,
>
> We're running out of infomask bits in the tuple header. I bumped into
> this as I tried to appl
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Magn
Would you like this applied?
---
Magnus Hagander wrote:
> Magnus Hagander wrote:
> > Hello!
> >
> > Per some previous discussion that I can't really recall if it was on or
> > off list, here is a WIP patch to make pg_regres
Patch applied. Thanks.
---
Michael Fuhr wrote:
> Update the UTF-8 RFC reference. RFC 2044 was obsoleted by RFC 2279,
> which was obsoleted by RFC 3629.
>
> --
> Michael Fuhr
[ Attachment, skipping... ]
>
> ---
I don't have much time lately so if you're willing to work on it, please do.
A Dimarts 09 Gener 2007 02:51, Jaime Casanova va escriure:
> On 1/8/07, Jaime Casanova <[EMAIL PROTECTED]> wrote:
> > maybe once this patch is applied you can think on make indexes and
> > [temp] sequences on temp tables
The attached patch against PostgreSQL-8.2.1 was discussed on [INTERFACES].
It fixes bcc32.mak makefiles for the Borland BCC compiler to build libpq
and psql*. There are also changes to some header files to hide some things
BCC doesn't like.
*Note: psql compiles with bcc after the patch, but it doe
On Tue, 9 Jan 2007, L Bayuk wrote:
> The attached patch against PostgreSQL-8.2.1 was discussed on [INTERFACES].
> It fixes bcc32.mak makefiles for the Borland BCC compiler to build libpq
> and psql*. There are also changes to some header files to hide some things
> BCC doesn't like.
>
> *Note: psq
Gavin Sherry wrote:
> On Tue, 9 Jan 2007, L Bayuk wrote:
>
> > The attached patch against PostgreSQL-8.2.1 was discussed on [INTERFACES].
> > It fixes bcc32.mak makefiles for the Borland BCC compiler to build libpq
> > and psql*. There are also changes to some header files to hide some things
> >
On Tue, 9 Jan 2007, Bruce Momjian wrote:
> Gavin Sherry wrote:
> > On Tue, 9 Jan 2007, L Bayuk wrote:
> >
> > > The attached patch against PostgreSQL-8.2.1 was discussed on [INTERFACES].
> > > It fixes bcc32.mak makefiles for the Borland BCC compiler to build libpq
> > > and psql*. There are also
Gavin Sherry wrote:
> On Tue, 9 Jan 2007, Bruce Momjian wrote:
>
> > Gavin Sherry wrote:
> > > On Tue, 9 Jan 2007, L Bayuk wrote:
> > >
> > > > The attached patch against PostgreSQL-8.2.1 was discussed on
> > > > [INTERFACES].
> > > > It fixes bcc32.mak makefiles for the Borland BCC compiler to b
On Tue, 2007-01-09 at 18:56 +0100, Magnus Hagander wrote:
> This patch enables verbose output when building all projects.
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
On Tue, 2007-01-09 at 12:29 +0100, Magnus Hagander wrote:
> Attached patch fixes two problems:
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to
On 1/9/07, Albert Cervera Areny <[EMAIL PROTECTED]> wrote:
I don't have much time lately so if you're willing to work on it, please do.
after doing the index part i revisited the patch again and saw that
there is something fundamentally wrong here (sorry for no noticing
that before :( )
your
Bill Moran wrote:
> In response to Tom Lane <[EMAIL PROTECTED]>:
>
> > Bill Moran <[EMAIL PROTECTED]> writes:
> > > Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > >>> Might be more robust to say
> > >>> if (trace_temp_files >= 0)
> >
> > > I specified in the GUC config that minimum allowable value
Bruce Momjian <[EMAIL PROTECTED]> writes:
> + A value of zero logs all temporary files, and positive
> + values log only files whose size is equal or greater than
> + the specified number of bytes.
Surely the measurement unit should be kbytes or disk blocks. And why
aren't
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > + A value of zero logs all temporary files, and positive
> > + values log only files whose size is equal or greater than
> > + the specified number of bytes.
>
> Surely the measurement unit should be kbytes or
Patch applied.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Peter Eisentraut wrote:
> > >> The problem is that this requires two runs even to proof the
> > >> documentation,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Surely the measurement unit should be kbytes or disk blocks. And why
>> aren't you using that GUC UNITS infrastructure Peter put in?
> Agreed. I have applied the following patch to make it kilobytes, and
> documented it. I didn't pu
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Patch applied. Thanks.
> I added a comment about the unused bits in the header file.
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
re
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Surely the measurement unit should be kbytes or disk blocks. And why
> >> aren't you using that GUC UNITS infrastructure Peter put in?
>
> > Agreed. I have applied the following patch to make it kilobytes, and
>
In response to Tom Lane <[EMAIL PROTECTED]>:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Surely the measurement unit should be kbytes or disk blocks. And why
> >> aren't you using that GUC UNITS infrastructure Peter put in?
>
> > Agreed. I have applied the following pat
Bill Moran <[EMAIL PROTECTED]> writes:
> In response to Tom Lane <[EMAIL PROTECTED]>:
>> and then zero
>> can be the "off" position, and we need not worry about whether -1 is
>> -1 byte or -1 kbyte.
> All doing this does is make it impossible to log temp files of 1 byte.
How you figure that? It
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Patch applied. Thanks.
> > I added a comment about the unused bits in the header file.
>
> Has anyone bothered to measure the overhead added by having to mask to
> fetch or store the natts value? This is not a zero-cost improvement.
Bill Moran <[EMAIL PROTECTED]> writes:
> In response to Tom Lane <[EMAIL PROTECTED]>:
>> Hmm, that could be a little bit ugly. Suggestion: redefine the value
>> such that files *greater than* the given size are logged,
> It already is that way, with 0 effectively meaning "log all".
Oh, never min
Tom Lane wrote:
> Bill Moran <[EMAIL PROTECTED]> writes:
> > In response to Tom Lane <[EMAIL PROTECTED]>:
> >> and then zero
> >> can be the "off" position, and we need not worry about whether -1 is
> >> -1 byte or -1 kbyte.
>
> > All doing this does is make it impossible to log temp files of 1 by
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Patch applied. Thanks.
> > I added a comment about the unused bits in the header file.
>
> Has anyone bothered to measure the overhead added by having to mask to
> fetch or store the natts value? This is not a zero-cost improvement.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> SHOW ALL has:
>log_temp_files | -1 | Log the
> use of temporary files larger than th
Yeah, but if you do "SET log_temp_files = -1", does it still say that?
I'm worried that will change it to -1024.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Has anyone bothered to measure the overhead added by having to mask to
>> fetch or store the natts value? This is not a zero-cost improvement.
> Tom, how should this be tested? I assume some loop of the same query
> over and over aga
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > SHOW ALL has:
>
> >log_temp_files | -1 | Log
> > the use of temporary files larger than th
>
> Yeah, but if you do "SET log_temp_files = -1", does it still say that?
> I'm worried
Bruce Momjian wrote:
> > %-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl bookindex.sgml
> > $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $<
> > + ifndef DRAFT
> > + [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
> > + endif
What is the point of that?
--
Pete
Bruce Momjian wrote:
> > + ifndef DRAFT
> > + [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
> > + endif
Why are you using $*? This isn't a pattern rule.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)--
Bruce Momjian wrote:
> > ! draft:
> > ! ifndef DRAFT
> > ! ifneq ($(MAKECMDGOALS), draft)
How could this condition ever match?
> > ! # Call ourselves with the DRAFT value set. This seems to be the only
> > ! # way to set gmake variables in a rule.
> > ! [EMAIL PROTECTED](MAKE) DRAFT="Y" $(MAKEC
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > > ? %-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl bookindex.sgml
> > > ? $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $<
> > > + ifndef DRAFT
> > > + [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
> > > + endif
>
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > > + ifndef DRAFT
> > > + [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
> > > + endif
>
> Why are you using $*? This isn't a pattern rule.
>
Sorry, my mistake. Here is an patch to fix that.
--
Bruce Momjian [EMAIL PROTECT
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > > ! draft:
> > > ! ifndef DRAFT
> > > ! ifneq ($(MAKECMDGOALS), draft)
>
> How could this condition ever match?
On first call, 'draft' might be set, but in the recursive call, this
code will not be reached because DRAFT iss set.
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Can we be sure that a BCC build libpq is even safe to use given the
> problems seen when using psql?
Well, I'd not trust it a lot, but surely we have to get it to build
before anyone can debug it ...
regards, tom lane
---
42 matches
Mail list logo
