Re: [BUGS] initdb fail to execute
On Sunday, May 05, 2013 1:15 AM Jinu K J wrote: Hi, We are trying install postgresql 9.2.3 version for windows xp. Below issue happen only for this particular PC. Other windows XP installations are ok. Here initdb command failed mentioning that , it is able to find postgres , but version mismatched. Can you please check is there any other version of postgres present in the machine? Regards, Hari babu.
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
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 Janesjeff.ja...@gmail.com wrote: On Sat, Apr 6, 2013 at 1:24 AM, Heikki Linnakangas hlinnakan...@vmware.comwrote: 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
[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 #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
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
