Andres Freund 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
>> http://pubs.opengroup.org/onlinepubs/009695299/func
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 wa
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 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
> >> wrote:
> >>>On 31.10.2013 16:43, Robert Haas wrote:
> There should be no
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
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
On Fri, Nov 01, 2013 at 12:27:31AM -0400, Robert Haas wrote:
> On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas
> 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
On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas
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. postgres -D data1
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 10:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund
>> 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 me
On 2013-10-31 10:29:17 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund
> > 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 me
Robert Haas writes:
> On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund 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?
>> Our main shared
On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund 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. There are many s
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 c
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 *other*
On Wed, Oct 30, 2013 at 9:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane 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 co
Robert Haas writes:
> On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane 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, IMO.
> Here's a short summary of w
On Wed, Oct 30, 2013 at 12:51 PM, Tom Lane wrote:
> Robert Haas 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 jus
On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane wrote:
> Andres Freund 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, w
Robert Haas 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 instead have the
> po
Robert Haas writes:
> On Wed, Oct 30, 2013 at 9:26 AM, Tom Lane 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?
> Good questions. I think that
On Wed, Oct 30, 2013 at 9:26 AM, Tom Lane wrote:
> Robert Haas 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 happeni
Andres Freund 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 addon segments du
On 2013-10-30 09:26:42 -0400, Tom Lane wrote:
> Robert Haas 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 happeni
Robert Haas 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 number looks like th
On Wed, Oct 30, 2013 at 8:47 AM, Andres Freund 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, Global/PostgreSQL.851401618. Now, th
On Wed, Oct 30, 2013 at 8:22 AM, Robert Haas 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
http://msdn.microsof
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 choo
On Tue, Oct 29, 2013 at 3: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 .
On Wed, Oct 30, 2013 at 1:22 AM, Amit Kapila wrote:
> On Wed, Oct 30, 2013 at 12:42 AM, 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
>> creati
On Wed, Oct 30, 2013 at 8:22 AM, Robert Haas wrote:
> On Wed, Oct 30, 2013 at 1:22 AM, Amit Kapila wrote:
>> On Wed, Oct 30, 2013 at 12:42 AM, Tom Lane wrote:
>>> The last two buildfarm runs on frogmouth have failed in initdb,
>>> like this:
>>>
>>> creating directory
>>> d:/mingw-bf/root/HEAD/
On Wed, Oct 30, 2013 at 12:42 AM, 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
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 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 def
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 dyn
34 matches
Mail list logo
