Re: [HACKERS] 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED

[Rainer Bauer]

"Matthew T. O'Connor" wrote:

>Tom Lane wrote:
>> 
>> ROTFL ... so to translate: "If your program crashes, please release
>> locks before crashing."
>
>Obviously that wasn't the intent of the above, but I guess it is the net 
>effect.  Either way, I don't think it's a huge problem, it just means 
>that PG may not be able to restart for a few seconds until the OS has 
>time to clean-up the locks.

I don't think so. I am using DevStudio 2005 here and from time to time the
debugger crashes so that I have to kill the program via the task manager.
Afterwards it's not possible to load the crashed project again in a newly
started DevStudio session, because some project files are still locked
exclusively. The only action that helps is rebooting windows.

Now, I don't know whether DevStudio is using LockFileEx() but somehow this
sounds familiar.

Rainer

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Overhauling GUCS

[Rainer Bauer]

"Pavel Stehule" wrote:

>2008/6/4 David E. Wheeler <[EMAIL PROTECTED]>:
>>
>> Exactly. The issue is that application developers, who are not DBAs, have no
>> idea how to tune PostgreSQL, and postgresql.conf is daunting and confusing.
>> So they use a different database that's "faster".
>
>do you thing, so any better config can help? It's not possible.  And
>you can't tune database without well knowledge of applications that
>use database. Any automatic tools are joy for child. But some default
>PostgreSQL parameters are not optimal.

I think it would be an enourmous help for beginners if they had a "simple"
tuning tool which would tell them which values where altered (and possibly
why) from Postgres' default settings based on some basic information.
Like:
- machine hardware (disk layout, OS, installed memory, etc.)
- application usage (no. of clients, read/write activity, etc)

I don't think that such a tool could tune the database perfectly (or even very
good), but at least people new to Postgres would know where to start looking
for tuning it to their needs.

And I am not speaking about end users running an application that uses
Postgres. I talk about application developers like me that port their
application to use Postgres.

Rainer

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Execution-time-sensitive timestamp regression tests

[Rainer Bauer]

Magnus Hagander wrote:

>For the record, what we were talking about was snapshotting the time at
>backend start and then use QueryPerformanceCounter() to see what
>happened and do some calculation.

Although this might not be such a big issue for the regression tests:
Be aware that the reliability of QueryPerformanceCounter() depends on the
hardware: 

I used it in Munnin, but there were too many customer machines affected by
this bug so that I had to abandom it. This was a few years ago, but I'm not
sure whether the function can be trusted today (see for example this
performance problem ).

Rainer

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Windows shared_buffers limitations

[Rainer Bauer]

Greg Smith wrote:

>Was working on some documentation today and I realized that I've taken for 
>granted the lore about not using large values for shared_buffers in 
>Windows without ever understanding why.  Can someone explain what the 
>underlying mechanism that causes that limitation is?  From poking the 
>archives I got the impression it was some page mapping issue but details 
>are elusive.

All I can offer is Magnus' explanation: "All evidence I've seen points to that
you should have shared_buffers as *small* as possible on win32, because memory
access there is slow. And leave more of the caching up to the OS."


Heikki said something similar here:


Rainer

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Problem with ControlFileData structure being ABI dependent

[Rainer Bauer]

Gregory Stark wrote:

>The looming problem is that you won't be able to use any libraries or 3rd
>party tools which use time_t in their interface unless you build with the same
>size time_t as they do. I don't know how're expected to find out that a .so
>you're handed has a different size time_t.

But that problem is already present if you try to link your VS2005 code to the
mingw build, isn't it? Respectively you will run into this problem when
upgrading to the MSVCC  build version 8.3.

Anyway, my original message was only intended as a comment, since I have no
idea whether time_t is only used internally or whether it's publically
exposed.

Rainer

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Problem with ControlFileData structure being ABI dependent

[Rainer Bauer]

Gregory Stark wrote:

>This is because of (at least) two changes in the ABI between the runtimes used
>by mingw and VC++.
> 1) Enums are apparently 8 bytes on VC++ but 4 bytes on mingw

They are 4 bytes here on my 32 bit WinXP machine with VS2005SP1.

> 2) time_t is 8 bytes on VC++ but 4 bytes on mingw.

Not sure whether an 8 byte time_t is now required by postgres. But you can get
the old behaviour by defining _USE_32BIT_TIME_T.

Rainer

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)

[Rainer Bauer]

Markus Schiltknecht wrote:

>[2]: Terms and Definitions of Database Replication
>http://www.postgres-r.org/documentation/terms

Markus, the links in the left side menu are broken on the "about" and
"documentation" page. They point to 
instead of , etc.

Rainer

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster