Re: [BUGS] BUG #8139: initdb: Misleading error message when current user not in /etc/passwd
Tom Lane wrote: > nico...@marchildon.net writes: > > The man page says: > > > RETURN VALUE > >The getpwnam() and getpwuid() functions return a pointer to a > > passwd > >structure, or NULL if the matching entry is not found or an > > error > >occurs. If an error occurs, errno is set appropriately. If one > > wants > >to check errno after the call, it should be set to zero before > > the > >call. > > AFAICS, getpwuid is not honoring its specification here: it failed to > set errno. I don't see that suppressing the strerror result would add > anything much. Well, in this case no error occured, but no matching entry was found. The wording in the manpage is explicit that there not being an entry is not an error. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & 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] BUG #8139: initdb: Misleading error message when current user not in /etc/passwd
nico...@marchildon.net writes:
> "initdb: could not obtain information about current user: Success"
> The misleading part is the "Success". This comes from errno:
> pw = getpwuid(geteuid());
> if (!pw)
> {
> fprintf(stderr,
> _("%s: could not obtain information about current
> user: %s\n"),
> progname, strerror(errno));
> exit(1);
> }
> The man page says:
> RETURN VALUE
>The getpwnam() and getpwuid() functions return a pointer to a
> passwd
>structure, or NULL if the matching entry is not found or an
> error
>occurs. If an error occurs, errno is set appropriately. If one
> wants
>to check errno after the call, it should be set to zero before
> the
>call.
AFAICS, getpwuid is not honoring its specification here: it failed to
set errno. I don't see that suppressing the strerror result would add
anything much.
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 #8139: initdb: Misleading error message when current user not in /etc/passwd
The following bug has been logged on the website:
Bug reference: 8139
Logged by: Nicolas Marchildon
Email address: nico...@marchildon.net
PostgreSQL version: 9.2.4
Operating system: RHEL 6
Description:
Running initdb while logged in as a user that has no entry in /etc/passwd,
which happens when authenticating with Kerberos, and missing sssd-client
prints a misleading error message:
"initdb: could not obtain information about current user: Success"
The misleading part is the "Success". This comes from errno:
pw = getpwuid(geteuid());
if (!pw)
{
fprintf(stderr,
_("%s: could not obtain information about current
user: %s\n"),
progname, strerror(errno));
exit(1);
}
The man page says:
RETURN VALUE
The getpwnam() and getpwuid() functions return a pointer to a
passwd
structure, or NULL if the matching entry is not found or an
error
occurs. If an error occurs, errno is set appropriately. If one
wants
to check errno after the call, it should be set to zero before
the
call.
First, initdb's get_id function does not set errno to zero, which is a bug.
Second, when the return value is NULL, it should only print strerror(errno)
when errno != 0.
--
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 #8043: 9.2.4 doesn't open WAL files from archive, only looks in pg_xlog
On 08.04.2013 18:58, Jeff Bohmer wrote: On Apr 6, 2013, at 1:24 PM, Jeff Janes wrote: On Sat, Apr 6, 2013 at 1:24 AM, Heikki Linnakangas wrote: Perhaps we should improve the documentation to make it more explicit that backup_label must be included in the backup. The docs already say that, though, so I suspect that people making this mistake have not read the docs very carefully anyway. I don't think the docs are very clear on that. They say "This file will of course be archived as a part of your backup dump file", but "will be" does not imply "must be". Elsewhere it emphasizes that the label you gave to pg_start_backup is written into the file, but doesn't really say what the file itself is there for. To me it seems to imply that the file is there for your convenience, to hold that label, and not as a critical part of the system. Patch attached, which I hope can be back-patched. I'll also add it to commitfest-Next. I think this documentation update would be helpful. Committed that. - Heikki -- 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 #8127: After failed insert a select to figure out what failed is rejected
On Monday, April 29, 2013 4:54 PM matti aarnio wrote: > The following bug has been logged on the website: > > Bug reference: 8127 > Logged by: Matti Aarnio > Email address: matti.aar...@methics.fi > PostgreSQL version: 9.2.4 > Operating system: Fedora 18 > Description: > > With table: > > CREATE TABLE demo ( > pkey INTEGER PRIMARY KEY, > key2 VARCHAR UNIQUE, > key3 VARCHAR UNIQUE > ); > > An insert that fails secondary constraint key does return SQL State > 23505, > and maybe an explanation message telling that "Key (key3)=".. " is > duplicate." > > With Oracle we ask a SELECT after such an error on that table for all > possibly existing secondary keys values, and get them to report > detailed > conflict information. > > With PostgreSQL we get following error on those error analysis SELECTs: > ERROR: current transaction is aborted, > commands ignored until end of transaction block > > Could PostgreSQL be similarly permissive (with respect of Oracle) > allowing > SELECTs within same transaction context that was already rejected? As per current implementation PostgreSQL behavior is different from Oracle in the scenario mentioned by you. However you can try by using Savepoint before failing statement and then after failure do Rollback To Savepoint_name and then call your select statement. This will make you select statement run in top transaction context. With Regards, Amit Kapila. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
