Charlie Savage wrote:
Just wanted to close off this thread.
Previously I reported that building 8.3.4 with MingW on Windows resulted
in an initdb executable that couldn't create new databases due to
security restrictions in creating global file mappings in Vista.
I'm happy to say that the
Just wanted to close off this thread.
Previously I reported that building 8.3.4 with MingW on Windows resulted
in an initdb executable that couldn't create new databases due to
security restrictions in creating global file mappings in Vista.
I'm happy to say that the problem seems fixed in
Andrew Dunstan wrote:
Has anyone considered not using a file lock on windows? CreateMutex
might do the trick if provided a mutex name, making it global rather
than process bound. OpenMutex can be used to test if the mutex exists
or if it is currently locked. I guess it would stay locked.
Andrew Chernow wrote:
Andrew Dunstan wrote:
Has anyone considered not using a file lock on windows? CreateMutex
might do the trick if provided a mutex name, making it global rather
than process bound. OpenMutex can be used to test if the mutex
exists or if it is currently locked. I
Andrew Dunstan wrote:
Andrew Chernow wrote:
Andrew Dunstan wrote:
Has anyone considered not using a file lock on windows? CreateMutex
might do the trick if provided a mutex name, making it global rather
than process bound. OpenMutex can be used to test if the mutex
exists or if it is
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
Rainer Bauer wrote:
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
Andrew Chernow wrote:
Rainer Bauer wrote:
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
The user running initdb (or the postmaster) needs
SeCreateGlobalPrivilege - which is something we cannot really start
Why not ? Doesn't the pg installer already tweak the permissions of the
installation user. On XP you can connect to session 0, so that is an
alternative on XP.
telling
Dave Page wrote:
The reason it should be in the Global namespace is that shmem is one part of
detecting an existing postmaster. Especially in situations where the db is
started
by hand, the protection against duplicate startup is important.
Yeah, as Magnus reminded me.
IMNSHO we
Andrew Dunstan wrote:
Dave Page wrote:
The reason it should be in the Global namespace is that shmem is one
part of
detecting an existing postmaster. Especially in situations where the
db is started
by hand, the protection against duplicate startup is important.
Yeah, as Magnus
Andrew Dunstan wrote:
I have verified that it does indeed work. Underneath the hood it uses
the native call LockFileEx() see win32io.c in Perl source. I suggest we
should switch from this flaky use of Global namespace to having the
postmaster acquire an explicit lock on a file in the
Andrew Dunstan [EMAIL PROTECTED] writes:
I have verified that it does indeed work. Underneath the hood it uses
the native call LockFileEx() see win32io.c in Perl source. I suggest we
should switch from this flaky use of Global namespace to having the
postmaster acquire an explicit lock on a
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I have verified that it does indeed work. Underneath the hood it uses
the native call LockFileEx() see win32io.c in Perl source. I suggest we
should switch from this flaky use of Global namespace to having the
postmaster acquire an explicit
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have verified that it does indeed work. Underneath the hood it uses
the native call LockFileEx() see win32io.c in Perl source. I suggest we
should switch from this flaky use of Global namespace to having the
postmaster acquire an
Tom Lane wrote:
Does fork/exec preserve lock ownership on Windows?
Not to my knowledge. On windows, there is only CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx). That doesn't
resemble the behavior of fork or exec at all. Basically, there is no
fork, windows
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
That can only be a solution if postmaster child processes will inherit
the lock.
I don't think so, no. But we could have the children explicitly acquire
a shared lock, so if the postmaster at startup tried to grab an
exclusive lock
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Does fork/exec preserve lock ownership on Windows?
Not to my knowledge. On windows, there is only CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx). That doesn't
resemble the behavior of fork or exec at all.
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Does fork/exec preserve lock ownership on Windows?
Not to my knowledge. On windows, there is only CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx). That doesn't
resemble the behavior of fork
Magnus Hagander wrote:
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Does fork/exec preserve lock ownership on Windows?
Not to my knowledge. On windows, there is only CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx). That doesn't
resemble
Andrew Chernow [EMAIL PROTECTED] writes:
Be careful. From LockFileEx docs:
However, the time it takes for the operating system to unlock these
locks depends upon available system resources. Therefore, it is
recommended that your process explicitly unlock all files it has locked
when it
Tom Lane wrote:
Hmm. Now that you mention it, didn't we solve a similar problem by
exploiting the behavior where CreateProcess creates a process but
doesn't start it running? I'm envisioning
* Create child process in suspended state
* Assign it ownership of a lock (can we do
On Wed, Oct 15, 2008 at 10:49 AM, Zeugswetter Andreas OSB sIT
[EMAIL PROTECTED] wrote:
The user running initdb (or the postmaster) needs
SeCreateGlobalPrivilege - which is something we cannot really start
Why not ? Doesn't the pg installer already tweak the permissions of the
installation
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Be careful. From LockFileEx docs:
However, the time it takes for the operating system to unlock these
locks depends upon available system resources. Therefore, it is
recommended that your process explicitly unlock all files it has
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.
Seconds?
Try log off and log on again, and if that
Andrew Chernow wrote:
Tom Lane wrote:
Hmm. Now that you mention it, didn't we solve a similar problem by
exploiting the behavior where CreateProcess creates a process but
doesn't start it running? I'm envisioning
* Create child process in suspended state
* Assign it ownership of a
On Mon, Oct 13, 2008 at 10:38 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
I am getting this error on XP Pro. The buildfarm members run happily from
the scheduler, but when run by hand from the command line they fail. This is
true of both MinGW and MSVC.
It's on my list to discuss it with
It's on my list to discuss it with Magnus when we meet in Italy
tomorrow. The simple fix is to back out the change that broke it,
which leaves us in our previous broken-but-less-severely state (which
is what we did for the binary packages).
If you mean reverting the patch that Mangus mentioned,
On Tue, Oct 14, 2008 at 2:33 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Dave Page wrote:
Well - building your own Postgres 8.3 on Windows using MingW appears
broken.
Not sure how many people fall into that category, but its seems like a
fairly major issue.
Very few people build their
On Tue, Oct 14, 2008 at 3:31 PM, Robert Haas [EMAIL PROTECTED] wrote:
The user running initdb (or the postmaster) needs
SeCreateGlobalPrivilege - which is something we cannot really start
telling people they must have. My view is that we revert the change
(well, replace it with something that
Robert Haas [EMAIL PROTECTED] writes:
The user running initdb (or the postmaster) needs
SeCreateGlobalPrivilege - which is something we cannot really start
telling people they must have. My view is that we revert the change
(well, replace it with something that looks less like a broken attempt
Dave Page wrote:
On Tue, Oct 14, 2008 at 2:33 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Dave Page wrote:
Well - building your own Postgres 8.3 on Windows using MingW appears
broken.
Not sure how many people fall into that category, but its seems like a
fairly major issue.
Very few
Tom Lane wrote:
Robert Haas [EMAIL PROTECTED] writes:
The user running initdb (or the postmaster) needs
SeCreateGlobalPrivilege - which is something we cannot really start
telling people they must have. My view is that we revert the change
(well, replace it with something that looks less like
On Tue, Oct 14, 2008 at 4:19 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Not quite. The reason it's in the global namespace is to provide an
interlock preventing the starting of a postmaster in two different
sessions at the same time against the same data directory. We need to
figure out
I'm not so sure that non-console terminal service sessions should be
categorized as pretty rare.
I use them routinely.
For installing and running Postgres? Note that we're not talking about
running clients apps here, but the server itself.
Sure, why not? I mean, I've come across
On Tue, Oct 14, 2008 at 5:12 PM, Robert Haas [EMAIL PROTECTED] wrote:
I'm not so sure that non-console terminal service sessions should be
categorized as pretty rare.
I use them routinely.
For installing and running Postgres? Note that we're not talking about
running clients apps here, but
Dave Page wrote:
Well - building your own Postgres 8.3 on Windows using MingW appears broken.
Not sure how many people fall into that category, but its seems like a
fairly major issue.
Very few people build their own Postgres on Windows, because it's not
exactly straightforward to do
On Tue, Oct 14, 2008 at 9:43 AM, Charlie Savage [EMAIL PROTECTED] wrote:
It's on my list to discuss it with Magnus when we meet in Italy
tomorrow. The simple fix is to back out the change that broke it,
which leaves us in our previous broken-but-less-severely state (which
is what we did for
On Tue, Oct 14, 2008 at 12:43 PM, Charlie Savage [EMAIL PROTECTED] wrote:
It's on my list to discuss it with Magnus when we meet in Italy
tomorrow. The simple fix is to back out the change that broke it,
which leaves us in our previous broken-but-less-severely state (which
is what we did for
The user running initdb (or the postmaster) needs
SeCreateGlobalPrivilege - which is something we cannot really start
telling people they must have. My view is that we revert the change
(well, replace it with something that looks less like a broken attempt
to use the global namespace) and
Magnus Hagander wrote:
Second, once I've successfully built and installed postgres, I run into
a bigger problem. When using initdb, I get this error:
creating template1 database in c:/Data/postgres30/base/1 ... FATAL:
could not create shared memory segment: 5
DETAIL: Failed system call was
Charlie Savage wrote:
I'm trying to upgrade my copy of postgresql from 8.2.x to 8.3.4 on a
Windows Vista SP1 laptop. I build postgres using mingw/msys and have had
no issues with 8.1.x and 8.2.x. However, with 8.3.4 I run into problems.
First, building fails:
Have you done anything special to your mingw install?
The only thing different is that I upgraded to the latest mingw and msys
packages a couple of weeks ago. The other thing I can think of is that
I installed openssl and related packages (the official ones from the
msys project). Would
43 matches
Mail list logo
