On 01.11.2013 18:22, Noah Misch wrote:
On Fri, Nov 01, 2013 at 12:27:31AM -0400, Robert Haas wrote:
On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 31.10.2013 16:43, Robert Haas wrote:
There should be no cases where the main shared memory
segment gets
On 2013-11-04 10:27:47 +0200, Heikki Linnakangas wrote:
On 01.11.2013 18:22, Noah Misch wrote:
On Fri, Nov 01, 2013 at 12:27:31AM -0400, Robert Haas wrote:
On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 31.10.2013 16:43, Robert Haas wrote:
There should
On 04.11.2013 11:55, Andres Freund wrote:
On 2013-11-04 10:27:47 +0200, Heikki Linnakangas wrote:
Hmm, here's another idea:
Postmaster creates the POSIX shared memory object at startup, by calling
shm_open(), and immediately calls shm_unlink on it. That way, once all the
processes have exited,
On 2013-11-04 13:13:27 +0200, Heikki Linnakangas wrote:
On 04.11.2013 11:55, Andres Freund wrote:
On 2013-11-04 10:27:47 +0200, Heikki Linnakangas wrote:
Postmaster creates the POSIX shared memory object at startup, by calling
shm_open(), and immediately calls shm_unlink on it. That way, once
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-04 13:13:27 +0200, Heikki Linnakangas wrote:
On 04.11.2013 11:55, Andres Freund wrote:
Also, I don't think it's portable across platforms to access segments
that already have been unlinked.
See
On Fri, Nov 01, 2013 at 12:27:31AM -0400, Robert Haas wrote:
On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 31.10.2013 16:43, Robert Haas wrote:
There should be no cases where the main shared memory
segment gets cleaned up and the dynamic shared
On 30.10.2013 18:52, Robert Haas wrote:
Here's a short summary of what I posted back in August: at system
startup time, the postmaster creates one dynamic shared segment,
called the control segment. That segment sticks around for the
lifetime of the server and records the identity of any
Hi,
On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote:
Wait, that sounds horrible. If you kill -9 the server, and then rm -rf
$PGDATA, the shared memory segment is leaked until next reboot? I find that
unacceptable. There are many scenarios where you never restart postmaster
after a
On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote:
Wait, that sounds horrible. If you kill -9 the server, and then rm -rf
$PGDATA, the shared memory segment is leaked until next reboot? I find that
unacceptable.
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote:
Wait, that sounds horrible. If you kill -9 the server, and then rm -rf
$PGDATA, the shared memory segment is leaked
On 2013-10-31 10:29:17 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote:
Wait, that sounds horrible. If you kill -9 the server, and then rm
On Thu, Oct 31, 2013 at 10:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote:
Wait, that sounds horrible. If you kill -9 the
On 31.10.2013 16:43, Robert Haas wrote:
Let me say this again: the dynamic shared memory code *does* clean up
after itself. If you kill -9 the postmaster and all of its children,
you'll orphan the main shared memory segment and any dynamic shared
memory segments that exist. There is nothing we
On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 31.10.2013 16:43, Robert Haas wrote:
There should be no cases where the main shared memory
segment gets cleaned up and the dynamic shared memory segments do not.
1. initdb -D data1
2. initdb -D data2
3.
On Wed, Oct 30, 2013 at 8:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 30, 2013 at 1:22 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Oct 30, 2013 at 12:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The last two buildfarm runs on frogmouth have failed in initdb,
like this:
On Wed, Oct 30, 2013 at 1:22 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Oct 30, 2013 at 12:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The last two buildfarm runs on frogmouth have failed in initdb,
like this:
creating directory
On Tue, Oct 29, 2013 at 3:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The last two buildfarm runs on frogmouth have failed in initdb,
like this:
creating directory
d:/mingw-bf/root/HEAD/pgsql.2492/src/test/regress/./tmp_check/data ... ok
creating subdirectories ... ok
selecting default
On 2013-10-30 08:45:03 -0400, Robert Haas wrote:
If I'm reading this correctly, the last three runs on frogmouth have
all failed, and all of them have failed with a complaint about,
specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
be happening, because the code to choose
On Wed, Oct 30, 2013 at 8:22 AM, Robert Haas robertmh...@gmail.com wrote:
I find it hard to believe this is the right fix. I know we have
similar code in win32_shmem.c, but surely if size is a 32-bit unsigned
quantity then size 0 is simply 0 anyway.
Gosh, I stand corrected. According to
On Wed, Oct 30, 2013 at 8:47 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-30 08:45:03 -0400, Robert Haas wrote:
If I'm reading this correctly, the last three runs on frogmouth have
all failed, and all of them have failed with a complaint about,
specifically,
Robert Haas robertmh...@gmail.com writes:
If I'm reading this correctly, the last three runs on frogmouth have
all failed, and all of them have failed with a complaint about,
specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
be happening, because the code to choose that
On 2013-10-30 09:26:42 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
If I'm reading this correctly, the last three runs on frogmouth have
all failed, and all of them have failed with a complaint about,
specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
Andres Freund and...@2ndquadrant.com writes:
On 2013-10-30 09:26:42 -0400, Tom Lane wrote:
Isn't this complaining about the main shm segment, not a DSM extension?
Don't think so, that has a : in the name.
If it *isn't* about the main memory segment, what the hell are we doing
creating random
On Wed, Oct 30, 2013 at 9:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If I'm reading this correctly, the last three runs on frogmouth have
all failed, and all of them have failed with a complaint about,
specifically, Global/PostgreSQL.851401618. Now,
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 30, 2013 at 9:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, why is the error not enough space, rather than something about
a collision? And if this is the explanation, why didn't the previous
runs probing for allowable shmem size fail?
Robert Haas robertmh...@gmail.com writes:
Yeah, I think that's probably what it is. There's PostmasterRandom()
to initialize the random-number generator on first use, but that
doesn't help if some other module calls random(). I wonder if we
ought to just get rid of PostmasterRandom() and
On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-10-30 09:26:42 -0400, Tom Lane wrote:
Isn't this complaining about the main shm segment, not a DSM extension?
Don't think so, that has a : in the name.
If it *isn't*
On Wed, Oct 30, 2013 at 12:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah, I think that's probably what it is. There's PostmasterRandom()
to initialize the random-number generator on first use, but that
doesn't help if some other module calls
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If it *isn't* about the main memory segment, what the hell are we doing
creating random addon segments during bootstrap? None of the DSM code
should even get control at this point,
On Wed, Oct 30, 2013 at 9:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If it *isn't* about the main memory segment, what the hell are we doing
creating random addon segments during
The last two buildfarm runs on frogmouth have failed in initdb,
like this:
creating directory
d:/mingw-bf/root/HEAD/pgsql.2492/src/test/regress/./tmp_check/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting
On 10/29/2013 03:12 PM, Tom Lane wrote:
The last two buildfarm runs on frogmouth have failed in initdb,
like this:
creating directory
d:/mingw-bf/root/HEAD/pgsql.2492/src/test/regress/./tmp_check/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting
On 10/29/2013 03:47 PM, Andrew Dunstan wrote:
On 10/29/2013 03:12 PM, Tom Lane wrote:
It may not be
unrelated that this machine was happy before commit d2aecae went in.
I'll try a run with that reverted just to see if that's it.
This is a 32 bit compiler on a 32 bit (virtual) machine,
On Wed, Oct 30, 2013 at 12:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The last two buildfarm runs on frogmouth have failed in initdb,
like this:
creating directory
d:/mingw-bf/root/HEAD/pgsql.2492/src/test/regress/./tmp_check/data ... ok
creating subdirectories ... ok
selecting default
34 matches
Mail list logo
