[BUGS] Concurrent CREATE USER MAPPING and DROP SERVER
Hello. I think I may have found a bug in the CREATE USER MAPPING / DROP SERVER handling. It is possible to create a user mapping on a server and drop said server in two concurrent transactions, and have both succeed. This results in an orphan row in the pg_user_mapping table. I would expect one of those transactions to fail. This is more easily explained with the following example: CREATE extension postgres_fdw; CREATE server pg_server FOREIGN DATA WRAPPER postgres_fdw -- SESSION 1 BEGIN; CREATE USER MAPPING FOR postgres SERVER pg_server OPTIONS (user 'user'); -- SESSION 2 BEGIN; DROP SERVER pg_server; -- SESSION 1 COMMIT; -- SESSION 2 COMMIT; select umserver, s.oid from pg_user_mapping left join pg_foreign_server s on s.oid = pg_user_mapping.umserver; ┌──┬─┐ │ umserver │ oid │ ├──┼─┤ │62172 │ ¤ │ └──┴─┘ -- 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 #8285: Unable to install the pgAgent
The following bug has been logged on the website: Bug reference: 8285 Logged by: Manish Roy Email address: manish@quipment.in PostgreSQL version: 9.2.1 Operating system: Windows 7 Description: Hello, I was trying to install the pgAgent in my windows system to create the job in PostGreSQL. But unfortunately the steps specified in this http://www.pgadmin.org/docs/1.4/pgagent-install.html; is not helping me out in installation of agent. It will be really grateful if anyone can help me out in the installation of a agent in postgresql. Thanks -- 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] Concurrent CREATE USER MAPPING and DROP SERVER
Ronan Dunklau rdunk...@gmail.com writes: It is possible to create a user mapping on a server and drop said server in two concurrent transactions, and have both succeed. There are lots of hazards of this sort, since we generally don't try to lock database objects other than tables when doing DDL. I can't get particularly excited about this one compared to the rest. We could try to extend the table-locking protocols to apply to all object types ... but from here, the amount of work and complexity involved seems far out of proportion to the benefit. 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] Re: windows 8 RTM compatibility issue (could not reserve shared memory region for child)
Hi Dave, On Tue, Sep 04, 2012 at 11:45:47PM -0400, Dave Vitek wrote: LOG: could not reserve shared memory region (addr=0141) for child 0F8C: 487 LOG: could not fork new process for connection: A blocking operation was interrupted by a call to WSACancelBlockingCall. So why hasn't this ever happened before? I'm guessing that ASLR got better in the latest windows 8 patch, or maybe there's just more stuff in the virtual address space of a newborn process. One straightforward fix is to specify a hardcoded address to MapViewOfFileEx instead of NULL. This address should be carefully selected such that it is in an area disjoint from the portions of the address space that are potentially reserved in a newborn process, and also unlikely to be in use inside the postmaster when it first maps the shared memory. This is pretty trivial to do for a particular version/configuration of Windows. However, I see no future-proof solution (besides making the shared segment position independent). If the hardcoded address is not available, you can always fall back on the current behavior. Given the strong dedication to backward-compatibility in Windows, I would expect a way to bypass the new ASLR measures. Some web searching suggests linking postgres.exe with /highentropyva:no and/or /dynamicbase:no might help, but nothing conclusive. Thoughts? That would be preferable to relying on experimentally-derived safe addresses, which could cease to be safe after a mere Windows update or similar. There is a security problem with the fix I outline above. It bypasses ASLR to a limited degree, since the shared memory would likely end up always living at the same address. I am not certain that MapViewOfFile even tries to be unpredictable, but let's assume it does or will be someday. I wouldn't worry about it too much. ASLR is a defense-in-depth measure; it comes into play when your software already has a flaw and potentially reduces the impact of that flaw. I've attached a patch that implements the stuff above. I can share the code for the program that tests whether an address is reliably available in a newborn postgres process, if anyone is interested. Great detective work. Seeing that program could be helpful. Thanks, nm -- Noah Misch 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 #7709: psql \copy csv terminates with \. in quoted region
On Tue, Nov 27, 2012 at 12:33:44PM -0500, Tom Lane wrote:
tgarn...@panjiva.com writes:
psql \copy terminates at \. by itself in a line even if the format is csv
and the \. is inside a quoted region. This means that some values can't be
round-tripped by psql \copy. Tested and the native postgresql COPY handles
this case correctly.
Ugh. This seems like a rather fundamental oversight in the CSV feature.
The problem is that psql has no idea whether the copy is being done in
CSV mode or not --- and even if it did, it doesn't parse the data fully
enough to realize whether a \. line is inside quotes or not.
In the case of out-of-line data files, it might be reasonable to just
dispense with the check for \. altogether and always ship the whole file
to the backend; I think there's a \. check on the backend side. (Not
sure this is safe in V2 protocol, but I doubt anyone cares anymore
about that.)
In the case of in-line data in a script file, CSV mode seems a bit
broken in any case; there's no concept of a terminator in CSV, AFAIK.
So maybe we don't have to worry about that.
I have added a C comment documenting this bug; patch attached.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/bin/psql/copy.c b/src/bin/psql/copy.c
new file mode 100644
index b5732c7..c1e7cfe
*** a/src/bin/psql/copy.c
--- b/src/bin/psql/copy.c
*** handleCopyIn(PGconn *conn, FILE *copystr
*** 635,640
--- 635,645
/* check for EOF marker, but not on a partial line */
if (firstload)
{
+ /*
+ * This code erroneously assumes '\.' on a line alone
+ * inside a quoted CSV string terminates the \copy.
+ * http://www.postgresql.org/message-id/e1tdnvq-0001ju...@wrigleys.postgresql.org
+ */
if (strcmp(buf, \\.\n) == 0 ||
strcmp(buf, \\.\r\n) == 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] Stalled post to pgsql-bugs
After further testing, this test case should be refined to throw NO_DATA_FOUND errors from the INTO STRICT clause to produce the memory leak. In pl_exec.c, exec_stmt_execsql does not free the SPI_tuptable by calling SPI_freetuptable before the ereport. Attached is a patch to 9.2-STABLE that seems to resolve it. pl_exec.diff Description: Binary data valgrind.out Description: Binary data -- 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 #8286: severe bug in auth
The following bug has been logged on the website: Bug reference: 8286 Logged by: Eike Dierks Email address: e...@inter.net PostgreSQL version: 9.2.4 Operating system: CentOS release 6.4 Description: I believe to have found a severe bug in auth. I don't want to post that here. Please contact me. ~eike -- 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 #8286: severe bug in auth
On Fri, Jul 5, 2013 at 8:11 AM, e...@inter.net wrote: The following bug has been logged on the website: Bug reference: 8286 Logged by: Eike Dierks Email address: e...@inter.net PostgreSQL version: 9.2.4 Operating system: CentOS release 6.4 Description: I believe to have found a severe bug in auth. I don't want to post that here. If you need to report a security problem, please use the steps described here to take proper actions: http://www.postgresql.org/support/security/ -- Michael -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
