Re: [BUGS] BUG #6705: 32 bit
On Mon, Jun 25, 2012 at 4:38 PM, Craig Ringer wrote: > On 06/25/2012 11:10 PM, Dave Page wrote: > > On Mon, Jun 25, 2012 at 5:41 AM, Craig Ringer wrote: > > Dave: Is there any chance the installers link to that page from their error > dialogs, or a static-and-sanitised version of it in docs? If you're ok > updating the installer messages I'll collect up a sanitized version that > doesn't link to other wiki pages (or make it clear they're external) and > convert it for the docs. > > We can't do clickable links in those message boxes, so I'm not sure > how useful it'll be in practice. > > Argh. I've been in the browser-based app too long, I simply forget that URL > handling isn't everywhere. > > The main ones that IMO need a where-to-go-next hint are the messages that > arise when an external process step fails, like initdb, failure to install > the runtime, etc. It's always necessary to ask a poster asking for help for > the installer log - and how many people don't post or ask for help, just get > stuck and confused? Any ideas for a one-liner to add? I'm struggling to find nice wording, that doesn't invite people to report issues without investigating themselves first: * If you need help, please review http://xx before seeking further assistance. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] server crash with "process 22821 releasing ProcSignal slot 32, but it contains 0"
On Mon, Jun 25, 2012 at 10:03 AM, Merlin Moncure wrote: > On Mon, Jun 25, 2012 at 9:57 AM, Tom Lane wrote: >> Merlin Moncure writes: >>> 2012-06-25 09:08:08 CDT [postgres@ysanalysis_hes]: LOG: could not >>> send data to client: Broken pipe >>> 2012-06-25 09:08:10 CDT [postgres@ysanalysis_hes]: LOG: unexpected >>> EOF on client connection >>> 2012-06-25 09:08:10 CDT [postgres@ysanalysis_hes]: LOG: process 22821 >>> releasing ProcSignal slot 32, but it contains 0 >>> 2012-06-25 09:08:10 CDT [postgres@ysanalysis_hes]: LOG: failed to >>> find proc 0x7f48617e2ab0 in ProcArray >>> [and a bit later] >>> 2012-06-25 09:08:24 CDT [postgres@ysanalysis_hes]: FATAL: latch already >>> owned >> >> I think what we're looking at here is a screw-up in the process shutdown >> sequence. Perhaps caused by bad recovery from an attempt to send an >> error message to the already-disconnected client; but that's just >> speculation, and it's hard to see how to get more info without a core >> dump. >> >> I wonder whether we shouldn't promote some or all of these three error >> cases to PANIC, as they certainly suggest shared-memory corruption. >> And if it did panic, we could hope to get a core dump for debugging >> purposes. > > Ok, I'll look into reproducing the crash conditions. Unfortunately > this is a critical server and it crashed during a time sensitive > process. I can schedule a maintenance window though but it will have > to wait a bit. > > merlin I have some good news: this was reproduce and i I believe it to be operator invoked: 2012-06-26 09:12:19 CDT [postgres@ysanalysis_hes]: ERROR: index "idx_lease_expiremonth2" does not exist 2012-06-26 09:12:19 CDT [postgres@ysanalysis_hes]: STATEMENT: DROP INDEX idx_Lease_ExpireMonth2; 2012-06-26 09:15:10 CDT [rms@ysanalysis]: LOG: unexpected EOF on client connection 2012-06-26 09:15:10 CDT [rms@ysanalysis]: LOG: process 10340 releasing ProcSignal slot 5, but it contains 0 2012-06-26 09:15:10 CDT [rms@ysanalysis]: LOG: failed to find proc 0x7f48617e6310 in ProcArray 2012-06-26 09:16:48 CDT [rms@ysanalysis]: FATAL: latch already owned 2012-06-26 09:16:48 CDT [@]: LOG: server process (PID 10928) exited with exit code 1 2012-06-26 09:16:48 CDT [@]: LOG: terminating any other active server processes 2012-06-26 09:16:48 CDT [postgres@postgres]: WARNING: terminating connection because of crash of another server process ...investigating... merlin -- 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] server crash with "process 22821 releasing ProcSignal slot 32, but it contains 0"
On Tue, Jun 26, 2012 at 9:19 AM, Merlin Moncure wrote: >> Ok, I'll look into reproducing the crash conditions. Unfortunately >> this is a critical server and it crashed during a time sensitive >> process. I can schedule a maintenance window though but it will have >> to wait a bit. I suspect (but haven't had time to prove and may not for several days -- unfortunately going on vacation momentarily) that this might be caused by pl/sh. In particular, we have a routine that was inadvertently applied to the database in with windows cr/lf instead of the normal linux newline. This is an older version of plgplsh (1.3) and is maybe minus some relevant bug fixes. Just wanted to give a heads up so that you didn't waste time investigating. I will follow up on this eventually. merlin -- 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 #6707: ERROR: could not open relation with OID
The following bug has been logged on the website: Bug reference: 6707 Logged by: LiFeAiR Email address: life...@gmail.com PostgreSQL version: 9.1.4 Operating system: FREE BSD Description: CREATE OR REPLACE FUNCTION test() RETURNS integer AS $BODY$ DECLARE _r RECORD; BEGIN CREATE TEMP TABLE test(id int); _r := ROW(NULL)::test; _r:=NULL; DROP TABLE test CASCADE; RETURN 1; END; $BODY$ LANGUAGE plpgsql VOLATILE COST 100; select test(); -- 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] server crash with "process 22821 releasing ProcSignal slot 32, but it contains 0"
Merlin Moncure writes: > I suspect (but haven't had time to prove and may not for several days > -- unfortunately going on vacation momentarily) that this might be > caused by pl/sh. Hm. The reported symptoms might be explainable if something had caused multiple threads to become active within the backend process --- then it would be plausible for it to try to do proc_exit cleanup twice. Which would explain the first two errors, though I'm not sure how that leads to failing to disown the process latch, as the third error suggests must have happened. But I don't know enough about pl/sh to know if it could cause threading activation. > In particular, we have a routine that was > inadvertently applied to the database in with windows cr/lf instead of > the normal linux newline. This doesn't seem real promising as an explanation ... 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] server crash with "process 22821 releasing ProcSignal slot 32, but it contains 0"
On Tue, Jun 26, 2012 at 12:02 PM, Tom Lane wrote: > Merlin Moncure writes: >> I suspect (but haven't had time to prove and may not for several days >> -- unfortunately going on vacation momentarily) that this might be >> caused by pl/sh. > > Hm. The reported symptoms might be explainable if something had caused > multiple threads to become active within the backend process --- then > it would be plausible for it to try to do proc_exit cleanup twice. > Which would explain the first two errors, though I'm not sure how that > leads to failing to disown the process latch, as the third error > suggests must have happened. But I don't know enough about pl/sh to > know if it could cause threading activation. > >> In particular, we have a routine that was >> inadvertently applied to the database in with windows cr/lf instead of >> the normal linux newline. > > This doesn't seem real promising as an explanation ... right -- just a suspicion. maybe the relevant point was that it immediately failed. operator invoking the busted routine (which I had to fix) and the crash were highly correlated, although it does not always crash. yesterday was very heavy load and today not so much. merlin -- 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 #6705: 32 bit
Hi, As I am having the installation problem and have tried installed postgresql tens of times, I am still in need of your help. Could you tell me under what folder generated by the installer I can find the installation log? Thanks. Best, Jimmy 2012/6/25 Craig Ringer > On 06/25/2012 04:19 AM, gj19861...@gmail.com wrote: > > The following bug has been logged on the website: > > Bug reference: 6705 > Logged by: Jimmy Creeks > Email address: gj19861...@gmail.com > PostgreSQL version: 9.1.4 > Operating system: Windows 7 > Description: > > Hi, > > I cannot install 8.3, 9.0, or 9.1 version of postgreSQL. I also try shutting > down windows firewall. Here is the bug report > > Please see: > > http://wiki.postgresql.org/wiki/Troubleshooting_Installation > > At minimum we need your installation log, the exact version of windows eg > "Windows 7 Professional 64-bit", whether you're on a Windows corporate > domain, and what/any antivirus software you have running. > > Please reply to pgsql-bugs@postgresql.org, not to me. > > Dave: Is there any chance the installers link to that page from their > error dialogs, or a static-and-sanitised version of it in docs? If you're > ok updating the installer messages I'll collect up a sanitized version that > doesn't link to other wiki pages (or make it clear they're external) and > convert it for the docs. > > -- > Craig Ringer >
[BUGS] BUG #6708: pgsql_fdw's foreign table cann't used in plpgsql function
The following bug has been logged on the website: Bug reference: 6708 Logged by: digoal.zhou Email address: dig...@126.com PostgreSQL version: 9.1.3 Operating system: CentOS 5.x bit64 Description: pgsql_fdw's foreign table "cache lookup failed for type 0" bug when used in function 1.INSTALL https://github.com/dvarrazzo/interdbconnect/downloads mv pgsql_fdw $PG_SRC/contrib/ cd $PG_SRC/contrib/pgsql_fdw . /home/postgres/.bash_profile USE_PGXS=1 make USE_PGXS=1 make install 2.TEST digoal=# create extension pgsql_fdw; CREATE EXTENSION CREATE SERVER srv_digoal FOREIGN DATA WRAPPER pgsql_fdw OPTIONS (host '172.16.3.33', port '5432', dbname 'digoal'); CREATE USER MAPPING FOR digoal SERVER srv_digoal OPTIONS (user 'rmt_digoal', password 'DIGOAL123'); grant usage on foreign server srv_digoal to digoal; \c digoal digoal CREATE FOREIGN TABLE test ( id int ) server srv_digoal options (nspname 'digoal', relname 'table_digoal'); select * from test; It can do success, and return currect rows; but , if test table in plpgsql function , then error occur: create or replace function f_test () returns int as $$ declare begin perform 1 from test limit 1; return 0; end; $$ language plpgsql; digoal=# \set VERBOSITY verbose digoal=# select * from f_test(); ERROR: XX000: cache lookup failed for type 0 CONTEXT: SQL statement "SELECT 1 from test limit 1" PL/pgSQL function "f_test" line 3 at PERFORM LOCATION: getTypeOutputInfo, lsyscache.c:2440 3. DETAIL information please visit my blog : http://blog.163.com/digoal@126/blog/static/16387704020125218171919/ thanks very much; -- 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 #6707: ERROR: could not open relation with OID
life...@gmail.com writes: > CREATE OR REPLACE FUNCTION test() RETURNS integer AS > $BODY$ > DECLARE > _r RECORD; > BEGIN > CREATE TEMP TABLE test(id int); > _r := ROW(NULL)::test; > _r:=NULL; > DROP TABLE test CASCADE; > RETURN1; > END; > $BODY$ > LANGUAGE plpgsql VOLATILE > COST 100; Hmm. The problem with this is that the DROP TABLE invalidates test's rowtype, so on a second call the already-compiled "ROW(NULL)::test" expression refers to a type that no longer exists. We could fix that by adding datatypes to the set of objects that are tracked to determine when a cached plan must be invalidated, but I'm more than a bit hesitant to expend the extra cycles for this, given the lack of previous complaints and the large number of datatypes that are mentioned in most plans. Perhaps it would be good enough to only track types that must be rowtypes (ie, are mentioned in RowExpr or ConvertRowtypeExpr)? 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] BUG #6705: 32 bit
On Wed, Jun 27, 2012 at 2:01 AM, Jimmy Creeks wrote: > Hi, > > As I am having the installation problem and have tried installed > postgresql tens of times, I am still in need of your help. Could you tell > me under what folder generated by the installer I can find the installation > log? Thanks. > Installation logs can be found in your system's temp directory (%TEMP% on windows).. > Best, > > Jimmy > > > 2012/6/25 Craig Ringer > >> On 06/25/2012 04:19 AM, gj19861...@gmail.com wrote: >> >> The following bug has been logged on the website: >> >> Bug reference: 6705 >> Logged by: Jimmy Creeks >> Email address: gj19861...@gmail.com >> PostgreSQL version: 9.1.4 >> Operating system: Windows 7 >> Description: >> >> Hi, >> >> I cannot install 8.3, 9.0, or 9.1 version of postgreSQL. I also try shutting >> down windows firewall. Here is the bug report >> >> Please see: >> >> http://wiki.postgresql.org/wiki/Troubleshooting_Installation >> >> At minimum we need your installation log, the exact version of windows eg >> "Windows 7 Professional 64-bit", whether you're on a Windows corporate >> domain, and what/any antivirus software you have running. >> >> Please reply to pgsql-bugs@postgresql.org, not to me. >> >> Dave: Is there any chance the installers link to that page from their >> error dialogs, or a static-and-sanitised version of it in docs? If you're >> ok updating the installer messages I'll collect up a sanitized version that >> doesn't link to other wiki pages (or make it clear they're external) and >> convert it for the docs. >> >> -- >> Craig Ringer >> > > -- Regards, Sachin Srivastava EnterpriseDB, India
Re: [BUGS] BUG #6705: 32 bit
On 06/26/2012 06:26 PM, Dave Page wrote: Any ideas for a one-liner to add? I'm struggling to find nice wording, that doesn't invite people to report issues without investigating themselves first: * If you need help, please review http://xx before seeking further assistance. The positive wording is good. Maybe even: "Guidance for resolving installation issues can be found at http:// " ... where that provides the common-issues list, a pointer to look at the installation log, then a report template for cases where it wasn't one of the common quick-fixes. I'm happy to work on the docs side, possibly even do a quick JavaScript+form report template to ensure fields like detailed OS version, exact Pg version, etc are supplied. Which reminds me, I need to find out how to detect whether a Windows box is on a domain with non-default group policy, and how/if antivirus can be detected. -- Craig Ringer -- 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 #6705: 32 bit
On Jun 27, 2012 8:26 AM, "Craig Ringer" wrote: > > On 06/26/2012 06:26 PM, Dave Page wrote: >> >> Any ideas for a one-liner to add? I'm struggling to find nice wording, >> that doesn't invite people to report issues without investigating >> themselves first: >> >> * If you need help, please review http://xx before seeking further >> assistance. > > > The positive wording is good. Maybe even: > > "Guidance for resolving installation issues can be found at http:// " > > ... where that provides the common-issues list, a pointer to look at the installation log, then a report template for cases where it wasn't one of the common quick-fixes. > > I'm happy to work on the docs side, possibly even do a quick JavaScript+form report template to ensure fields like detailed OS version, exact Pg version, etc are supplied. Which reminds me, I need to find out how to detect whether a Windows box is on a domain with non-default group policy, and how/if antivirus can be detected. > >From the browser? Pretty sure that's impossible, and for very good reasons... /Magnus
Re: [BUGS] BUG #6705: 32 bit
On 06/27/2012 02:33 PM, Magnus Hagander wrote: > ... where that provides the common-issues list, a pointer to look at the installation log, then a report template for cases where it wasn't one of the common quick-fixes. > > I'm happy to work on the docs side, possibly even do a quick JavaScript+form report template to ensure fields like detailed OS version, exact Pg version, etc are supplied. Which reminds me, I need to find out how to detect whether a Windows box is on a domain with non-default group policy, and how/if antivirus can be detected. > From the browser? Pretty sure that's impossible, and for very good reasons... No, not from the browser. What a horrible thought. No, just "run this command" or "look here" or "copy this registry key" stuff. (It is possible to collect this stuff from the browser, but you'd have to use an ActiveX control or an Java Web Start application, and the security implications are absolutely horrific. I'd never, ever, ever, ever want to go there.) Maybe eventually I'd be able to put together a little script to run to collect info; if it's not bundled in the installer it doesn't have the same necessity to be absolutely robust and correct in all situations and can be easily updated to collect more. It can also collect stuff like installed-program lists, environment data, etc because the user would be _knowingly_ and _explicitly_ submitting the report with that info and have a chance to redact portions if desired. For now, though, all I'm talking about is a helping-hand web form with hints about how to find out the exact Windows version, architecture, antivirus in use, etc. Nothing but a web page with some jQuery code. -- Craig Ringer -- 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 #6705: 32 bit
On Jun 27, 2012 8:42 AM, "Craig Ringer" wrote: > > On 06/27/2012 02:33 PM, Magnus Hagander wrote: >> >> >> > ... where that provides the common-issues list, a pointer to look at the installation log, then a report template for cases where it wasn't one of the common quick-fixes. >> > >> > I'm happy to work on the docs side, possibly even do a quick JavaScript+form report template to ensure fields like detailed OS version, exact Pg version, etc are supplied. Which reminds me, I need to find out how to detect whether a Windows box is on a domain with non-default group policy, and how/if antivirus can be detected. >> > >> >> From the browser? Pretty sure that's impossible, and for very good reasons... >> > No, not from the browser. What a horrible thought. No, just "run this command" or "look here" or "copy this registry key" stuff. Good. Scared me there for a second :-) > (It is possible to collect this stuff from the browser, but you'd have to use an ActiveX control or an Java Web Start application, and the security implications are absolutely horrific. I'd never, ever, ever, ever want to go there.) Yeah let's not go there. Active X would also encourage the bad practice of using Internet explorer of course, which is another good reason not to go there :-) > Maybe eventually I'd be able to put together a little script to run to collect info; if it's not bundled in the installer it doesn't have the same necessity to be absolutely robust and correct in all situations and can be easily updated to collect more. It can also collect stuff like installed-program lists, environment data, etc because the user would be _knowingly_ and _explicitly_ submitting the report with that info and have a chance to redact portions if desired. > > For now, though, all I'm talking about is a helping-hand web form with hints about how to find out the exact Windows version, architecture, antivirus in use, etc. Nothing but a web page with some jQuery code. > There are some easy api to get whether the box is on a domain or not, and it's easily accessible from wsh as well. And it ought to be trivial in power shell... As for the av, I'm less sure. Maybe it's better to just dump a list of installed programs? I'd expect all av to be installed by installers that register them.. The other idea would be to find out if there is an api corresponding to the "your computer is at risk" is warning bubble, and just use it backwards. I have non idea if there is though, I've never done any work in that area at all. /Magnus
