Re: [BUGS] Re: BUG #5065: pg_ctl start fails as administrator, with "could not locate matching postgres executable"
On Fri, Oct 16, 2009 at 1:08 AM, Jesse Morris wrote: > I went back to the version that supposedly initially fixed this issue, > but I couldn't get it to work either. So I think the DACL adjustment > code was always broken. The DACL stuff that both Cygwin and Active > Perl use to simulate *nix file permissions masks this error, so any > test framework that uses them would get false negatives on this bug. > Since these DACLs are inheritable, a workaround is to run pg_ctl as a > child process of Active Perl or Cygwin. The comments indicated > pg_ctl & initdb were already trying to do the same thing themselves > (that is, add the current user to the DACLs) but it didn't actually > work on any of the systems I tried it on. In fairness it wasn't entirely broken as it fixed the problem for the majority of people. Clearly there's room for improvement though as we do still see the problem occasionally. > I think that a number of other people have seen this bug; search for > "FATAL: postgres - could not locate matching postgres executable." > But that message is so misleading is probably why it seems nobody has > properly diagnosed it as a permissions issue before. I didn't do > anything to fix pg_ctl's error reporting. :D We figured out that it was a permissions problem after a *lot* of back and forth with Microsoft's developer support engineers - that's what led to the AddUserToDacl fix. What didn't then happen was further investigation into the handful of later reports of similar issues - unfortunately that can be extremely difficult as few users are experienced Windows programmers. It's great to see someone that is has seen the problem and taken the time to figure it out :-). > The patch: > > --begin patch-- :-(. Unfortunately inlining the patch in the email has munged it beyond usability. Can you resend it as an attachment please? Thanks! -- 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
[BUGS] vacuumdb error
Hi, I've noticed I can't run vacuumdb with ALL FULL VERBOSE and FREEZE. The error returned is: vacuumdb: vacuuming of database "killingcupid.co.uk" failed: ERROR: syntax error at or near "FREEZE" LINE 1: VACUUM FULL VERBOSE FREEZE; The commands I used are: vacuumdb -afFv vacuumdb --all --full --freeze --verbose I've tried moving the switches round to put them in the order specified in the documentation, just in case it had any effect on the order of the keywords, but it doesn't. I can run this manually in psql using: VACUUM FULL FREEZE VERBOSE; This is either a bug in vacuumdb with it not using the correct order, or postgres shouldn't be paying attention to the order of the keywords. In any case, it doesn't work. I've searched the postgres FAQs, TODO and mailing list archives, but can't find a mention of this. Thanks Thom -- 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] vacuumdb error
2009/10/16 Thom Brown : > Hi, > > I've noticed I can't run vacuumdb with ALL FULL VERBOSE and FREEZE. > > The error returned is: > > vacuumdb: vacuuming of database "killingcupid.co.uk" failed: ERROR: > syntax error at or near "FREEZE" > LINE 1: VACUUM FULL VERBOSE FREEZE; > > The commands I used are: > > vacuumdb -afFv > vacuumdb --all --full --freeze --verbose > > I've tried moving the switches round to put them in the order > specified in the documentation, just in case it had any effect on the > order of the keywords, but it doesn't. I can run this manually in > psql using: > > VACUUM FULL FREEZE VERBOSE; > > This is either a bug in vacuumdb with it not using the correct order, > or postgres shouldn't be paying attention to the order of the > keywords. In any case, it doesn't work. I've searched the postgres > FAQs, TODO and mailing list archives, but can't find a mention of > this. > > Thanks > > Thom > I should also mention this is using PostgreSQL 8.4.1 and vacuumdb is dated 2009-09-03. The error also still occurs if I remove FULL from the command. Thom -- 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] vacuumdb error
Thom Brown wrote: > This is either a bug in vacuumdb with it not using the correct order, > or postgres shouldn't be paying attention to the order of the > keywords. In any case, it doesn't work. I've searched the postgres > FAQs, TODO and mailing list archives, but can't find a mention of > this. Thanks, fixed. We had the same bug with FREEZE and ANALYZE combination, which was fixed in April, but the order between FREEZE and VERBOSE was still incorrect. -- Heikki Linnakangas EnterpriseDB 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] vacuumdb error
2009/10/16 Heikki Linnakangas : > Thom Brown wrote: >> This is either a bug in vacuumdb with it not using the correct order, >> or postgres shouldn't be paying attention to the order of the >> keywords. In any case, it doesn't work. I've searched the postgres >> FAQs, TODO and mailing list archives, but can't find a mention of >> this. > > Thanks, fixed. We had the same bug with FREEZE and ANALYZE combination, > which was fixed in April, but the order between FREEZE and VERBOSE was > still incorrect. > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com > Thanks Heikki. You probably already know, but remember to prevent it using FREEZE at all for 8.5+ as according to the documentation it's being deprecated. Thom -- 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] vacuumdb error
Thom Brown wrote: > Thanks Heikki. You probably already know, but remember to prevent it > using FREEZE at all for 8.5+ as according to the documentation it's > being deprecated. It's been documented as deprecated since 8.2, in favor of the vacuum_freeze_max_age option. However, it's still widely used in the field, and there's no immediate reason to remove it, so I don't think we're actually going to remove it in the foreseeable future. -- Heikki Linnakangas EnterpriseDB 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] vacuumdb error
2009/10/16 Heikki Linnakangas : > Thom Brown wrote: >> Thanks Heikki. You probably already know, but remember to prevent it >> using FREEZE at all for 8.5+ as according to the documentation it's >> being deprecated. > > It's been documented as deprecated since 8.2, in favor of the > vacuum_freeze_max_age option. However, it's still widely used in the > field, and there's no immediate reason to remove it, so I don't think > we're actually going to remove it in the foreseeable future. > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com > Sorry, I mean the actual keyword will be removed meaning it would error if used as an option, although whether it'll be in 8.5 I don't actually know. Thom -- 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 #5121: Segmentation Fault when using pam w/ krb5
Ok... I compiled 8.2.14 and 8.3.8 with the same configure options. They
both segfaut when doing the authentication. Note that when I use -W
option with psql everything works ok. I went back to 8.4.1 enabled the
max debug level then re-tested and got the info below in the log. I went
to line 769 in pqcomm.c and commented the ereport and return EOF lines
and recompiled. Now when I connect it works without a segfault. Hope
this narrows things down.
- Pqcomm.c
/*
* Careful: an ereport() that tries to write to
the client would
* cause recursion to here, leading to stack
overflow and core
* dump! This message must go *only* to the
postmaster log.
*/
/* ereport(COMMERROR,
(errcode_for_socket_access(),
errmsg("could not receive data
from client: %m")));
return EOF; */
-- postgresql log -
.
.
.
<@ 2009-10-15 23:39:06.725 EDT>DEBUG: 0: forked new backend,
pid=23184 socket=8
<@ 2009-10-15 23:39:06.725 EDT>LOCATION: BackendStartup,
postmaster.c:3083
<[unkno...@[unknown] 2009-10-15 23:39:06.726 EDT>LOG: 0:
connection received: host=10.0.20.38 port=36929
<[unkno...@[unknown] 2009-10-15 23:39:06.726 EDT>LOCATION:
BackendInitialize, postmaster.c:3259
<[unkno...@[unknown] 10.0.20.38(36929) 2009-10-15 23:39:06.754
EDT>DEBUG: 0: SSL connection from "(anonymous)"
<[unkno...@[unknown] 10.0.20.38(36929) 2009-10-15 23:39:06.754
EDT>LOCATION: open_server_SSL, be-secure.c:961
DEBUG:
0: SSL: read alert (0x0100)
LOCATION:
info_cb, be-secure.c:699
LOG:
08006: could not receive data from client: Connection reset by peer
LOCATION:
pq_recvbuf, pqcomm.c:769
<@ 2009-10-15 23:39:20.546 EDT>DEBUG: 0: reaping dead processes
<@ 2009-10-15 23:39:20.546 EDT>LOCATION: reaper, postmaster.c:2236
<@ 2009-10-15 23:39:20.546 EDT>DEBUG: 0: server process (PID
23184) was terminated by signal 11: Segmentation fault
<@ 2009-10-15 23:39:20.546 EDT>LOCATION: LogChildExit,
postmaster.c:2725
<@ 2009-10-15 23:39:20.546 EDT>LOG: 0: server process (PID 23184)
was terminated by signal 11: Segmentation fault
<@ 2009-10-15 23:39:20.546 EDT>LOCATION: LogChildExit,
postmaster.c:2725
<@ 2009-10-15 23:39:20.546 EDT>LOG: 0: terminating any other
active server processes
.
.
.
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, October 15, 2009 7:26 PM
To: Douglas, Ryan
Cc: Magnus Hagander
Subject: Re: [BUGS] BUG #5121: Segmentation Fault when using pam w/ krb5
"Douglas, Ryan" writes:
> My krb5.conf points to MS Active Directory...
Oh, that's *definitely* relevant information. I have no idea how well
tested that combination is. Magnus, can you comment on whether there
might be bugs in the combination of PG 8.4.1, Fedora 11 PAM libraries,
and an MS controller?
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 #5121: Segmentation Fault when using pam w/ krb5
Both actually... When just the "return" is commented out the routine goes into a loop and the following shows up in the logs... LOG: could not receive data from client: Connection reset by peer LOG: could not receive data from client: Connection reset by peer LOG: could not receive data from client: Connection reset by peer LOG: could not receive data from client: Connection reset by peer When just "ereport" is commented out I still get a sigfault... <[unkno...@[unknown] 2009-10-16 01:13:49.211 EDT>LOG: connection received: host=10.0.20.38 port=32815 <@ 2009-10-16 01:13:49.258 EDT>LOG: server process (PID 13201) was terminated by signal 11: Segmentation fault <@ 2009-10-16 01:13:49.258 EDT>LOG: terminating any other active server processes <@ 2009-10-16 01:13:49.262 EDT>LOG: all server processes terminated; reinitializing <@ 2009-10-16 01:13:49.381 EDT>LOG: database system was interrupted; last known up at 2009-10-16 01:13:37 EDT <@ 2009-10-16 01:13:49.382 EDT>LOG: database system was not properly shut down; automatic recovery in progress <@ 2009-10-16 01:13:49.382 EDT>LOG: record with zero length at 3/B7D75538 <@ 2009-10-16 01:13:49.383 EDT>LOG: redo is not required <@ 2009-10-16 01:13:49.409 EDT>LOG: autovacuum launcher started <@ 2009-10-16 01:13:49.410 EDT>LOG: database system is ready to accept connections But when both are commented it seems to work... <[unkno...@[unknown] 2009-10-16 01:15:05.330 EDT>LOG: connection received: host=10.0.20.38 port=32816 <[unkno...@[unknown] 2009-10-16 01:15:17.436 EDT>LOG: connection received: host=10.0.20.38 port=32817 LOG: connection authorized: user=rdouglas database=tacacs -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, October 16, 2009 1:01 AM To: Douglas, Ryan Subject: Re: [BUGS] BUG #5121: Segmentation Fault when using pam w/ krb5 "Douglas, Ryan" writes: > Ok... I compiled 8.2.14 and 8.3.8 with the same configure options. They > both segfaut when doing the authentication. Note that when I use -W > option with psql everything works ok. I went back to 8.4.1 enabled the > max debug level then re-tested and got the info below in the log. I went > to line 769 in pqcomm.c and commented the ereport and return EOF lines > and recompiled. Now when I connect it works without a segfault. Hope > this narrows things down. Which is it that makes the difference ... the ereport or the return? 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
[BUGS] BUG #5122: Subqueries - inner select statement bug
The following bug has been logged online: Bug reference: 5122 Logged by: Muris Pucic Email address: t...@multicom.ba PostgreSQL version: 8.2 Operating system: Vista Description:Subqueries - inner select statement bug Details: Hi, If we have two simple tables: TABLE1 -- id first_name TABLE2 -- id last_name ## EXAMPLE QUERY: ## -- The query below works, even though there is no column "first_name" in TABLE2. This should return an error but it does not, it returns all rows from TABLE1. This query should not evaluate correctly even when aliases are not used because it can be misleading. SELECT * FROM TABLE1 WHERE first_name IN (SELECT first_name FROM TABLE2) -- The query below works as expected SELECT * FROM TABLE1 WHERE first_name IN (SELECT last_name FROM TABLE2) Regards, Muris www.elektronika.ba -- 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 #5123: bug in window function "last_value"
The following bug has been logged online: Bug reference: 5123 Logged by: Andrey Email address: and...@ulab.ru PostgreSQL version: 8.4.1-x86_64 Operating system: RHEL5-x86_64 Description:bug in window function "last_value" Details: EXAMPLE: CREATE TABLE t ( id serial NOT NULL, CONSTRAINT pkey_t PRIMARY KEY (id) ) WITH (OIDS=FALSE); INSERT INTO t VALUES(default); INSERT INTO t VALUES(default); INSERT INTO t VALUES(default); select id, first_value(id) over(order by id), last_value(id) over(order by id) from t; RESULT: id | first_value | last_value +-+ 1 | 1 | 1 2 | 1 | 2 3 | 1 | 3 (3 rows) fist_value - good, last_value - bad -- 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] vacuumdb error
On Fri, Oct 16, 2009 at 6:39 AM, Heikki Linnakangas wrote: > Thom Brown wrote: >> This is either a bug in vacuumdb with it not using the correct order, >> or postgres shouldn't be paying attention to the order of the >> keywords. In any case, it doesn't work. I've searched the postgres >> FAQs, TODO and mailing list archives, but can't find a mention of >> this. > > Thanks, fixed. We had the same bug with FREEZE and ANALYZE combination, > which was fixed in April, but the order between FREEZE and VERBOSE was > still incorrect. The fact that this is order-sensitive is just a trap for the unwary anyway. I wonder if we ought to implement a flexible options syntax like we did for EXPLAIN and COPY, though since I don't know of any new options that are needed here maybe it's not worth it. ...Robert -- 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 #5123: bug in window function "last_value"
Andrey wrote: > select id, first_value(id) over(order by id), last_value(id) over(order by > id) from t; > > RESULT: > id | first_value | last_value > +-+ > 1 | 1 | 1 > 2 | 1 | 2 > 3 | 1 | 3 > (3 rows) > > fist_value - good, last_value - bad Looks ok to me. What did you expect? -- Heikki Linnakangas EnterpriseDB 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] vacuumdb error
2009/10/16 Robert Haas : > The fact that this is order-sensitive is just a trap for the unwary > anyway. I wonder if we ought to implement a flexible options syntax > like we did for EXPLAIN and COPY, though since I don't know of any new > options that are needed here maybe it's not worth it. > > ...Robert > I'd personally prefer options that could be used in any order as it means you only have to remember the keywords, not also the order of them as specified in the documentation. As long as the order doesn't affect the functioning of the command, I don't see the harm. It just makes it easier to use. Thom -- 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 #5122: Subqueries - inner select statement bug
Muris Pucic wrote: > -- The query below works, even though there is no column "first_name" in > TABLE2. This should return an error but it does not, it returns all rows > from TABLE1. This query should not evaluate correctly even when aliases are > not used because it can be misleading. > > SELECT * FROM TABLE1 WHERE first_name IN (SELECT first_name FROM TABLE2) Nope, it's working as expected. The first_name in the subquery is referring to the first_name column in the outer query. While it looks strange in a context like that, it's not an error. You wouldn't be able to write correlated subqueries otherwise, e.g: SELECT * FROM TABLE1 WHERE EXISTS (SELECT 1 FROM TABLE2 WHERE first_name = last_name) -- Heikki Linnakangas EnterpriseDB 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 #5122: Subqueries - inner select statement bug
"Muris Pucic" writes: > -- The query below works, even though there is no column "first_name" in > TABLE2. This should return an error but it does not, it returns all rows > from TABLE1. This query should not evaluate correctly even when aliases are > not used because it can be misleading. > SELECT * FROM TABLE1 WHERE first_name IN (SELECT first_name FROM TABLE2) This is not a bug, it's a perfectly legal outer reference. It is required to work that way by the SQL standard. If you think it's a bad design, take it up with the ISO standards committee. 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 #5123: bug in window function "last_value"
Heikki Linnakangas writes: > Andrey wrote: >> select id, first_value(id) over(order by id), last_value(id) over(order by >> id) from t; >> >> RESULT: >> id | first_value | last_value >> +-+ >> 1 | 1 | 1 >> 2 | 1 | 2 >> 3 | 1 | 3 >> (3 rows) >> >> fist_value - good, last_value - bad > Looks ok to me. What did you expect? These *are* the correct answers, since the default window frame runs from first row to current row. If you don't like them, you may need to specify a different window frame. 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 #5123: bug in window function "last_value"
2009/10/16 Tom Lane : > Heikki Linnakangas writes: >> Andrey wrote: >>> select id, first_value(id) over(order by id), last_value(id) over(order by >>> id) from t; >>> >>> RESULT: >>> id | first_value | last_value >>> +-+ >>> 1 | 1 | 1 >>> 2 | 1 | 2 >>> 3 | 1 | 3 >>> (3 rows) >>> >>> fist_value - good, last_value - bad > >> Looks ok to me. What did you expect? > > These *are* the correct answers, since the default window frame runs > from first row to current row. If you don't like them, you may need > to specify a different window frame. > > regards, tom lane > And it's well-documented. See http://www.postgresql.org/docs/8.4/static/functions-window.html -- Hitoshi Harada -- 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 #5118: start-status-insert-fatal
Pedro Gimeno wrote: > Tom Lane wrote: > >> This could be addressed by having the postmaster report its $PGDATA >> value in the pg_ping response, but I would be against that on >> security grounds. We don't let nonprivileged users know where >> PGDATA is, why would we make the information available without any >> authentication at all? > > Maybe a hash of it? I'm not really clear on why it's a security issue for someone to know the $PGDATA value, but if it is, there are some "typical" locations for which a hash could be generated and matched against the returned hash; so a hash of it would only be safe for those who chose sufficiently "creative" directory paths. On top of that, I'm not sure it's a very useful way to confirm that you've connected to the correct instance. We often get requests to replace the contents of a development or test database with a dump from a production database. More than once, the DBA doing this has forgotten to stop PostgreSQL before deleting the $PGDATA directory and creating it fresh for the restore of the PITR dump. When we attempt to start the new copy, which has the same $PGDATA, owner, and port number as the copy still running in the deleted directory, we have similar issues to those described in the original post. So, personally, I consider the data directory a less reliable test than the pid. (We don't have a lot of OS crash & reboot occurrences.) -Kevin -- 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 #5118: start-status-insert-fatal
On Fri, Oct 16, 2009 at 10:33 AM, Kevin Grittner wrote: > Pedro Gimeno wrote: >> Tom Lane wrote: >> >>> This could be addressed by having the postmaster report its $PGDATA >>> value in the pg_ping response, but I would be against that on >>> security grounds. We don't let nonprivileged users know where >>> PGDATA is, why would we make the information available without any >>> authentication at all? >> >> Maybe a hash of it? > > I'm not really clear on why it's a security issue for someone to know > the $PGDATA value, but if it is, there are some "typical" locations > for which a hash could be generated and matched against the returned > hash; so a hash of it would only be safe for those who chose > sufficiently "creative" directory paths. > > On top of that, I'm not sure it's a very useful way to confirm that > you've connected to the correct instance. We often get requests to > replace the contents of a development or test database with a dump > from a production database. More than once, the DBA doing this has > forgotten to stop PostgreSQL before deleting the $PGDATA directory and > creating it fresh for the restore of the PITR dump. When we attempt to > start the new copy, which has the same $PGDATA, owner, and port number > as the copy still running in the deleted directory, we have similar > issues to those described in the original post. So, personally, I > consider the data directory a less reliable test than the pid. (We > don't have a lot of OS crash & reboot occurrences.) Well, then Tom's idea of using a random number seems pretty solid no matter how you slice it. Maybe a UUID. ...Robert -- 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 #5118: start-status-insert-fatal
Robert Haas wrote: > Well, then Tom's idea of using a random number seems pretty solid no > matter how you slice it. Maybe a UUID. A random number is looking like the best option. I'm not sure why I'd want to generate a perfectly good 128 bit random number and then throw away six of the bits to dress it up as a UUID, though. Do the libraries for that do enough to introduce entropy to compensate for the lost bits? Any other benefit I'm missing? -Kevin -- 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 #5121: Segmentation Fault when using pam w/ krb5
Well, we certainly are not going to break pq_recvbuf in such a fundamental way as that ;-). I think that the more likely place to work around this is going to be in pam_passwd_conv_proc() in src/backend/libpq/auth.c. In particular, I see that when it gets a NULL from recv_password_packet (which is what's going to happen when pq_recvbuf returns EOF), it returns PAM_CONV_ERR without bothering to set *resp. I wonder whether we need to be initializing *resp to NULL, or even making it really valid? 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 #5118: start-status-insert-fatal
"Kevin Grittner" writes: > Robert Haas wrote: >> Well, then Tom's idea of using a random number seems pretty solid no >> matter how you slice it. Maybe a UUID. > A random number is looking like the best option. I'm not sure why I'd > want to generate a perfectly good 128 bit random number and then throw > away six of the bits to dress it up as a UUID, though. Do the > libraries for that do enough to introduce entropy to compensate for > the lost bits? Any other benefit I'm missing? I was envisioning just using PostmasterRandom() (after initializing the seed from time(NULL) as we do now). I don't think we need a super-wide random number. 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 #5118: start-status-insert-fatal
Tom Lane wrote: > I was envisioning just using PostmasterRandom() (after initializing > the seed from time(NULL) as we do now). I don't think we need a > super-wide random number. Fine with me. Just that and CanAcceptConnections in the response? It seems like pg_ping (client utility and related postmaster support) should be a discrete patch. Improvements to pg_ctl and init scripts would come later, as separate patches? -Kevin -- 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 #5118: start-status-insert-fatal
"Kevin Grittner" writes: > It seems like pg_ping (client utility and related postmaster support) > should be a discrete patch. Improvements to pg_ctl and init scripts > would come later, as separate patches? Sounds sane to me. Alternatively, do the postmaster support and make the presumably-minor pg_ctl mods to use it, and then a standalone pg_ping utility could come later. I'm not sure how big the utility would be, but surely bigger than the delta in pg_ctl. 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 #5118: start-status-insert-fatal
Tom Lane wrote: > Alternatively, do the postmaster support and make the > presumably-minor pg_ctl mods to use it, and then a standalone > pg_ping utility could come later. I'm not sure how big the utility > would be, but surely bigger than the delta in pg_ctl. Bigger than the delta for *just this change* to pg_ctl. I was thinking of addressing all pg_ctl issues at once, but perhaps this one makes sense on its own. If so, your alternative does sound better. -Kevin -- 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 #5121: Segmentation Fault when using pam w/ krb5
"Douglas, Ryan" writes: > Program terminated with signal 11, Segmentation fault. > #0 0x00559624 in pam_passwd_conv_proc () > Missing separate debuginfos, use: debuginfo-install > audit-libs-1.7.13-1.fc11.x86_64 > (gdb) bt > #0 0x00559624 in pam_passwd_conv_proc () > #1 0x7f738dfeedd8 in _pam_krb5_conv_call (pamh=, > messages=0xb51780, n_prompts=0, responses=0x7fff2e356668) at conv.c:99 > #2 0x7f738dfefb38 in _pam_krb5_generic_prompter (context= optimized out>, data=0x7fff2e357fe0, name=, > banner=, num_prompts=1, > prompts=, suppress_password_prompts=1) at > prompter.c:330 Actually, now that I look more closely at that stack trace, pam_passwd_conv_proc *is* a Postgres function --- so the core dump is happening when libpam calls us back. (I wonder why gdb failed to present any information about it? Are you using a stripped postgres executable?) In a quick look at the source for pam_passwd_conv_proc, the only very plausible explanation for why it would segfault in isolated cases seems to be that the initial sanity check on the passed-in message status might be assuming more than it should --- in particular it would obviously dump core if msg is null or msg[0] is null. I am thinking that maybe, when the KDC is Active Directory and there's no password supplied already, libpam makes additional calls to the conv_proc with parameter values that we're not prepared to handle. Can you add additional debug printouts or step through the code and verify what's happening there? 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 #5123: bug in window function "last_value"
On Fri, Oct 16, 2009 at 04:45:55PM +0300, Heikki Linnakangas wrote: > Andrey wrote: > > select id, first_value(id) over(order by id), last_value(id) over(order by > > id) from t; > > > > RESULT: > > id | first_value | last_value > > +-+ > > 1 | 1 | 1 > > 2 | 1 | 2 > > 3 | 1 | 3 > > (3 rows) > > > > fist_value - good, last_value - bad > > Looks ok to me. What did you expect? I think what the OP was expecting was to have the last value be 3 instead of changing. This is at least a POLA violation. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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 #5121: Segmentation Fault when using pam w/ krb5
"Douglas, Ryan" writes:
> I added some logging statements in the pam_passwd_conv_proc function and
> it gets as far as checking if the password is null then returning
> PAM_CONV_ERR.
That's what I would expect to happen if you don't use -W in psql.
What I suspect is happening with the MS KDC is that an additional
call to the conv_proc happens later with some parameter values that
we aren't prepared for. Can you stick some debugging printout
into the checks at the very top of the routine?
> if (passwd == NULL)
> ereport(LOG,(errmsg("RD - passwd
> is NULL... returning PAM_CONV_ERR")));
> return PAM_CONV_ERR;/* client didn't want to
> send password */
I think you need to add some braces if you don't want to break the
behavior here. This is C not Python ...
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 #5122: Subqueries - inner select statement bug
Muris Pucic wrote: > -- The query below works, even though there is no column "first_name" in > TABLE2. This should return an error but it does not, it returns all rows > from TABLE1. This query should not evaluate correctly even when aliases are > not used because it can be misleading. > > SELECT * FROM TABLE1 WHERE first_name IN (SELECT first_name FROM TABLE2) This is per spec -- first_name inside the subselect refers to the outer TABLE1. Misleading, yes. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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 #5121: Segmentation Fault when using pam w/ krb5
"Douglas, Ryan" writes: > Any tips on using gdb to step through the code? If you set pre_auth_delay to 30s or so in postgresql.conf, it'll slow things down enough so that you can get the backend's PID from "ps" and then attach to it with gdb. Then set a breakpoint at pam_passwd_conv_proc, continue, and away you go. You'll definitely want a debug-enabled postgres executable, though, which you did not seem to have before. 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 #5123: bug in window function "last_value"
David Fetter writes: > I think what the OP was expecting was to have the last value be 3 > instead of changing. This is at least a POLA violation. [ shrug... ] It's what the spec requires, as far as anybody here can tell. As Hitoshi-san already noted, we do point out in our docs that last_value is not too useful unless you use a nondefault window frame selection. I'm not sure what else we could do. 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 #5121: Segmentation Fault when using pam w/ krb5
I added some logging statements in the pam_passwd_conv_proc function and
it gets as far as checking if the password is null then returning
PAM_CONV_ERR.
if (strlen(appdata_ptr) == 0)
{
char *passwd;
sendAuthRequest(pam_port_cludge, AUTH_REQ_PASSWORD);
passwd = recv_password_packet(pam_port_cludge);
if (passwd == NULL)
ereport(LOG,(errmsg("RD - passwd
is NULL... returning PAM_CONV_ERR")));
return PAM_CONV_ERR;/* client didn't want to
send password */
if (strlen(passwd) == 0)
{
ereport(LOG,
(errmsg("empty password returned
by client")));
return PAM_CONV_ERR;
}
appdata_ptr = passwd;
}
- pg log -
<[unkno...@[unknown] 2009-10-16 12:16:07.033 EDT>LOG: connection
received: host=10.0.20.38 port=35945
LOG:
could not receive data from client: Connection reset by peer
LOG: RD
- passwd is NULL... returning PAM_CONV_ERR
<@ 2009-10-16 12:16:07.071 EDT>LOG: server process (PID 2176) was
terminated by signal 11: Segmentation fault
<@ 2009-10-16 12:16:07.071 EDT>LOG: terminating any other active
server processes
<@ 2009-10-16 12:16:07.074 EDT>LOG: all server processes terminated;
reinitializing
<@ 2009-10-16 12:16:07.194 EDT>LOG: database system was interrupted;
last known up at 2009-10-16 12:15:58 EDT
<@ 2009-10-16 12:16:07.195 EDT>LOG: database system was not properly
shut down; automatic recovery in progress
<@ 2009-10-16 12:16:07.196 EDT>LOG: record with zero length at
3/B7D75778
<@ 2009-10-16 12:16:07.196 EDT>LOG: redo is not required
<@ 2009-10-16 12:16:07.223 EDT>LOG: database system is ready to accept
connections
<@ 2009-10-16 12:16:07.223 EDT>LOG: autovacuum launcher started
-Ryan
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Friday, October 16, 2009 11:11 AM
To: Douglas, Ryan
Cc: pgsql-bugs@postgreSQL.org
Subject: Re: [BUGS] BUG #5121: Segmentation Fault when using pam w/ krb5
Well, we certainly are not going to break pq_recvbuf in such a
fundamental way as that ;-). I think that the more likely place
to work around this is going to be in pam_passwd_conv_proc() in
src/backend/libpq/auth.c. In particular, I see that when it gets
a NULL from recv_password_packet (which is what's going to happen
when pq_recvbuf returns EOF), it returns PAM_CONV_ERR without
bothering to set *resp. I wonder whether we need to be initializing
*resp to NULL, or even making it really valid?
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 #5121: Segmentation Fault when using pam w/ krb5
Any tips on using gdb to step through the code? [postg...@va-mp-db02 ~]$ file /usr/local/pgsql/bin/postgres /usr/local/pgsql/bin/postgres: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped Pg Log --- <[unkno...@[unknown] 2009-10-16 12:33:33.600 EDT>LOG: 0: connection received: host=10.0.20.38 port=57014 <[unkno...@[unknown] 2009-10-16 12:33:33.600 EDT>LOCATION: BackendInitialize, postmaster.c:3259 <[unkno...@[unknown] 10.0.20.38(57014) 2009-10-16 12:33:33.629 EDT>DEBUG: 0: SSL connection from "(anonymous)" <[unkno...@[unknown] 10.0.20.38(57014) 2009-10-16 12:33:33.629 EDT>LOCATION: open_server_SSL, be-secure.c:961 DEBUG: 0: SSL: read alert (0x0100) LOCATION: info_cb, be-secure.c:699 LOG: 08006: could not receive data from client: Connection reset by peer LOCATION: pq_recvbuf, pqcomm.c:769 LOG: 0: RD - passwd is NULL... returning PAM_CONV_ERR LOCATION: pam_passwd_conv_proc, auth.c:1906 <@ 2009-10-16 12:33:33.641 EDT>DEBUG: 0: reaping dead processes <@ 2009-10-16 12:33:33.641 EDT>LOCATION: reaper, postmaster.c:2236 <@ 2009-10-16 12:33:33.641 EDT>DEBUG: 0: server process (PID 2257) was terminated by signal 11: Segmentation fault <@ 2009-10-16 12:33:33.641 EDT>LOCATION: LogChildExit, postmaster.c:2725 <@ 2009-10-16 12:33:33.641 EDT>LOG: 0: server process (PID 2257) was terminated by signal 11: Segmentation fault <@ 2009-10-16 12:33:33.641 EDT>LOCATION: LogChildExit, postmaster.c:2725 <@ 2009-10-16 12:33:33.641 EDT>LOG: 0: terminating any other active server processes <@ 2009-10-16 12:33:33.641 EDT>LOCATION: HandleChildCrash, postmaster.c:2552 <@ 2009-10-16 12:33:33.641 EDT>DEBUG: 0: sending SIGQUIT to process 2251 <@ 2009-10-16 12:33:33.641 EDT>LOCATION: HandleChildCrash, postmaster.c:2621 <@ 2009-10-16 12:33:33.641 EDT>DEBUG: 0: sending SIGQUIT to process 2252 <@ 2009-10-16 12:33:33.641 EDT>LOCATION: HandleChildCrash, postmaster.c:2633 <@ 2009-10-16 12:33:33.641 EDT>DEBUG: 0: shmem_exit(-1): 0 callbacks to make <@ 2009-10-16 12:33:33.641 EDT>LOCATION: shmem_exit, ipc.c:197 <@ 2009-10-16 12:33:33.641 EDT>DEBUG: 0: proc_exit(-1): 0 callbacks to make <@ 2009-10-16 12:33:33.641 EDT>LOCATION: proc_exit_prepare, ipc.c:169 <@ 2009-10-16 12:33:33.641 EDT>DEBUG: 0: shmem_exit(-1): 0 callbacks to make <@ 2009-10-16 12:33:33.641 EDT>LOCATION: shmem_exit, ipc.c:197 <@ 2009-10-16 12:33:33.641 EDT>DEBUG: 0: proc_exit(-1): 0 callbacks to make <@ 2009-10-16 12:33:33.641 EDT>LOCATION: proc_exit_prepare, ipc.c:169 <@ 2009-10-16 12:33:33.643 EDT>DEBUG: 0: sending SIGQUIT to process 2253 <@ 2009-10-16 12:33:33.643 EDT>LOCATION: HandleChildCrash, postmaster.c:2645 <@ 2009-10-16 12:33:33.643 EDT>DEBUG: 0: sending SIGQUIT to process 2254 <@ 2009-10-16 12:33:33.643 EDT>LOCATION: HandleChildCrash, postmaster.c:2675 <@ 2009-10-16 12:33:33.643 EDT>DEBUG: 0: shmem_exit(-1): 0 callbacks to make <@ 2009-10-16 12:33:33.643 EDT>LOCATION: shmem_exit, ipc.c:197 <@ 2009-10-16 12:33:33.643 EDT>DEBUG: 0: proc_exit(-1): 0 callbacks to make <@ 2009-10-16 12:33:33.643 EDT>LOCATION: proc_exit_prepare, ipc.c:169 <@ 2009-10-16 12:33:33.643 EDT>DEBUG: 0: shmem_exit(-1): 0 callbacks to make <@ 2009-10-16 12:33:33.643 EDT>LOCATION: shmem_exit, ipc.c:197 <@ 2009-10-16 12:33:33.643 EDT>DEBUG: 0: proc_exit(-1): 0 callbacks to make <@ 2009-10-16 12:33:33.643 EDT>LOCATION: proc_exit_prepare, ipc.c:169 <@ 2009-10-16 12:33:33.644 EDT>DEBUG: 0: reaping dead processes <@ 2009-10-16 12:33:33.644 EDT>LOCATION: reaper, postmaster.c:2236 <@ 2009-10-16 12:33:33.644 EDT>DEBUG: 0: reaping dead processes <@ 2009-10-16 12:33:33.644 EDT>LOCATION: reaper, postmaster.c:2236 <@ 2009-10-16 12:33:33.644 EDT>LOG: 0: all server processes terminated; reinitializing -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, October 16, 2009 12:19 PM To: Douglas, Ryan Cc: pgsql-bugs@postgreSQL.org Subject: Re: [BUGS] BUG #5121: Segmentation Fault when using pam w/ krb5 "Douglas, Ryan" writes: > Program terminated with signal 11, Segmentation fault. > #0 0x00559624 in pam_passwd_conv_proc () > Missing separate debuginfos, use: debuginfo-install audit-libs-1.7.13-1.fc11.x86_64 > (gdb) bt > #0 0x00559624 in pam_passwd_conv_proc () > #1 0x7f738dfeedd8 in _pam_krb5_conv_call (pamh=, messages=0xb51780, n_prompts=0, responses=0x7fff2e356668) at conv.c:99 > #2 0x7f738dfefb38 in _pam_krb5_generic_prompter (context=, data=0x7fff2e357fe0, name=, banner=, num_prompts=1, > prompts=, suppress_password_prompts=1) at prompter.c:330 Actually, now that I look more closely at that stack trace, pam_passwd_conv_proc *is* a Postgres function --- so the core dump is happening when libpam calls us back. (I wonder why gdb failed to present any information about it? Are you using a strippe
Re: [BUGS] BUG #5118: start-status-insert-fatal
On Fri, Oct 16, 2009 at 11:08 AM, Kevin Grittner wrote: > Robert Haas wrote: > >> Well, then Tom's idea of using a random number seems pretty solid no >> matter how you slice it. Maybe a UUID. > > A random number is looking like the best option. I'm not sure why I'd > want to generate a perfectly good 128 bit random number and then throw > away six of the bits to dress it up as a UUID, though. Do the > libraries for that do enough to introduce entropy to compensate for > the lost bits? Any other benefit I'm missing? I'm confused. UUIDs throw away 6 bits? Anyway, some smaller random number might be fine, too - not trying to throw a monkey wrench into the process. ...Robert -- 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 #5121: Segmentation Fault when using pam w/ krb5
I wrote: > The best idea I can come up with is that the conv_proc is being called > with zero messages and is dumping core because it tries to print the > contents of msg[0]. However, it's far from clear why libpam would > bother to call it with zero messages. Hah --- found it. (Man, it is so nice working with open source that you can actually look at...) prompter.c in pam_krb5 has /* Skip any prompt for which the supplied default answer is the * previously-entered password -- it's just a waste of the * user's time. */ So it definitely is possible to call our proc with zero messages, and whether this will happen or not is probably dependent on the behavior of the KDC, and even then, ereport might or might not dump core depending on the contents of the not-allocated msg[0] array member. I will go and rewrite this function to look more like openssh's, on the assumption that their version is probably pretty well battle tested. 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 #5121: Segmentation Fault when using pam w/ krb5
2009/10/16 Tom Lane : > I wrote: >> The best idea I can come up with is that the conv_proc is being called >> with zero messages and is dumping core because it tries to print the >> contents of msg[0]. However, it's far from clear why libpam would >> bother to call it with zero messages. > > Hah --- found it. (Man, it is so nice working with open source that > you can actually look at...) prompter.c in pam_krb5 has > > /* Skip any prompt for which the supplied default answer is the > * previously-entered password -- it's just a waste of the > * user's time. */ > > So it definitely is possible to call our proc with zero messages, and > whether this will happen or not is probably dependent on the behavior > of the KDC, and even then, ereport might or might not dump core depending > on the contents of the not-allocated msg[0] array member. > > I will go and rewrite this function to look more like openssh's, > on the assumption that their version is probably pretty well battle > tested. Yeah, that sounds like a reasonable thing to do. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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 #5118: start-status-insert-fatal
Robert Haas wrote: > UUIDs throw away 6 bits? http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_4_.28random.29 -Kevin -- 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] Re: BUG #5065: pg_ctl start fails as administrator, with "could not locate matching postgres executable"
> -Original Message- > From: Dave Page [mailto:dp...@pgadmin.org] > Sent: Friday, October 16, 2009 2:14 AM > To: Jesse Morris > Cc: pgsql-bugs@postgresql.org > Subject: Re: [BUGS] Re: BUG #5065: pg_ctl start fails as administrator, > with "could not locate matching postgres executable" > > > The patch: > > > > --begin patch-- > > :-(. Unfortunately inlining the patch in the email has munged it > beyond usability. Can you resend it as an attachment please? Oops! Re-sent, as an attachment. postgres-bug-5065.patch Description: postgres-bug-5065.patch -- 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 #5118: start-status-insert-fatal
On Fri, Oct 16, 2009 at 2:04 PM, Kevin Grittner wrote: > Robert Haas wrote: > >> UUIDs throw away 6 bits? > > http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_4_.28random.29 How about that. You learn something new every day. ...Robert -- 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 #5121: Segmentation Fault when using pam w/ krb5
"Douglas, Ryan" writes:
>You were right. According to the trace msg[0] is null.
Hah. This must be triggered by something Active Directory does that
a KDC doesn't, because I'm still not seeing it here. But anyway the
problem is clear now, we have to avoid referencing msg[0] when num_msg
is zero.
Please try the attached patch and see if it behaves sanely for you.
This is based on openssh's PAM callback, so it ought to be more
robust than what we had. (This is against 8.4 branch tip, but it
should apply to 8.4.1 with maybe a few lines' offset.)
regards, tom lane
Index: auth.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.183.2.2
diff -c -r1.183.2.2 auth.c
*** auth.c 14 Oct 2009 22:10:01 - 1.183.2.2
--- auth.c 16 Oct 2009 20:08:39 -
***
*** 441,447
case uaPAM:
#ifdef USE_PAM
- pam_port_cludge = port;
status = CheckPAMAuth(port, port->user_name, "");
#else
Assert(false);
--- 441,446
***
*** 1880,1940
pam_passwd_conv_proc(int num_msg, const struct pam_message ** msg,
struct pam_response ** resp, void *appdata_ptr)
{
! if (num_msg != 1 || msg[0]->msg_style != PAM_PROMPT_ECHO_OFF)
! {
! switch (msg[0]->msg_style)
! {
! case PAM_ERROR_MSG:
! ereport(LOG,
! (errmsg("error from underlying PAM layer: %s",
! msg[0]->msg)));
! return PAM_CONV_ERR;
! default:
! ereport(LOG,
! (errmsg("unsupported PAM conversation %d/%s",
! msg[0]->msg_style, msg[0]->msg)));
! return PAM_CONV_ERR;
! }
! }
! if (!appdata_ptr)
{
/*
* Workaround for Solaris 2.6 where the PAM library is broken and does
* not pass appdata_ptr to the conversation routine
*/
! appdata_ptr = pam_passwd;
}
! /*
! * Password wasn't passed to PAM the first time around - let's go ask the
! * client to send a password, which we then stuff into PAM.
! */
! if (strlen(appdata_ptr) == 0)
! {
! char *passwd;
!
! sendAuthRequest(pam_port_cludge, AUTH_REQ_PASSWORD);
! passwd = recv_password_packet(pam_port_cludge);
! if (passwd == NULL)
! return PAM_CONV_ERR; /* client didn't want to send password */
!
! if (strlen(passwd) == 0)
! {
! ereport(LOG,
! (errmsg("empty password returned by client")));
! return PAM_CONV_ERR;
! }
! appdata_ptr = passwd;
! }
/*
* Explicitly not using palloc here - PAM will free this memory in
* pam_end()
*/
! *resp = calloc(num_msg, sizeof(struct pam_response));
! if (!*resp)
{
ereport(LOG,
(errcode(ERRCODE_OUT_OF_MEMORY),
--- 1879,1909
pam_passwd_conv_proc(int num_msg, const struct pam_message ** msg,
struct pam_response ** resp, void *appdata_ptr)
{
! char *passwd;
! struct pam_response *reply;
! int i;
! if (appdata_ptr)
! passwd = (char *) appdata_ptr;
! else
{
/*
* Workaround for Solaris 2.6 where the PAM library is broken and does
* not pass appdata_ptr to the conversation routine
*/
! passwd = pam_passwd;
}
! *resp = NULL;/* in case of error exit */
! if (num_msg <= 0 || num_msg > PAM_MAX_NUM_MSG)
! return PAM_CONV_ERR;
/*
* Explicitly not using palloc here - PAM will free this memory in
* pam_end()
*/
! if ((reply = calloc(num_msg, sizeof(struct pam_response))) == NULL)
{
ereport(LOG,
(errcode(ERRCODE_OUT_OF_MEMORY),
***
*** 1942,1951
return PAM_CONV_ERR;
}
! (*resp)[0].resp = strdup((char *) appdata_ptr);
! (*resp)[0].resp_retcode = 0;
! return ((*resp)[0].resp ? PAM_SUCCESS : PAM_CONV_ERR);
}
--- 1911,1981
return PAM_CONV_ERR;
}
! for (i = 0; i < num_msg; i++)
! {
! switch (msg[i]->msg_style)
! {
! case PAM_PROMPT_ECHO_OFF:
! if (strlen(passwd) == 0)
! {
! /*
! * Password wasn't passed to PAM the first time around -
! * let's go ask the client to send a password, which we
! * then stuff into PAM.
! */
! sendAuthRequest(pam_port_cludge, AUTH_REQ_PASSWORD);
! passwd = recv_password_packet(pam_port_cludge);
! if (passwd == NULL)
! {
! /*
! * Client didn't want to send password. We
! * intentionally do not log anything about this.
! */
! goto fail;
! }
! if (strlen(passwd) == 0)
! {
! ereport(LOG,
! (errmsg("empty password returned by client")));
! goto fail;
! }
! }
! if ((reply[i].resp = strdup(passwd)) == NULL)
! goto fail;
! reply[i].resp_retcode = PAM_SUCCESS;
! break;
! case PAM_ERROR_MSG:
! ereport(LOG,
! (errmsg("error from underlying PAM layer: %s",
! msg[i]->msg)));
! /* FALL THROUGH */
! case PAM_TEXT_INFO:
! /* we don't bother to log TEXT_INFO messages */
! if ((reply[i].resp = strdup("")) == NULL)
Re: [BUGS] BUG #5123: bug in window function "last_value"
On Fri, Oct 16, 2009 at 01:28:57PM -0400, Tom Lane wrote: > David Fetter writes: > > I think what the OP was expecting was to have the last value be 3 > > instead of changing. This is at least a POLA violation. > > [ shrug... ] It's what the spec requires, as far as anybody here > can tell. As Hitoshi-san already noted, we do point out in our docs > that last_value is not too useful unless you use a nondefault window > frame selection. I'm not sure what else we could do. Perhaps an illustration of the issue and a workaround in the docs? Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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 #5121: Segmentation Fault when using pam w/ krb5
Tom, You were right. According to the trace msg[0] is null. (gdb) set follow-fork-mode child (gdb) c Continuing. [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f5a6c2b77b0 (LWP 23208)] 0x00580cf4 in pam_passwd_conv_proc (num_msg=0, msg=0x21015a0, resp=0x7fff5955a0b8, appdata_ptr=0x7f20c7) at auth.c:1868 1868auth.c: No such file or directory. in auth.c (gdb) backtrace #0 0x00580cf4 in pam_passwd_conv_proc (num_msg=0, msg=0x21015a0, resp=0x7fff5955a0b8, appdata_ptr=0x7f20c7) at auth.c:1868 #1 0x7f59e36f8dd8 in _pam_krb5_conv_call (pamh=, messages=0x2101490, n_prompts=0, responses=0x7fff5955a0b8) at conv.c:99 #2 0x7f59e36f9b38 in _pam_krb5_generic_prompter ( context=, data=0x7fff5955ba30, name=, banner=, num_prompts=1, prompts=, suppress_password_prompts=1) at prompter.c:330 #3 0x7f59e36f9e10 in _pam_krb5_normal_prompter (context=0x0, data=0x21015a0, name=0x7fff5955a0b8 "", banner=0x7f20c7 "", num_prompts=0, prompts=0x101010101010101) at prompter.c:409 #4 0x0031d3660bce in krb5_get_as_key_password (context=0x20fe420, client=, etype=23, prompter=, prompter_data=, salt=0x7fff5955a950, params=0x7fff5955a940, as_key=0x7fff5955a910, gak_data=0x7fff5955ab70) at gic_pwd.c:61 #5 0x0031d3667713 in pa_enc_timestamp (context=0x20fe420, request=, in_padata=, out_padata=0x7fff5955a780, salt=, s2kparams=, etype=0x7fff5955a99c, as_key=0x7fff5955a910, prompter=0x7f59e36f9e00 <_pam_krb5_normal_prompter>, prompter_data=0x7fff5955ba30, ---Type to continue, or q to quit--- gak_fct=0x31d36609f0 , gak_data=0x7fff5955ab70) at preauth2.c:635 #6 0x0031d3667e0c in krb5_do_preauth (context=, request=0x7fff5955a890, encoded_request_body=, encoded_previous_request=, in_padata=0x2100ac0, out_padata=, salt=0x7fff5955a950, s2kparams=0x7fff5955a940, etype=0x7fff5955a99c, as_key=0x7fff5955a910, prompter=0x7f59e36f9e00 <_pam_krb5_normal_prompter>, prompter_data=0x7fff5955ba30, gak_fct=0x31d36609f0 , gak_data=0x7fff5955ab70, get_data_rock=0x7fff5955a930, opte=0x20fe960) at preauth2.c:1586 #7 0x0031d365f251 in krb5_get_init_creds (context=0x20fe420, creds=, client=, prompter=, prompter_data=, start_time=, in_tkt_service=0x7fff5955baa0 "krbtgt/thexchange@thexchange.com", options=0x20fe960, gak_fct=0x31d36609f0 , gak_data=0x7fff5955ab70, use_master=0x7fff5955abac, as_reply=0x7fff5955aba0) at get_in_tkt.c:1106 #8 0x0031d3660f18 in krb5_get_init_creds_password (context=0x20fe420, creds=, client=, password=, prompter=0x7f59e36f9e00 <_pam_krb5_normal_prompter>, data=, start_time=0, ---Type to continue, or q to quit--- in_tkt_service=0x7fff5955baa0 "krbtgt/thexchange@thexchange.com", options=0x20fe960) at gic_pwd.c:139 #9 0x7f59e36ff571 in v5_get_creds (ctx=0x20fe420, pamh=, creds=, user=, userinfo=0x20fecf0, options=0x20fe9c0, service=0x7f59e3703bf8 "krbtgt", password=0x0, gic_options=0x20fe960, prompter=0x7f59e36f9e00 <_pam_krb5_normal_prompter>, result=0x21002d4) at v5.c:1014 #10 0x7f59e36f53cf in pam_sm_authenticate (pamh=0x210f5a0, flags=0, argc=, argv=) at auth.c:423 #11 0x0031d0202c1e in _pam_dispatch_aux ( use_cached_chain=, resumed=, h=, flags=, pamh=) at pam_dispatch.c:110 #12 _pam_dispatch (use_cached_chain=, resumed=, h=, flags=, pamh=) at pam_dispatch.c:407 #13 0x0031d0202500 in pam_authenticate (pamh=0x210f5a0, flags=0) at pam_auth.c:34 #14 0x005810d1 in CheckPAMAuth (user=, port=, password=) at auth.c:1999 #15 ClientAuthentication (user=, port=, password=) at auth.c:430 ---Type to continue, or q to quit--- #16 0x005e035c in BackendInitialize (port=0x20fd460) at postmaster.c:3324 #17 0x005e0c3c in BackendStartup (port=) at postmaster.c:3058 #18 ServerLoop (port=) at postmaster.c:1387 #19 0x005e354d in PostmasterMain (argc=1, argv=0x20b9010) at postmaster.c:1040 #20 0x00588900 in main (argc=1, argv=0x20b9010) at main.c:188 (gdb) print num_msg $1 = 0 (gdb) print msg[0] $2 = (const struct pam_message *) 0x0 (gdb) -Original Message- From: Magnus Hagander [mailto:mag...@hagander.net] Sent: Friday, October 16, 2009 2:05 PM To: Tom Lane Cc: Douglas, Ryan; pgsql-bugs Subject: Re: [BUGS] BUG #5121: Segmentation Fault when using pam w/ krb5 2009/10/16 Tom Lane : > I wrote: >> The best idea I can come up with is that the conv_proc is being called >> with zero messages and is dumping core because it tries to print the >> contents of msg[0]. However, it's far from clear why libpam would >> bother to call it with zero messages. > > Hah --- found it. (Man, it is so nice working with open source that > you can actually look at...) prompter.c in pam_krb5 has > > /* Skip
Re: [BUGS] BUG #5121: Segmentation Fault when using pam w/ krb5
It works like champ... cool.. thanks. -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, October 16, 2009 4:15 PM To: Douglas, Ryan Cc: Magnus Hagander; pgsql-bugs Subject: Re: [BUGS] BUG #5121: Segmentation Fault when using pam w/ krb5 "Douglas, Ryan" writes: >You were right. According to the trace msg[0] is null. Hah. This must be triggered by something Active Directory does that a KDC doesn't, because I'm still not seeing it here. But anyway the problem is clear now, we have to avoid referencing msg[0] when num_msg is zero. Please try the attached patch and see if it behaves sanely for you. This is based on openssh's PAM callback, so it ought to be more robust than what we had. (This is against 8.4 branch tip, but it should apply to 8.4.1 with maybe a few lines' offset.) 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
[BUGS] BUG #5124: visualizacion de registros
The following bug has been logged online: Bug reference: 5124 Logged by: malu Email address: maluulam_l...@yahoo.com.mx PostgreSQL version: 8.3 Operating system: windows xp proffeional Description:visualizacion de registros Details: Hola que tal, buen dia, veran estoy importando una archivo tipo CSV a una tabla de postgres, la importacion es correcta, la ejecuta bien , pero al momento de pedirle que muestre la informacion no muestra nada, considero yo que es por el numero de registros, ya que son 80 registros los que riene a tabla, no se si me puedan ayudar como hacer que se guardenbien los registros en la tabla para que pueda manipularla. Gracias por su atencion Saludos -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
