Re: [BUGS] BUG #4771: Postgres wont start
Christine,
when PostgreSQL does not start on Windows, the first place to look for
errors is the Microsoft Windows EventLog. That is the standard place to
report errors.
You can dig there via Control Panel; exact click path depending on your
Windows Version (XP / Vista / W2003 / W2008 / W7); or start a commandline
and type eventvwr (works on all)
There you go to the errors of "Application"; and track down the information
of the PostgreSQL service.
In my experience (~ 200 different Windows Computers in ~15 Administrative
Environments) the most common errors are:
- "something" is taking away the "run-as-service"-privilege of the
postgres-Windows-User. Likely culprits for "something" are GroupPolicies
within ActiveDirectory. To be more challenging, it does not happen
immediately, but after x days of normal working
- "something" is taking away access rights to the PostgreSQL Data Directory
/ the PostgreSQL Configuration files
- Switching distributions between versions (from pginstaller to one click
installer or vice versa)
- Difference within PostgreSQL packagings ("pg_debugger" was default
acitvated in 8.3.0-8.3.4; and is no more default activated by default in
8.3.7; a line with "preload pg_debugger " in postgresql.conf may lead to non
starting PostgreSQL service)
- Some (anti)viral products block the access off ports; or files, or
starting of processes by Postgresql.
Most of these errors are best detected by checking the error log. (just with
AntiVir Products you're in the wild, most of the time. Check their
logfiles!)
Harald
On Thu, Apr 23, 2009 at 5:08 AM, Christine Penner wrote:
> I get no error. The only way I know its not connected is by trying to log
> in to pgAdmin. It tells me the server doesn't listen. Then I told it to
> start. Last time that worked. Now it won't start at all but it never gives
> any error.
>
> When I tried to open it with pg_ctl it tells me can not open PID file
> (Postmaster.pid). Permission denied. That's odd because I am an
> administrative user on Vista and it was working at one point.
>
> Should Postgres not be in the Program Files directory for Vista?
> In any case how to I fix it. I want to at least get the data out so I can
> re load it. I have a backup but its not as recent as I would like.
>
> Christine
>
>
> At 10:46 PM 4/21/2009, you wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Christine Penner wrote:
>> > The following bug has been logged online:
>> >
>> > Bug reference: 4771
>> > Logged by: Christine Penner
>> > Email address: christi...@telus.net
>> > PostgreSQL version: 8.3.7
>> > Operating system: Vista
>> > Description:Postgres wont start
>> > Details:
>> >
>> > I have had Postgres running and working on the computer for about a
>> month. A
>> > week ago I started and realized that the Postgres service was not
>> started. I
>> > started it and it worked fine. Today I started up and again Postgres has
>> not
>> > started. I have tried again and again to start it but it won't start. I
>> have
>> > restarted my computer 3 times, shut down programs running that may
>> interfere
>> > but still nothing.
>> >
>> > I can't find a log file that will give me more info on why it won't
>> start.
>> >
>>
>> what is the Error you are getting ?
>>
>> go to bin folder of postgres and try to start using pg_ctl
>>
>> like :- pg_ctl -D c:/postgres/8.3/...path upto data folder START
>>
>>
>>
>>
>>
>>
>>
>> --
>>regards,tushar
>>http://webeatoracle.com
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.2.2 (GNU/Linux)
>>
>> iD8DBQFJ7q9LfQNodY2PIRoRArjqAKCIfLk/392qYIn+cQY7iy23IPXNxQCgtetG
>> 8Q7KHYTH/gcd3+WSQnCd/Zw=
>> =7r7H
>> -END PGP SIGNATURE-
>>
>> __ Information from ESET NOD32 Antivirus, version of virus
>> signature database 4029 (20090422) __
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
LASIK good, steroids bad?
Re: [BUGS] BUG #4763: postgres service unstable, even during install
> However, after that when I try to run a script to dump another database and > restore it onto the beta, I get a "file not found" error, which is really > odd both because it was working fine on the 2009-03-24 build and because the > permissions have not changed. Aside from that, which is it's own problem, > after that error the service is no longer running and has to be started > again. > > This makes me think that something similar happens during the install, so > that something fails with the plperl setup that causes the service to shut > down (rather than it failing to start up in the first place.) If I shut down the 8.4-beta1 service and start up the 2009-03-24 service on the same port and run the script the same way (it's a perl script I'm accessing through a browser), it runs fine, so I can't see how it would be an Apache or Perl permissions issue (i.e., what those two are running as)--I just hit F5, it's launching the same pg_restore binary from the same account on the same restore file. The one way is fine, the other says, "No such file or directory" (sorry: not "file not found," that was a bit imprecise of me earlier.) I found I was looking in the wrong log for more detail, but I found some: pg_restore: WARNING: database "production" does not exist pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 519; 2612 47275 PROCEDURAL LANGUAGE plperl mysuperuser pg_restore: [archiver (db)] could not execute query: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Command was: CREATE PROCEDURAL LANGUAGE plperl; After that it's an error with every statement because there's no connection to the server. Now the really weird thing is, "production" doesn't exist on my 2009-03-24 server either. That's the one the dump is *from*, but I'm using "pg_restore -d dev", so it shouldn't matter that it doesn't exist (and indeed it doesn't on the 2009-03-24 server, because that works fine, note that I'm even using the 8.4-beta1 pg_restore binary for both cases.) And for the record the script drops "dev" and creates it from template0 right before trying to restore over it. Is it possible it's looking for Perl in the wrong place? (Hence the "No such file..." error that somehow makes it back to my Perl script?) Kev -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4763: postgres service unstable, even during install
On Thu, Apr 23, 2009 at 4:30 PM, Kevin Field wrote: > Is it possible it's looking for Perl in the wrong place? (Hence the > "No such file..." error that somehow makes it back to my Perl script?) What version of perl do you have? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4763: postgres service unstable, even during install
On Apr 23, 12:13 pm, dp...@pgadmin.org (Dave Page) wrote: > On Thu, Apr 23, 2009 at 4:30 PM, Kevin Field > wrote: > > Is it possible it's looking for Perl in the wrong place? (Hence the > > "No such file..." error that somehow makes it back to my Perl script?) > > What version of perl do you have? I have 5.8.8 in C:\Perl and 5.10.0 in C:\Perl5.10 But no problems with 2009-03-24...aren't both that and 8.4-beta1 linked against 5.8.8? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4763: postgres service unstable, even during install
On Thu, Apr 23, 2009 at 6:43 PM, Kevin Field wrote: > On Apr 23, 12:13 pm, dp...@pgadmin.org (Dave Page) wrote: >> On Thu, Apr 23, 2009 at 4:30 PM, Kevin Field >> wrote: >> > Is it possible it's looking for Perl in the wrong place? (Hence the >> > "No such file..." error that somehow makes it back to my Perl script?) >> >> What version of perl do you have? > > I have 5.8.8 in C:\Perl and 5.10.0 in C:\Perl5.10 > > But no problems with 2009-03-24...aren't both that and 8.4-beta1 > linked against 5.8.8? The community installer for beta 1 uses Perl 5.10. The one-click uses 5.8 in beta 1 and earlier snapshots. Both will use 5.10 for beta 2 (as well as Python 2.6 and TCL 8.5). I'm wondering if it's barfing because it's finding the wrong version when it tries to install pl/perl. That would also explain a report I saw of the installer failing with a similar error. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4763: postgres service unstable, even during install
On Apr 23, 11:30 am, Kevin Field wrote: > > pg_restore: WARNING: database "production" does not exist > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 519; 2612 47275 > PROCEDURAL LANGUAGE plperl mysuperuser > pg_restore: [archiver (db)] could not execute query: server closed the > connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > Command was: CREATE PROCEDURAL LANGUAGE plperl; Just for yucks, I tried creating the database 'production' (despite the fact that that shouldn't make a difference) and re-running the script, and it gave the same error minus the first line. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4777: pg_restore is done in alphabetical order by schema
The following bug has been logged online: Bug reference: 4777 Logged by: Kasia Tuszynska Email address: ktuszyn...@esri.com PostgreSQL version: 8.3.7 Operating system: Windows 2003 server Description:pg_restore is done in alphabetical order by schema Details: Summary:Postgres utility pg_restore.exe restores in alphabetical order by schema name, thus if a user table has a dependency on data yet to be restored (because it resides in a schema that will be restored further down in the restore) it will be blank. The Environment:Postgresql 8.3.0 (but the issue was retested in 8.3.7)is used as a database to store spatial data maintained by an application called ArcSDE (Spatial Database Engine). The application maintains 87 system tables, one of which resides in the "public" schema, the rest reside in a schema called "sde". The data it's self is stored in a user defined data type. All user data has a dependancy on a table in the public schema, the dependency is not maintained with constraints. If user data resides in schema called avtest and a schema called vtest, doing a restore will result in the data in the vtest schema to restore correctly ( meaning that the table was populated with data), and the data stored in the avtest schema will have no records in the table. example of unsuccessfull backup and restore: C:\Program Files\PostgreSQL\8.3\bin\pg_dump.exe -h aisak -p 5432 -U postgres -F c -b -v -f "C:\aisak.dump.backup" postgis C:\Program Files\PostgreSQL\8.3\bin\pg_restore.exe -h localhost -p 5432 -U postgres -d postgis -v "C:\aisak.dump.backup" If however I were to restore the public schema first, and than the remaineder of the database the data in both schemas restores correctly, because the public.sde_spatial_reference table is present for the data restore in both avtest and vtest schema. Example of a successful restore: C:\Program Files\PostgreSQL\8.3\bin\pg_dump.exe -h aisak -p 5432 -U postgres -F c -b -v -f "C:\testbackup.dump.backup" testbackup C:\Program Files\PostgreSQL\8.3\bin>pg_restore.exe -n public -p 5432 -U postgres -d testbackup -v "C:\testbackup.dump.backup" C:\Program Files\PostgreSQL\8.3\bin>pg_restore.exe -p 5432 -U postgres -d testbackup ckup -v "C:\testbackup.dump.backup" Identifying the problem:The best way to see the issue without setting up the whole environment of ArcSDE is to look at the text backup file: C:\Program Files\PostgreSQL\8.3\bin\pg_dump.exe -h aisak -p 5432 -U postgres -F p -v -f "C:\testbackup_text.dump.backup" testbackup reading the file illustrates that, the order in which the restore is structured is the following: create all schemas (in alphabetical order) create all tables, object ( in alphabetical order) execute copy command to populate tables ( in alphabetical schema order), the data I was testing with was restored in the following order: ... -- TOC entry 2891 (class 0 OID 889207) -- Dependencies: 2239 -- Data for Name: state; Type: TABLE DATA; Schema: avtest; Owner: avtest COPY state (objectid, state_name, state_fips... ... -- TOC entry 2806 (class 0 OID 888299) -- Dependencies: 2141 -- Data for Name: sde_spatial_references; Type: TABLE DATA; Schema: public; Owner: sde COPY sde_spatial_references (srid, sr_name, ... ... -- TOC entry 2893 (class 0 OID 889278) -- Dependencies: 2241 -- Data for Name: poles; Type: TABLE DATA; Schema: vtest; Owner: vtest COPY poles (objectid, dscktlabel,... Please notice that the sde_spatial_references table is restored as the second table in the list. It should be restored as the first table since all of the user data (states and poles) in this case relies on it. Please let me know if there is any other information I can provide. Sincerely, Kasia Tuszynska ktuszyn...@esri.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4777: pg_restore is done in alphabetical order by schema
"Kasia Tuszynska" writes: > Description:pg_restore is done in alphabetical order by schema You have not shown us any actual problem. There is nothing wrong with restoring the data in the order pg_dump uses, because no triggers or cross-table constraints have been installed at the time the data is loaded. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
