[GRASS-user] how to resolve initdb
Pawan Joshi
josh_0882 at yahoo.com
Tue May 1 01:04:06 EDT 2007
Hello !!
I am using cygwin 1.5.24 with postgres 8.0.7.
when i n initializing the data directory i m having following problem
$ /usr/sbin/initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user "pawan".
This user must also own the server process.
The database cluster will be initialized with locale C.
modifica dei permessi sulla directory esistente /usr/local/pgsql/data ... ok
creazione directory /usr/local/pgsql/data/global ... ok
creazione directory /usr/local/pgsql/data/pg_xlog ... ok
creazione directory /usr/local/pgsql/data/pg_xlog/archive_status ... ok
creazione directory /usr/local/pgsql/data/pg_clog ... ok
creazione directory /usr/local/pgsql/data/pg_subtrans ... ok
creazione directory /usr/local/pgsql/data/base ... ok
creazione directory /usr/local/pgsql/data/base/1 ... ok
creazione directory /usr/local/pgsql/data/pg_tblspc ... ok
selecting default max_connections ... sh: line 1: 3576 Bad system call
"/usr/sbin/postgres.exe" -boot -x0 -F -c shared_buffers=500 -c max_connections=1
00 template1 < "/dev/null" > "/dev/null" 2>&1
sh: line 1: 3796 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=250 -c max_connections=50 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 2580 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=200 -c max_connections=40 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 3092 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=150 -c max_connections=30 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 1028 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=100 -c max_connections=20 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 1616 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=50 -c max_connections=10 template1 < "/dev/null" > "/dev/null"
2>&1
10
selecting default shared_buffers ... sh: line 1: 1416 Bad system call "
/usr/sbin/postgres.exe" -boot -x0 -F -c shared_buffers=1000 -c max_connections=1
0 template1 < "/dev/null" > "/dev/null" 2>&1
sh: line 1: 2492 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=900 -c max_connections=10 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 612 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=800 -c max_connections=10 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 1756 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=700 -c max_connections=10 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 3656 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=600 -c max_connections=10 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 2156 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=500 -c max_connections=10 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 2084 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=400 -c max_connections=10 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 1572 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=300 -c max_connections=10 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 2352 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=200 -c max_connections=10 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 3664 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=100 -c max_connections=10 template1 < "/dev/null" > "/dev/null
" 2>&1
sh: line 1: 424 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F
-c shared_buffers=50 -c max_connections=10 template1 < "/dev/null" > "/dev/null"
2>&1
50
child process is terminated by signal 12
initdb: removing data directory "/usr/local/pgsql/data"
I have down the following before initdb command
1. set CYGWIN=server
2. /usr/sbin/cygserver.exe &
and cygrunsrv is not required anymore for 8.0.x versions.
Thanks,
Pawan
grassuser-request at grass.itc.it wrote: Send grassuser mailing list submissions to
grassuser at grass.itc.it
To subscribe or unsubscribe via the World Wide Web, visit
http://grass.itc.it/mailman/listinfo/grassuser
or, via email, send a message with subject or body 'help' to
grassuser-request at grass.itc.it
You can reach the person managing the list at
grassuser-owner at grass.itc.it
When replying, please edit your Subject line so it is more specific
than "Re: Contents of grassuser digest..."
Today's Topics:
1. Benchmarking Grass 4.3, 5.4, 6.0, 6.2 raster commands
(Roy Sanderson)
2. Re: Problem with slope modeling . (Dylan Beaudette)
3. Re: Problem with slope modeling . (Maciej Sieczka)
4. Re: Benchmarking Grass 4.3, 5.4, 6.0, 6.2 raster commands
(Glynn Clements)
5. Re: [GRASS-dev] Re: [GRASS-user] Benchmarking Grass 4.3, 5.4,
6.0, 6.2 raster commands (Helena Mitasova)
6. Re: Problem with slope modeling . (Dylan Beaudette)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Apr 2007 15:28:12 +0000
From: Roy Sanderson
Subject: [GRASS-user] Benchmarking Grass 4.3, 5.4, 6.0, 6.2 raster
commands
To: grassuser at grass.itc.it
Message-ID: <3.0.3.32.20070430152812.009de6b0 at popin.ncl.ac.uk>
Content-Type: text/plain; charset="us-ascii"
Hello Everyone
I've been trying to persuade our users to stop working with Grass 4.3 and
Grass 5.4 for some time now, and as I have to upgrade the OS on our
applications server have told them that they now have no choice.
However, a couple of users stated that they preferred to use Grass 4.3 as
it was faster, and for large tasks, more stable than the newer versions. I
checked this on a map of 52,000 rows by 28,000 columns and commands like
r.mapcalc, r.clump, r.volume operated about 10x faster in Grass 4.3 than
the more recent versions.
This might simply arise from the age of the applications server OS (still
running RH7.3), or because I've mis-configured the newer versions of Grass.
For example, I did not compile Grass 5 or 6 with large-file support
enabled, although the file sizes are only around 180Mb, but the speedy
performance of 4.3 vs 5.4, 6.0 and 6.2.1 surprised me. Perhaps there's an
additional overhead associated with the introduction of nulls and
floating-points, which were major changes from 4.3 to 5.4. However, the
performance difference is still present when working with integer maps. As
I haven't benchmarked versions, and also because personally I only work
with Grass version 6, I hadn't spotted the differences until now.
Has anyone else noticed this issue?
Many thanks
Roy
----------------------------------------------------------------------------
-------
Roy Sanderson
Institute for Research on Environment and Sustainability
Devonshire Building
University of Newcastle
Newcastle upon Tyne
NE1 7RU
United Kingdom
Tel: +44 191 246 4835
Fax: +44 191 246 4999
http://www.ncl.ac.uk/environment/
r.a.sanderson at newcastle.ac.uk
----------------------------------------------------------------------------
------------------------------
Message: 2
Date: Mon, 30 Apr 2007 09:03:47 -0700
From: Dylan Beaudette
Subject: Re: [GRASS-user] Problem with slope modeling .
To: grassuser at grass.itc.it
Message-ID: <200704300903.47190.dylan.beaudette at gmail.com>
Content-Type: text/plain; charset="utf-8"
On Monday 30 April 2007 06:01, Radomir wrote:
> Dnia 26-03-2007, pon o godzinie 20:30 +1200, Hamish napisał(a):
> > > Radomir wrote:
> > > > I'm preparing the slope and elevation map from digitised isolines.
> > > > I'm using v.surf.rst to do that with the following options:
> > > >
> > > > v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"
> > > > dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"
> > > > maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300
> > > >
> > > > The screenshot from small part of resulting map is here:
> > > > http://mort.no-ip.org/screen.png
> > > >
> > > >
> > > > On this screen you can see the valley in the center. I expect that
> > > > the slope between two isolines on the bottom of the valley will be
> > > > similar. But it is changing and gives an effect of "wave" between
> > > > isolines.
> >
> > Mars wrote:
> > > I presume the Isolines are representative of Elevation.
> >
> > and the displayed raster, legend, and profile show the slope.
> > it might help to show a profile using the elevation map. (it is hard to
> > tell if the slope stays monotonically increasing in your profile as
> > slope will always be positive)
> >
> >
> >
> > profiler notes:
> > - y-scale is ranged to max/min of map, not max/min of profile?
> > ($elevrange from r.univar instead of r.profile in gis.m/profile.tcl)
> > Not sure which is best. Both ways have some merit.
> >
> > - in your screenshot the axes tick labels are not formatted cleanly.
> > I've just prettified those in CVS, please test.
> >
> > - BUG: if profile ends outside of the raster map off in NULL-land,
> > the totaldistance calculation is calculated to the end of the arrows,
> > but the end of real data in the plot is stretched to the far right end
> > regardless. e.g.: Zoom out so your raster is a postage stamp sized box
> > in the middle, then make some profiles from map canvas corner to
> > corner. The start of the data is positioned ok. Also it should break
> > the plot at NULL data, not draw a line beween the last known good data
> > either side of the NULLs.
> >
> > - it would be possible to add a title like "Profile for $mapname" at the
> > top of the profile. Is there demand for this? Better to have it in the
> > window title than on the plot itself?
> >
> > Maciek wrote:
> > > I had this problem too when interpolating DEM from contour lines with
> > > RST. Try to interploate DEM with r.surf.nnbathy from GRASS WIKI
> > > add-ons page and let us know if the artifact hollow between 2 adjacent
> > > contour lines still remains. I'm not 100% sure it will help. It might.
> >
> > v.surf.rst is designed for semi-evenly distributed series of data points
> > (at least locally, it is fine for data density to smoothly change), not
> > contour lines.
> >
> > running v.to.points + v.surf.rst tends to bias the surface to the
> > isolines. Output the treefile= segmentation map and curvature maps to
> > see the effect in detail. Also in the GRASS book, if you have access to
> > it.
> >
> > as Maciek wrote, you should get better results with r.surf.nnbathy, or
> > you can try r.surf.contour (see hints about that posted in the last day
> > or two to this list for r.surf.contour).
> >
> > You might try r.contour with your output raster map at levels half way
> > between your original isolines to get a nice visual check of how the
> > interpolation went. (create new contour lines 1/2 way between the
> > original ones and overlay them)
> >
> >
> >
> > Hamish
>
> Maciek, Hamish, Mars,
> Thank you for your comments.
>
> I've interpolated isolines with use of r.surf.nnbathy:
>
> r.surf.nnbathy alg=nn input=izolinie output=nn_elevation
>
> unfortunately, the results are even worse that those which comes from
> RST method. After "translating" it into the slope map (r.slope.aspect) I
> have the following result:
>
> http://mort.no-ip.org/grass/indexgrass.html
>
> As You can see, I still have "waves" between isolines. On the graph you
> will find those "waves" really large.
>
> The r.surf.contour methods gives much worse results then RST (see the
> Elevation graph).
>
> I've run r.contour with my RST output map as Hamish suggested ( see the
> last image on the http://mort.no-ip.org/grass/indexgrass.html )
>
> It was really interesting to analyse the output vector map. It seems
> that when the distance between two isolines is "large" GRASS "puts the
> next isoline" very close to the previous and this is how the "waves"
> comes from.
>
> What sholud I do next?? Please for comments and suggestions.
> Best Regards,
I do not know what is causing this behaviour, but there is a well-documented
problem with USGS dem data that causes similar artifacts:
(see the image at the bottom of the page)
http://169.237.35.250/~dylan/gdalwarp/image_matrix.html
dylan
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
------------------------------
Message: 3
Date: Mon, 30 Apr 2007 19:31:01 +0200
From: Maciej Sieczka
Subject: Re: [GRASS-user] Problem with slope modeling .
To: dylan.beaudette at gmail.com
Cc: grassuser at grass.itc.it
Message-ID: <463627D5.8050802 at o2.pl>
Content-Type: text/plain; charset=ISO-8859-2
Dylan Beaudette wrote:
> On Monday 30 April 2007 06:01, Radomir wrote:
>> Dnia 26-03-2007, pon o godzinie 20:30 +1200, Hamish napisa³(a):
>>>> Radomir wrote:
>>>>> I'm preparing the slope and elevation map from digitised isolines.
>>>>> I'm using v.surf.rst to do that with the following options:
>>>>>
>>>>> v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"
>>>>> dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"
>>>>> maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300
>>>>>
>>>>> The screenshot from small part of resulting map is here:
>>>>> http://mort.no-ip.org/screen.png
>>>>>
>>>>>
>>>>> On this screen you can see the valley in the center. I expect that
>>>>> the slope between two isolines on the bottom of the valley will be
>>>>> similar. But it is changing and gives an effect of "wave" between
>>>>> isolines.
>>> Mars wrote:
>>>> I presume the Isolines are representative of Elevation.
>>> and the displayed raster, legend, and profile show the slope.
>>> it might help to show a profile using the elevation map. (it is hard to
>>> tell if the slope stays monotonically increasing in your profile as
>>> slope will always be positive)
>>>
>>>
>>>
>>> profiler notes:
>>> - y-scale is ranged to max/min of map, not max/min of profile?
>>> ($elevrange from r.univar instead of r.profile in gis.m/profile.tcl)
>>> Not sure which is best. Both ways have some merit.
>>>
>>> - in your screenshot the axes tick labels are not formatted cleanly.
>>> I've just prettified those in CVS, please test.
>>>
>>> - BUG: if profile ends outside of the raster map off in NULL-land,
>>> the totaldistance calculation is calculated to the end of the arrows,
>>> but the end of real data in the plot is stretched to the far right end
>>> regardless. e.g.: Zoom out so your raster is a postage stamp sized box
>>> in the middle, then make some profiles from map canvas corner to
>>> corner. The start of the data is positioned ok. Also it should break
>>> the plot at NULL data, not draw a line beween the last known good data
>>> either side of the NULLs.
>>>
>>> - it would be possible to add a title like "Profile for $mapname" at the
>>> top of the profile. Is there demand for this? Better to have it in the
>>> window title than on the plot itself?
>>>
>>> Maciek wrote:
>>>> I had this problem too when interpolating DEM from contour lines with
>>>> RST. Try to interploate DEM with r.surf.nnbathy from GRASS WIKI
>>>> add-ons page and let us know if the artifact hollow between 2 adjacent
>>>> contour lines still remains. I'm not 100% sure it will help. It might.
>>> v.surf.rst is designed for semi-evenly distributed series of data points
>>> (at least locally, it is fine for data density to smoothly change), not
>>> contour lines.
>>>
>>> running v.to.points + v.surf.rst tends to bias the surface to the
>>> isolines. Output the treefile= segmentation map and curvature maps to
>>> see the effect in detail. Also in the GRASS book, if you have access to
>>> it.
>>>
>>> as Maciek wrote, you should get better results with r.surf.nnbathy, or
>>> you can try r.surf.contour (see hints about that posted in the last day
>>> or two to this list for r.surf.contour).
>>>
>>> You might try r.contour with your output raster map at levels half way
>>> between your original isolines to get a nice visual check of how the
>>> interpolation went. (create new contour lines 1/2 way between the
>>> original ones and overlay them)
>>>
>>>
>>>
>>> Hamish
>> Maciek, Hamish, Mars,
>> Thank you for your comments.
>>
>> I've interpolated isolines with use of r.surf.nnbathy:
>>
>> r.surf.nnbathy alg=nn input=izolinie output=nn_elevation
>>
>> unfortunately, the results are even worse that those which comes from
>> RST method. After "translating" it into the slope map (r.slope.aspect) I
>> have the following result:
>>
>> http://mort.no-ip.org/grass/indexgrass.html
>>
>> As You can see, I still have "waves" between isolines. On the graph you
>> will find those "waves" really large.
>>
>> The r.surf.contour methods gives much worse results then RST (see the
>> Elevation graph).
>>
>> I've run r.contour with my RST output map as Hamish suggested ( see the
>> last image on the http://mort.no-ip.org/grass/indexgrass.html )
>>
>> It was really interesting to analyse the output vector map. It seems
>> that when the distance between two isolines is "large" GRASS "puts the
>> next isoline" very close to the previous and this is how the "waves"
>> comes from.
>>
>> What sholud I do next?? Please for comments and suggestions.
>> Best Regards,
>
> I do not know what is causing this behaviour, but there is a well-documented
> problem with USGS dem data that causes similar artifacts:
>
> (see the image at the bottom of the page)
> http://169.237.35.250/~dylan/gdalwarp/image_matrix.html
Dylan,
Are you sure this is related? The material you mention refers to issues
connected with raster DEM re-projection. Radomir is concerned with a
comparison of different interpolation methods (with a specific input
such as contour lines), in regard to DEM's slope.
Maybe I'm missing something. Please excuse me and elaborate, if so.
Best,
Maciek
------------------------------
Message: 4
Date: Mon, 30 Apr 2007 19:17:12 +0100
From: Glynn Clements
Subject: Re: [GRASS-user] Benchmarking Grass 4.3, 5.4, 6.0, 6.2 raster
commands
To: Roy Sanderson
Cc: grassuser at grass.itc.it, grass-dev at grass.itc.it
Message-ID: <17974.12968.328085.755096 at cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
[CC to grass-dev]
Roy Sanderson wrote:
> I've been trying to persuade our users to stop working with Grass 4.3 and
> Grass 5.4 for some time now, and as I have to upgrade the OS on our
> applications server have told them that they now have no choice.
>
> However, a couple of users stated that they preferred to use Grass 4.3 as
> it was faster, and for large tasks, more stable than the newer versions. I
> checked this on a map of 52,000 rows by 28,000 columns and commands like
> r.mapcalc, r.clump, r.volume operated about 10x faster in Grass 4.3 than
> the more recent versions.
>
> This might simply arise from the age of the applications server OS (still
> running RH7.3), or because I've mis-configured the newer versions of Grass.
> For example, I did not compile Grass 5 or 6 with large-file support
> enabled, although the file sizes are only around 180Mb, but the speedy
> performance of 4.3 vs 5.4, 6.0 and 6.2.1 surprised me. Perhaps there's an
> additional overhead associated with the introduction of nulls and
> floating-points, which were major changes from 4.3 to 5.4. However, the
> performance difference is still present when working with integer maps. As
> I haven't benchmarked versions, and also because personally I only work
> with Grass version 6, I hadn't spotted the differences until now.
I strongly suspect that the support for nulls is to blame. The
implementation is really quite inefficient in several ways.
It doesn't help that the null file is repeatedly opened and closed
(the null bitmap is read in chunks of 8 rows at a time, with the file
being opened anew for each read). Depending upon the speed of
filesystem calls (open(), access() etc) relative to actual I/O, that
could be a significant factor.
Keeping the null file open would eliminate that part of the overhead,
but would double the number of descriptors used. On older versions,
that would halve the maximum number of open maps, although that limit
has been eliminated in recent 6.3 CVS versions.
Also, that would only eliminate part of the overhead. Actually
decoding and embedding the null data is also non-trivial.
Embedding the nulls in the data file, eliminating the null bitmap
altogether, would eliminate all of the null overhead, but would also
either enlarge the files significantly or break compatibility.
The existing format is optimised for small, non-negative integers.
Each row is stored using only as many bytes are required for the
largest value, where all values are treated as unsigned (i.e. negative
values always require 4 bytes). The integer value used for nulls is
0x80000000 (i.e. INT_MIN, -2^31); embedding this value directly would
cause many files to always use 4 bytes per cell when 1 byte would
otherwise be enough.
We could change the encoding to be more friendly to embedded nulls,
but that would break compatibility with earlier versions. AFAICT, a
6.3 integer raster can still be read by 4.3 (assuming that it uses RLE
rather than zlib compression), with any nulls being read as zeroes.
--
Glynn Clements
------------------------------
Message: 5
Date: Mon, 30 Apr 2007 16:14:39 -0400
From: Helena Mitasova
Subject: Re: [GRASS-dev] Re: [GRASS-user] Benchmarking Grass 4.3, 5.4,
6.0, 6.2 raster commands
To: Glynn Clements
Cc: grassuser at grass.itc.it, Roy Sanderson
, GRASS developers list
Message-ID: <2A41DE5D-FA9F-495E-9B39-57258C82B42C at unity.ncsu.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Glynn,
does the null implementation affect also the runs with rasters that
have no nulls
and there is no MASK present? As I have recently written, I have
noticed what seems to be totally unrelated changes in performance in
v.surf.rst compared the 4.3 - mostly along the line of changing to
G_ludcmp
from an internal lineq solver, but it may be somewhere else.
10x faster is a huge difference - it may be worthwhile to find out
whether it is true for integer maps without nulls and whether it
is really nulls slowing it down so badly.
There were many discussions about the null implementation and as
Glynn correctly
points out the main driver for the current design was to sacrifice
the performance
to preserve the backwards compatibility. Wishes of old users (many of
whom
contributed funds to GRASS development) were given very high priority.
Helena
Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/
On Apr 30, 2007, at 2:17 PM, Glynn Clements wrote:
>
> [CC to grass-dev]
>
> Roy Sanderson wrote:
>
>> I've been trying to persuade our users to stop working with Grass
>> 4.3 and
>> Grass 5.4 for some time now, and as I have to upgrade the OS on our
>> applications server have told them that they now have no choice.
>>
>> However, a couple of users stated that they preferred to use Grass
>> 4.3 as
>> it was faster, and for large tasks, more stable than the newer
>> versions. I
>> checked this on a map of 52,000 rows by 28,000 columns and
>> commands like
>> r.mapcalc, r.clump, r.volume operated about 10x faster in Grass
>> 4.3 than
>> the more recent versions.
>>
>> This might simply arise from the age of the applications server OS
>> (still
>> running RH7.3), or because I've mis-configured the newer versions
>> of Grass.
>> For example, I did not compile Grass 5 or 6 with large-file support
>> enabled, although the file sizes are only around 180Mb, but the
>> speedy
>> performance of 4.3 vs 5.4, 6.0 and 6.2.1 surprised me. Perhaps
>> there's an
>> additional overhead associated with the introduction of nulls and
>> floating-points, which were major changes from 4.3 to 5.4.
>> However, the
>> performance difference is still present when working with integer
>> maps. As
>> I haven't benchmarked versions, and also because personally I only
=== message truncated ===
Pawan Joshi
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
Check outnew cars at Yahoo! Autos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20070430/c7062069/attachment.html
More information about the grass-user
mailing list