Re: [BUGS] BUG #4303: insufficient privileges
You might have better luck asking on the pgsql-general mailing list (you'll want to subscribe to it at http://archives.postgresql.org/). I don't know if the windows hackers regularly read -bugs. On Jul 14, 2008, at 4:14 AM, Alexandre wrote: The following bug has been logged online: Bug reference: 4303 Logged by: Alexandre Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Windows xp Description:insufficient privileges Details: Hi, I have been getting the following error everytime I tried to install PostgreSQL: Service 'PostgreSQL Database Server 8.2' (pgsql-8.2) failed to start. Verify that you have sufficient privileges to start system services I am loged in as an administrator. I searched forums etc... but found no clear answers... Im really desperate ! Can't solve this stupid problem... Can you help me ? Thank you Alexandre -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [BUGS] BUG #4303: insufficient privileges
On Mon, Jul 14, 2008 at 5:14 AM, Alexandre <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 4303 > Logged by: Alexandre > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2 > Operating system: Windows xp > Description:insufficient privileges > Details: > > Hi, > > I have been getting the following error everytime I tried to install > PostgreSQL: > > Service 'PostgreSQL Database Server 8.2' (pgsql-8.2) failed to start. Verify > that you have sufficient privileges to start system services > > I am loged in as an administrator. > I searched forums etc... but found no clear answers... Is there anything in the event log, or in the pg_log directory in the data directory? -- 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] Psql or test application hangs when interface is down for the DB server
"K, Niranjan (NSN - IN/Bangalore)" <[EMAIL PROTECTED]> writes: > Is there any other workaround or alternative so that the situation about > the interface is down is known and based on that the 'PQexec' does not > get blocked for ~15 minutes. Absent threads I think you have to use alarm() and a SIGALRM signal handler. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- 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] Psql or test application hangs when interface is down for the DB server
Gregory Stark <[EMAIL PROTECTED]> writes: > "K, Niranjan (NSN - IN/Bangalore)" <[EMAIL PROTECTED]> writes: >> Is there any other workaround or alternative so that the situation about >> the interface is down is known and based on that the 'PQexec' does not >> get blocked for ~15 minutes. > Absent threads I think you have to use alarm() and a SIGALRM signal handler. On most modern platforms you can adjust the TCP timeouts for the connection. There's no explicit support for that in libpq, but you can just get the socket FD from it and do setsockopt(). 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
Re: [BUGS] Psql or test application hangs when interface is down for the DB server
I have noticed this as well. Blocks in poll(), timeout parameter -1, meaning infinite then after 4 minutes on my system poll() returns 1 and getsockopt() is called with SO_ERROR. SYN packets are tried only for the default tcp timeout of 20 seconds. Consider using threads that way you can set your own timeout value. Regards Val --- On Wed, 16/7/08, K, Niranjan (NSN - IN/Bangalore) <[EMAIL PROTECTED]> wrote: > From: K, Niranjan (NSN - IN/Bangalore) <[EMAIL PROTECTED]> > Subject: Re: [BUGS] Psql or test application hangs when interface is down for > the DB server > To: "ext Tom Lane" <[EMAIL PROTECTED]> > Cc: pgsql-bugs@postgresql.org > Date: Wednesday, 16 July, 2008, 6:55 AM > Currently the test application or the psql will unblock > after ~15 > minutes. This is a very huge time to realize for programs > this situation > which do database updates. > As far as I have debugged, I see that the execution is > waiting on > 'poll()' system call in the function pqSocketPoll() > which is called as a > result of 'PQexec()' and the timeout paramater > provided will be -1, > which means infinite wait time. It not clear how this is > getting > unblocked after 15 minutes. Who will write to the socket or > who will > interrupt the poll() system call? > > Is there any other workaround or alternative so that the > situation about > the interface is down is known and based on that the > 'PQexec' does not > get blocked for ~15 minutes. > > regards, > Niranjan > > -Original Message- > From: ext Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 15, 2008 8:16 PM > To: K, Niranjan (NSN - IN/Bangalore) > Cc: pgsql-bugs@postgresql.org > Subject: Re: [BUGS] Psql or test application hangs when > interface is > down for the DB server > > "K, Niranjan (NSN - IN/Bangalore)" > <[EMAIL PROTECTED]> writes: > > In the postgres database there is table > 'COUNTER_TABLE' with column > > integer type 'COUNTER'. The test application > attached in this mail, > > will start a transaction, gets the current value in > the COUNTER, > > increments the value and updates the incremented value > into the > COUNTER column. > > This is being done in a loop. The program is started > in a remote > > client and after few transactions, the interface > between the client & > > the database server is brought down (example I used > "ifconfig eth0 > > down" in the server). With this the test > application hangs and does > > not return from the API of postgres (ex. > 'PQexec'). > > If you waited long enough for the TCP connection to time > out, it would > return (with an error, of course). This behavior is not a > bug, it is > the expected behavior of any program using a network > connection. > > 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 __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html -- 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] Psql or test application hangs when interface is down for the DB server
"Valentin Bogdanov" <[EMAIL PROTECTED]> writes: > I have noticed this as well. Blocks in poll(), timeout parameter -1, Oh good point. non-blocking sockets and poll/select let you control the timeout too. > meaning infinite then after 4 minutes on my system poll() returns 1 and > getsockopt() is called with SO_ERROR. SYN packets are tried only for the > default tcp timeout of 20 seconds. Uhm, 20 seconds would be an unreasonably low default. I think the RFCs mandate timeouts closer to the 4 minutes you describe. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- 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] Psql or test application hangs when interface is down for the DB server
Thanks Gregory, You right, of course, about that. It is 4 minutes I wasn't paying attention and thought that I have found something odd. The last packet is sent a minute and a half after the first and I miss-read that for 20 seconds. Cheers, Val --- On Wed, 16/7/08, Gregory Stark <[EMAIL PROTECTED]> wrote: > From: Gregory Stark <[EMAIL PROTECTED]> > Subject: Re: [BUGS] Psql or test application hangs when interface is down for > the DB server > To: [EMAIL PROTECTED] > Cc: "ext Tom Lane" <[EMAIL PROTECTED]>, "K, Niranjan (NSN - IN/Bangalore)" > <[EMAIL PROTECTED]>, pgsql-bugs@postgresql.org > Date: Wednesday, 16 July, 2008, 6:33 PM > "Valentin Bogdanov" <[EMAIL PROTECTED]> > writes: > > > I have noticed this as well. Blocks in poll(), timeout > parameter -1, > > Oh good point. non-blocking sockets and poll/select let you > control the > timeout too. > > > meaning infinite then after 4 minutes on my system > poll() returns 1 and > > getsockopt() is called with SO_ERROR. SYN packets are > tried only for the > > default tcp timeout of 20 seconds. > > Uhm, 20 seconds would be an unreasonably low default. I > think the RFCs mandate > timeouts closer to the 4 minutes you describe. > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > Ask me about EnterpriseDB's RemoteDBA services! > > -- > Sent via pgsql-bugs mailing list > (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html -- 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] Psql or test application hangs when interface is down for the DB server
Thanks Gregory, You right, of course, about that. It is 4 minutes I wasn't paying attention and thought that I have found something odd. The last packet is sent a minute and a half after the first and I miss-read that for 20 seconds. Cheers, Val --- On Wed, 16/7/08, Gregory Stark <[EMAIL PROTECTED]> wrote: > From: Gregory Stark <[EMAIL PROTECTED]> > Subject: Re: [BUGS] Psql or test application hangs when interface is down for > the DB server > To: [EMAIL PROTECTED] > Cc: "ext Tom Lane" <[EMAIL PROTECTED]>, "K, Niranjan (NSN - IN/Bangalore)" > <[EMAIL PROTECTED]>, pgsql-bugs@postgresql.org > Date: Wednesday, 16 July, 2008, 6:33 PM > "Valentin Bogdanov" <[EMAIL PROTECTED]> > writes: > > > I have noticed this as well. Blocks in poll(), timeout > parameter -1, > > Oh good point. non-blocking sockets and poll/select let you > control the > timeout too. > > > meaning infinite then after 4 minutes on my system > poll() returns 1 and > > getsockopt() is called with SO_ERROR. SYN packets are > tried only for the > > default tcp timeout of 20 seconds. > > Uhm, 20 seconds would be an unreasonably low default. I > think the RFCs mandate > timeouts closer to the 4 minutes you describe. > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > Ask me about EnterpriseDB's RemoteDBA services! > > -- > Sent via pgsql-bugs mailing list > (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
