From: Magnus Hagander [EMAIL PROTECTED]
ITAGAKI Takahiro wrote:
Do you mean there are drives that have larger sector size than 8kB?
We've already put the xlog buffer along the alignment of
ALIGNOF_XLOG_BUFFER (typically 8192 bytes).
But if there are such drives, using FILE_FLAG_NO_BUFFERING
Hello, Magnus-san, Itagaki-san
From: Magnus Hagander [EMAIL PROTECTED]
I think many people can benefit from Itagaki-san's proposal, and
NO_BUFFERING should be default. Isn't it very rare that disks with
sector size larger than 8KB are used?
Definitly very rare.
Providing a way (such as
From: Bruce Momjian [EMAIL PROTECTED]
Tom Lane wrote:
Basically this whole idea is misconceived. Just print the number
and
have done.
And how do people interpret that number?
I understand that people Bruce-san is saying means PostgreSQL
developers, not ordinary users.
When ordinary users
they?
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
To: Takayuki Tsunakawa [EMAIL PROTECTED]
Cc: Tom Lane [EMAIL PROTECTED]; Alvaro Herrera
[EMAIL PROTECTED]; Magnus Hagander [EMAIL PROTECTED];
ITAGAKI Takahiro [EMAIL PROTECTED];
PostgreSQL-patches pgsql-patches@postgresql.org
Sent
From: Bruce Momjian [EMAIL PROTECTED]
OK, I have tested on MinGW and found I can use FormatMessage() to
print
a description for all ERROR* system() failures, rather than print a
hex
value. This removes the need for a URL or lookup of hex values.
Attached and applied.
Excuse me if I'm
for a description of the hex value.
When I search for /include/ntstatus.h, I get the Wine page first, so
hopefully we can mark this item as completed.
Thank you, Bruce-san. I agree.
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
To: Takayuki Tsunakawa [EMAIL PROTECTED]
Cc: PostgreSQL
From: Magnus Hagander [EMAIL PROTECTED]
Are you entirely sure that ntstatus.h is where to look? Because per
whatever docs I've found, that contains device driver errors and
*not*
exception codes.
Yes, what you are pointing out is correct. winbase.h and winnt.h
should be consulted instead of
From: Chris Marcellino [EMAIL PROTECTED]
To this end, I have ported the svsv_shmem.c layer to use the POSIX
calls (which are some ways more robust w.r.t reducing collision by
using strings as shared memory id's, instead of ints).
I hope your work will be accepted. Setting IPC parameters is
ep
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Then, how about semaphores? When I just do configure, PostgreSQL
seems to use SysV semaphores. But POSIX semaphore implementation
is
prepared in src/backend/port/posix_sema.c. Why isn't it used by
default? Does it have any problem?
Either way, Essentially, no one is running out of
From: Tom Lane [EMAIL PROTECTED]
Probably not. The issues about Darwin's POSIX-sema implementation
are (a) eating backend open-file slots, which won't matter when a
backend only touches a few different tables as pgbench does; and
(b) extra process-launch overhead, which won't matter to
Hello,
Could anyone tell me how to use 2GB of shared buffers on Windows? I'm
sorry for attaching large text files and for sending this mail to this
ML.
When I try to start PostgreSQL 8.2.1 on Windows 2003 Server with
shared_buffers=1024MB, I get the following error messages in the Event
Log
Hello, long time no see.
I'm sorry to interrupt your discussion. I'm afraid the code is getting
more complicated to continue to use fsync(). Though I don't intend to
say the current approach is wrong, could anyone evaluate O_SYNC
approach again that commercial databases use and tell me if and why
From: Greg Smith [EMAIL PROTECTED]
If you compare how Oracle handles their writes and checkpoints to
the
Postgres code, it's obvious they have a different architecture that
enables them to support sync writing usefully. I'd recommend the
Database
Writer Process section of
14 matches
Mail list logo
