Paul van der Zwan <[EMAIL PROTECTED]> writes:
> On 25-apr-2006, at 16:46, Tom Lane wrote:
>> AFAICS, SHM_SHARE_MMU has no
>> guaranteed semantic effect anyway, it's just a performance hint; so
>> ignoring it on platforms that can't handle it is reasonable.
>>
> I disagree, I have no definite info
Hi,
I've investigated the problem further, and here are my findings. I believe
this will be enough to allow you to provide a permanent fix to this problem.
To recap: we get an unusual error message from Postgres when storing a lot
of data (hundreds of megabytes) on a machine that is running
On 25-apr-2006, at 9:08, Tom Lane wrote:
Paul van der Zwan <[EMAIL PROTECTED]> writes:
Maybe noone ever ran Postgres on Solaris on a VIA Epia system.
Maybe. What is a "VIA Epia system"?
VIA is a hardware manufacturer who make small, low power boards with
their own X86 compatible cpu
on
On 25-apr-2006, at 7:48, Tom Lane wrote:
"Paul van der Zwan" <[EMAIL PROTECTED]> writes:
Only systems with large pagesizes support ISM, so always defining
#define PG_SHMAT_FLAGS SHM_SHARE_MMU
in src/backend/port/sysv_shmem.c will cause all calls to shmat to
fail with
EINVA
Sure.
I should note that we're moving to Linux for our production servers so
our interest in the Windows port is waning (at least for the time
being). In particular, the stuck WAL segment rename problem has
occasionally been rather a pain in the neck.
As long as we still have Windows test server
Paul van der Zwan <[EMAIL PROTECTED]> writes:
> AFAIK getpagesizes() appeared in 2001 so that probably means it is
> missing in anything before Solaris 9.
We could handle this without relying on getpagesizes() by just trying
and falling back:
#ifdef SHM_SHARE_MMU
memAddress = shmat(shmi
Paul van der Zwan <[EMAIL PROTECTED]> writes:
> Maybe noone ever ran Postgres on Solaris on a VIA Epia system.
Maybe. What is a "VIA Epia system"?
Frankly, I'm afraid that your patch is likely to break way more systems
than it fixes. What is getpagesizes(), and is it guaranteed to exist on
*eve
