Newest version added:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
-
AFAIK, the only systems supported by Postgres that this patch won't
work on are NetBSD and OpenBSD.
The POSIX calls free the user from the SHMMAX and SHMALL limitations
of the SysV shared memory calls on platforms that support it. Since
this still takes one SysV segment, SHMMNI can still be
> If you have the need to ship a product with Postgres embedded in it and
> are unable to change kernel settings (like myself), this might be of use
> to you. I have tested all of the failure situations I could think of by
> various combinations of deleting lockfiles while in use, changing the
> P
In case you haven't had enough, here is another version of the code
to make Postgres use POSIX shared memory. Along with the issues that
have already been addressed, this version ensures that orphaned
backends are not in the database when restarting Postgres by using a
single 1 byte SysV se
Chris Marcellino <[EMAIL PROTECTED]> writes:
> Ignoring the case where backends are still alive in the database,
I grow weary of explaining this, but: that is EXACTLY the case you
cannot ignore.
regards, tom lane
---(end of broadcast)
I believe that all we need is the ID to be constant and unique while
the postmaster or its associated backends are running. If anything
from a given generation has the database open, it will remain
constant before any new process can connect to it successfully. Would
it be feasible to looku
On Tue, Feb 27, 2007 at 10:30:15AM +0100, Magnus Hagander wrote:
> > Does Windows have a method to get a unique ID number for a given data
> > directory, or a token file in that directory? It would need to be
> > constant while the database is open. Perhaps
> > GetFileInformationByHandle? It
The comment on that method vexes me:
"This value is useful only while the file is open by at least one
process. If no processes have it open, the index may change the next
time the file is opened."
I wonder how this applies to directories. I.e. is a directory open if
a file in it is open?
On Tue, Feb 27, 2007 at 01:09:46AM -0800, Chris Marcellino wrote:
> The Win32 version didn't materialize until very recently. The Win32
> calls are similar semantically to the POSIX ones, so it was somewhat
> straightforward.
>
> Plaintext is nice if you can fit it, since Windows permits you t
The Win32 version didn't materialize until very recently. The Win32
calls are similar semantically to the POSIX ones, so it was somewhat
straightforward.
Plaintext is nice if you can fit it, since Windows permits you to
have slashes and all sorts of other non-filename characters in them,
On Mon, Feb 26, 2007 at 09:00:09PM -0800, Chris Marcellino wrote:
>
> There is also a Windows version of this patch included, which can
> replace the current SysV-to-Win32 shared memory
> layer as it currently does not check for orphaned backends in the
> database. If this is used,
> src/back
On Feb 26, 2007, at 10:43 PM, Tom Lane wrote:
Chris Marcellino <[EMAIL PROTECTED]> writes:
The System V shared memory facilities provide a method to determine
who is attached to a shared memory segment.
This is used to prevent backends that were orphaned by crashed or
killed database processes
Chris Marcellino <[EMAIL PROTECTED]> writes:
> The System V shared memory facilities provide a method to determine
> who is attached to a shared memory segment.
> This is used to prevent backends that were orphaned by crashed or
> killed database processes from corrupting the data-
> base as it
Recapitulating and addressing some of the issues with my previous
attempt at this feature:
PostgreSQL currently uses the System V shared memory APIs to access
shared memory. On Mac OS X and other BSDs,
the default System V shared memory limits are often very low and
require adjustment for a
14 matches
Mail list logo