Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The attached patch adds a test for libxslt/xslt.h and only builds
> contrib/xml2 if it's found, which I think should handle Peter's
> objection, as well as unbreak the buildfarm. (The patch is large because
> cvs diff seems to have behaved a bit oddly
Bruce Momjian wrote:
Andrew Dunstan wrote:
Peter Eisentraut wrote:
And if it is, then you have several options:
. don't configure with libxml, or
. don't build contrib modules from the contrib Makefile (use the
individual module Makefiles instead), or
. change the xml2 Makefile
Bruce Momjian wrote:
Andrew Dunstan wrote:
Peter Eisentraut wrote:
And if it is, then you have several options:
. don't configure with libxml, or
. don't build contrib modules from the contrib Makefile (use the
individual module Makefiles instead), or
. change the xml2 Makefile
On Tue, 2007-04-10 at 12:18 -0700, Gurjeet Singh wrote:
> Also, although the whole plan-tree is available in
> get_relation_info(), but it wouldn't be the right place to scan other
> tables, for eg., for generating JOIN-INDEXes or materializing some
> intermediate joins. (sometime in the futur
ITAGAKI Takahiro wrote:
> This patch replace _ftime() by QueryPerformanceCounter() to measure durations
> in psql \timing on Windows. It had only 15ms~ of time resolusion. I brought
> the codes from src/include/executor/instrument.h .
Applied, thanks.
//Magnus
---(end of
Andrew Dunstan wrote:
> Peter Eisentraut wrote:
> >> And if it is, then you have several options:
> >> . don't configure with libxml, or
> >> . don't build contrib modules from the contrib Makefile (use the
> >> individual module Makefiles instead), or
> >> . change the xml2 Makefile
> >>
> >
Patch applied by Magnus.
---
ITAGAKI Takahiro wrote:
> The attached is a patch to define O_DIRECT by ourselves on Windows,
> and to map O_DIRECT to FILE_FLAG_NO_BUFFERING.
>
> There will be a consistency in our support betw
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Writing lots of additional code simply to remove a parameter that
> *might* be mis-interpreted doesn't sound useful to me, especially when
> bugs may leak in that way. My take is that this is simple and useful
> *and* we have it now; other ways don't yet
NikhilS wrote:
Hi Trevor,
+
+ parent_index_info =
BuildIndexInfo(parent_index);
The above is not used anywhere else in the code and seems redundant.
Yep, pulled that out.
+
+ ereport(NOTICE,
On Fri, 2007-04-13 at 11:47 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Fri, 2007-04-13 at 10:36 -0400, Tom Lane wrote:
> >> That's what bothers me about this patch, too. It will be increasing
> >> the cost of writing WAL (more data -> more CRC computation and more
>
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2007-04-13 at 10:36 -0400, Tom Lane wrote:
>> That's what bothers me about this patch, too. It will be increasing
>> the cost of writing WAL (more data -> more CRC computation and more
>> I/O, not to mention more contention for the WAL locks) whi
On Fri, 2007-04-13 at 10:36 -0400, Tom Lane wrote:
> "Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> > But you also turn off the optimization that avoids writing regular
> > WAL records when the info is already contained in a full-page image
> > (increasing the uncompressed size of WAL).
Simon Riggs wrote:
> On Tue, 2007-04-10 at 20:46 +0900, ITAGAKI Takahiro wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> wrote:
> >
> > > > transaction_guarantee.v11.patch
> > > correct files attached
> >
> > This is a small fix to transaction_guarantee patch.
> > WAL writer needs PGSharedMemoryReA
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> But you also turn off the optimization that avoids writing regular
> WAL records when the info is already contained in a full-page image
> (increasing the uncompressed size of WAL).
> It was that part I questioned.
That's what bothers me a
On Tue, 2007-04-10 at 20:46 +0900, ITAGAKI Takahiro wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> wrote:
>
> > > transaction_guarantee.v11.patch
> > correct files attached
>
> This is a small fix to transaction_guarantee patch.
> WAL writer needs PGSharedMemoryReAttach() on EXEC_BACKEND platforms.
I've done some further looking aruond at this, and I've been unable to find
any references to disk systems with sector size > 8192 bytes (which is what
the alignment of the buffers per XLOG_BLCKSZ, at leastby default).
So I'll commit this fairly simple patch, and we'll revert it or add runtime
che
> > Yup, this is a good summary.
> >
> > You say you need to remove the optimization that avoids the logging
of
> > a new tuple because the full page image exists.
> > I think we must already have the info in WAL which tuple inside the
> > full page image is new (the one for which we avoided th
17 matches
Mail list logo