> > 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
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
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.
"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
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
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" <[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 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
>
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,
"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
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
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
> >>
> >
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
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
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
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
17 matches
Mail list logo
