Philip Yarra <[EMAIL PROTECTED]> writes:
> I've just tried the latest CVS on Tru64 (OSF) and I'm getting a surprising=
> number of failures.
You seem to have some path problems: most of the errors look like
+ ERROR: could not access file "/regress.so": No such file or directory
or collateral da
Manfred Spraul <[EMAIL PROTECTED]> writes:
> One problem for WAL is that O_DIRECT would disable the write cache -
> each operation would block until the data arrived on disk, and that might block
> other backends that try to access WALWriteLock.
> Perhaps a dedicated backend that does the writeba
I've just tried the latest CVS on Tru64 (OSF) and I'm getting a surprising
number of failures. I've tested using gcc 2.95 and compaq's cc (both the same
number of failures, can provide regression.* and make.out from /bin/cc run
if required). The attached results are from gcc, which appears to b
--On Wednesday, October 29, 2003 15:49:53 -0500 Tom Lane
<[EMAIL PROTECTED]> wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
--On Wednesday, October 29, 2003 15:26:39 -0500 Tom Lane=20
<[EMAIL PROTECTED]> wrote:
[snip]
Is this a bug, or is it correct-per-spec behavior? It's surely likely
to
Larry Rosenman <[EMAIL PROTECTED]> writes:
> --On Wednesday, October 29, 2003 15:26:39 -0500 Tom Lane=20
> <[EMAIL PROTECTED]> wrote:
> [snip]
>> Is this a bug, or is it correct-per-spec behavior? It's surely likely
>> to confuse people. I wonder whether superusers shouldn't be allowed to
>> revo
I have added my first release note detail item. I used to
add a description to the first release note item. You can see it
rendered here:
http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-DEVEL
I plan to go through the release notes and add more. If we decide on a
Tom Lane wrote:
Not for WAL --- we never read the WAL at all in normal operation. (If
it works for writes, then we would want to use it for writing WAL, but
that's not apparent from what Christopher quoted.)
At least under Linux, it works for writes. Oracle uses O_DIRECT to
access (both read and
Doug McNaught <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> A new DIRECTIO kernel option enables support for read operations that
>> bypass the buffer cache and put data directly into a userland
>> buffer. This feature requires that the O_DIRECT flag is set on
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> I would think the biggest savings could come from using directIO for
> vacuuming, so it doesn't cause the kernel to flush buffers.
>
> Would that be just as hard to implement?
Two words: "cache coherency".
-Doug
---(end o
On 29 Oct 2003, Doug McNaught wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>
> > FreeBSD 4.9 was released today. In the release notes was:
> >
> > 2.2.6 File Systems
> >
> > A new DIRECTIO kernel option enables support for read operations that
> > bypass the buffer cache and pu
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> FreeBSD 4.9 was released today. In the release notes was:
>
> 2.2.6 File Systems
>
> A new DIRECTIO kernel option enables support for read operations that
> bypass the buffer cache and put data directly into a userland
> buffer. This feature
FreeBSD 4.9 was released today. In the release notes was:
2.2.6 File Systems
A new DIRECTIO kernel option enables support for read operations that
bypass the buffer cache and put data directly into a userland buffer.
This feature requires that the O_DIRECT flag is set on the file
descriptor a
On Wed, 2003-10-29 at 06:54, Thiago Fernandes Moesch wrote:
>I have a comment on something like that to: Why - when creating a view
> using explicit * on select - postgresql reads all the fields in the query
> and especify them one by one on the view definition? Developers always have
> to chec
Ports list updated:
http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html
---
Alessio Bragadini wrote:
> On Fri, 2003-10-24 at 18:37, Bruce Momjian wrote:
>
> > It is time for people to report th
I have a comment on something like that to: Why - when creating a view
using explicit * on select - postgresql reads all the fields in the query
and especify them one by one on the view definition? Developers always have
to check every view after changing a table definition to be certain it do
On Fri, 2003-10-24 at 18:37, Bruce Momjian wrote:
> It is time for people to report their port testing. Please test against
> current CVS or beta5 and report your 'uname -a'.
Sorry for the delay. All regression tests passed on Alpha Tru64/
Digital Unix version 4.0g using Digital CC.
OSF1 emily
16 matches
Mail list logo
