Re: [BUGS] [PATCH v2] Use CC atomic builtins as a fallback
Hello Tom, all, Tom Lane [2011-12-20 21:14 -0500]: > Getting this thread back to the original patch ... I'm afraid that if we > apply this as-is, what will happen is that we fix ARMv7 and break older > versions. Right, I guess it's dependent on the compiler version, too. That's why my original patch tested for this first and used it if it was available, then we can have any code in the #else part further down. > So I'm thinking that removing the swpb ASM option is not such a good > idea. We could possibly test for __sync_lock_test_and_set first, and > only use swpb if we're on ARM and don't have the builtin. OK, that would be kind of a hybrid solution between the first and second version of the patch. Can work on this (but only next year, need to do some christmas prep, and then holidays/AFK). > Another thing that is bothering me is that according to the gcc > manual, eg here, > http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html > __sync_lock_test_and_set is nominally provided for datatypes 1, 2, > 4, or 8 bytes in length, but the underlying hardware doesn't > necessarily support all those widths natively. If you pick the > wrong width then you don't get an inline operation at all, but a > call to some possibly inefficient library subroutine. It's even worse. Our original version of the patch used a char, and while that worked fine on the older Babbage board, it completely broke at runtime on e. g. a Panda board. It wasn't just slow, it caused hangs and test failures all over the place. With int it works flawlessly. > I see that your patch just assumes that "int" will be a good width > for the lock type, but it's unclear to me what that choice is based > on and whether or not it might be a really bad choice on some > platforms. Unfortunately the gcc documentation doesn't give any further conditions. As an "int" is usually meant to fit the standard word size of a processor, if that function call/machine op code supports just one datatype, it will most likely be "int", not something which you have to mask on read/write (char) or potentially involves multiple words (long/long long). The intel definition [1] (and also in above gcc doc) says "32 or 64 bit integer", which also matches "int" (unless we are looking at some really small architectures like the old Atmels with their 16 bit words, but these are three magnitudes too small for PostgreSQL anyway :) ) So with the intel compiler "char" is clearly forbidden. Beyond that I don't have any further data. So, I'm happy with keeping this patch in Debian/Ubuntu only for the time being, as there we have a pretty clear idea of the supported ARM platforms, and can actually test the patches on all the platforms. I just found it prudent to at least bring it up here. Thanks, and happy end-of-year holidays! Martin [1] http://www.cs.fsu.edu/~engelen/courses/HPC-adv/intref_cls.pdf p. 198 -- Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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] Incorrect comment in heapam.c
On 20 December 2011 18:11, Tom Lane wrote: > Simon Riggs writes: >> On Tue, Dec 20, 2011 at 5:50 PM, Peter Geoghegan >> wrote: >>> In fact, that macro is defined in access/htup.h...should it be? > >> IMHO comment is wrong, code is in the right place. > > It used to be in heapam.h ... evidently, whoever moved it missed this > comment. I imagined that that was the case. It's a fairly inconsequential bug, but it is worth fixing... -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
R: R: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
Then I meet my colleague who is the systems engineer that takes care of the machine and I explain your hints (suggested by Craig Ringer) about how detect and log kernel issues. If it can be useful, the content of file /proc/$pid/wchan in the moment of block is "_stext". In the meantime, to be sure that it could not been a libpq bug, I ask you one thing. In internet I searched for detailed specifications of poll/select system functions but I didn't understand one thing, that is which one of the 2 statement is true: 1) poll/select wait only for FUTURE modifications of ready-read state of sockets 2) poll/select check if there is something to read at the moment of the call and otherwise wait for FUTURE modifications of ready-read state Because if it was true the first statement, it could be that the answer of the server arrives between the request and the call of poll (this time is surely very short but however strictly greater than 0 and in this interval the server answer could arrive). Theoretical sequence: 1) Client request to server 2) Server answer to client 3) client wait calling poll In this case client and server go in a sort of deadlock because server and client wait each other for the other and could be a libpq bug. What do you think about ? This scenario could be possible or the true statement is the second ? Regard, Andrea -Messaggio originale- Da: Craig Ringer [mailto:ring...@ringerc.id.au] Inviato: mercoledì 21 dicembre 2011 0.56 A: Tom Lane Cc: Andrea Grassi; harry...@comcast.net; 'Pg Bugs'; 'Alvaro Herrera' Oggetto: Re: R: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function On 21/12/2011 1:42 AM, Tom Lane wrote: > Hrm. What's with the 48 bytes in the client's receive queue? Surely > the kernel should be reporting that the socket is read-ready, if it's > got some data. I think you've found an obscure kernel bug somehow > it's failing to wake the poll() caller. > I've been leaning that way too; that's why I was asking him for /proc/$pid/stack and `wchan -C programname -o wchan:80=` output - to get some idea of what function in the kernel it's sitting in. Unfortunately the OP is on some enterprise distro that doesn't have /proc/$pid/stack . wchan info would still be useful. I wonder how old their kernel is? The bug could've already been fixed. /proc/pid/stack has been around since 2008 so it must be pretty elderly. OP: You can also get a kernel stack for a process by enabling the magic SysRQ key (see Google) then using Alt-SysRq-T . This requires a physical keyboard directly connected to the server. It emits the stack information via dmesg. See: http://en.wikipedia.org/wiki/Magic_SysRq_key There's a "sysrqd" that apparently lets you use these features remotely, but I've never tried it. -- 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] [PATCH v2] Use CC atomic builtins as a fallback
Martin Pitt writes: > Tom Lane [2011-12-20 21:14 -0500]: >> Another thing that is bothering me is that according to the gcc >> manual, eg here, >> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html >> __sync_lock_test_and_set is nominally provided for datatypes 1, 2, >> 4, or 8 bytes in length, but the underlying hardware doesn't >> necessarily support all those widths natively. If you pick the >> wrong width then you don't get an inline operation at all, but a >> call to some possibly inefficient library subroutine. > It's even worse. Our original version of the patch used a char, and > while that worked fine on the older Babbage board, it completely broke > at runtime on e. g. a Panda board. It wasn't just slow, it caused > hangs and test failures all over the place. With int it works > flawlessly. Yeah, that was another thing I found worrisome while googling: there were a disturbingly large number of claims that __sync_lock_test_and_set and/or __sync_lock_release were flat-out broken on various combinations of gcc version and platform. After reading that, there is no way at all that I'd accept your original patch to use these functions everywhere. For the moment I'm inclined to consider using these functions *only* on ARM, so as to limit our exposure to such bugs. That would also limit the risk of using an inappropriate choice of lock width. 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: R: R: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
"Andrea Grassi" writes: > In internet I searched for detailed specifications of poll/select system > functions but I didn't understand one thing, that is which one of the 2 > statement is true: > 1) poll/select wait only for FUTURE modifications of ready-read state of > sockets > 2) poll/select check if there is something to read at the moment of the call > and otherwise wait for FUTURE modifications of ready-read state #1 is nonsense. If poll worked like that, it would be impossible for anyone to use it without suffering from race conditions. But if you don't see where exactly the poll() specification says so, I observe that it says first that poll sets the bit(s) if the requested condition is true, and second that *if* none of the events have occurred yet, poll should wait. See for instance http://pubs.opengroup.org/onlinepubs/007908799/xsh/poll.html 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 #6349: Cannot install on 32 bit platform
The following bug has been logged on the website: Bug reference: 6349 Logged by: Chandramouli Email address: cmjno...@gmail.com PostgreSQL version: 9.1.2 Operating system: Windows 7 32 bit Description: Hello. I downloaded the insatller of postgresql from the internet and when I try to install it says "Cannot install a 64 bit installer on a 32 bit platform".Where can I get a 32bit installed. Please help me as I am in a hurry to start the database for a social networking website. -- 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 #6348: PROBLEMAS DELETE
The following bug has been logged on the website: Bug reference: 6348 Logged by: wilson camargo Email address: wilsoncam...@gmail.com PostgreSQL version: 9.1.2 Operating system: win linux Description: hace algun tiempo tube el inconveniente de eliminar de una tabla relacionada en una subconsulta y eliminando 1 aprox se demoraba 20 seg la consulta era DELETE FROM saldo_detalle_cartera WHERE saldo_detalle_cartera.movimiento_contable in (select s.movimiento_contable from saldo_detalle_cartera s inner join movimiento_contable m on m.id_mov_contable= s.movimiento_contable and m.proyecto = '185' ) afotunadamente hay una forma mas rapida que es usando esta sentencia DELETE FROM saldo_detalle_cartera USING movimiento_contable m WHERE saldo_detalle_cartera.movimiento_contable = m.id_mov_contable and m.proyecto='185' la cual lo hace en tan solo 11 ms la pregunta es podria hacer algo paracecido usando UDATE con tablas relacionales -- 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 #6348: PROBLEMAS DELETE
Excerpts from wilsoncamago's message of mié dic 21 11:26:39 -0300 2011: > hace algun tiempo tube el inconveniente de eliminar de una tabla relacionada > en una subconsulta y eliminando 1 aprox se demoraba 20 seg la consulta > era > DELETE FROM saldo_detalle_cartera > WHERE saldo_detalle_cartera.movimiento_contable in (select > s.movimiento_contable from saldo_detalle_cartera s > inner join movimiento_contable m on > m.id_mov_contable= s.movimiento_contable > and m.proyecto = '185' ) > > afotunadamente hay una forma mas rapida que es usando esta sentencia Wilson, esto no es un bug. Por favor plantea tu pregunta en pgsql-es-ay...@postgresql.org -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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 #6350: Delete a role which is still in use
The following bug has been logged on the website: Bug reference: 6350 Logged by: Marc Balmer Email address: m...@msys.ch PostgreSQL version: 9.1.1 Operating system: NetBSD Description: A role can be deleted although it is still referenced in a column privilege. Here is how: create three new roles: user, admin, new_admin create a table, e.g. "bar" with one column, e.g. "foo", owner of the table is "admin". now grant "user" select rights on the "foo" column in table "bar". now change the owner of the table "bar" to "new_admin". drop the role "admin". PostgreSQL won't complain. look at the privileges of table "bar" using \dp. The ownership change from "admin" to "new_admin" did not make it to the column privileges. -- 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 #6349: Cannot install on 32 bit platform
wrote: > I downloaded the insatller of postgresql from the internet and > when I try to install it says "Cannot install a 64 bit installer > on a 32 bit platform".Where can I get a 32bit installed. This is not a bug. Please post futures questions like this to a more appropriate list, like pgsql-general, pgsql-novice, or pgsql-admin. The downloads on this page seem to include both 32-bit and 64-bit versions: http://www.enterprisedb.com/products-services-training/pgdownload#windows Perhaps you clicked on the wrong one last time? -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] script for #6350
Attached script (run as psql -U postgres -f bug_6350.sql) shows the problem. Enjoy! create database problematic; \c problematic -- create three roles create role usr; create role adm; create role new_adm; create table foo (bar integer); alter table foo owner to adm; grant select(bar) on foo to usr; -- all ok so far, usr and adm are referenced in -- the foo.bar column privileges \dp foo -- now change the owner alter table foo owner to new_adm; -- the following drop succeds, although role adm -- is still referenced in the foo.bar column -- privileges. this is a bug. drop role adm; \dp foo -- the column privileges can now not be changed -- due to the stale reference to the deleted role. revoke select(bar) on foo from usr; \dp foo \c template1 drop database problematic; -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] script for #6350
Attached script (run as psql -U postgres -f bug_6350.sql) shows the problem. Enjoy! create database problematic; \c problematic -- create three roles create role usr; create role adm; create role new_adm; create table foo (bar integer); alter table foo owner to adm; grant select(bar) on foo to usr; -- all ok so far, usr and adm are referenced in -- the foo.bar column privileges \dp foo -- now change the owner alter table foo owner to new_adm; -- the following drop succeds, although role adm -- is still referenced in the foo.bar column -- privileges. this is a bug. drop role adm; \dp foo -- the column privileges can now not be changed -- due to the stale reference to the deleted role. revoke select(bar) on foo from usr; \dp foo \c template1 drop database problematic; -- 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 #6350: Delete a role which is still in use
m...@msys.ch writes: > A role can be deleted although it is still referenced in a column privilege. Hmm, it looks like ALTER TABLE OWNER forgets to update the grantors in column privileges. Table privileges are processed properly, but not columns. 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 #6351: ERROR: btree index keys must be ordered by attribute
The following bug has been logged on the website: Bug reference: 6351 Logged by: Christian Rudolph Email address: christian_oede...@gmx.de PostgreSQL version: 9.0.6 Operating system: openSUSE Description: Hi, our OR-Mapper accidently created an index that contained the same column twice, with the result that some SELECTs could not be executed anymore and gave the error message "btree index keys must be ordered by attribute". The problem can be reproduced with a new table every time: CREATE TABLE tab (id SERIAL, a INTEGER, b INTEGER); CREATE INDEX tab123 ON tab (a, b, a); SELECT a, b FROM tab WHERE a = 0 AND b = 0; ERROR: XX000: btree index keys must be ordered by attribute LOCATION: _bt_preprocess_keys, nbtutils.c:322 For me the error occured without inserting any rows. The database was compiled from source using the switches --with-tcl --with-perl and --with-python. SELECT version(); PostgreSQL 9.0.6 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.2.1 (SUSE Linux), 32-bit Thanks, Christian -- 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 #6204: Using plperl functions generate crash
I'm running into the same issue. I can "create language plperl;" successfully, but as soon as I try to create a function (as shown above), Postgres dies. Guimaraes - did you find a solution using standard installers? sachin - have you tried on win7? pasman - what's the process to install from source? More detail on my setup... I'm on Win7. Postgres 9.1 32-bit: http://www.enterprisedb.com/products/pgdownload.do#windows (version 9.1.2-1) Perl 5.14 32-bit, I've tried both: http://downloads.activestate.com/ActivePerl/releases/5.14.2.1402/ActivePerl-5.14.2.1402-MSWin32-x86-295342.msi http://downloads.activestate.com/ActivePerl/releases/5.14.1.1401/ActivePerl-5.14.1.1401-MSWin32-x86-294969.msi Here's what I see in the log file: 2011-12-21 08:10:49 PST LOG: server process (PID 7296) was terminated by exception 0xC005 2011-12-21 08:10:49 PST HINT: See C include file "ntstatus.h" for a description of the hexadecimal value. 2011-12-21 08:10:49 PST LOG: terminating any other active server processes 2011-12-21 08:10:49 PST WARNING: terminating connection because of crash of another server process 2011-12-21 08:10:49 PST DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2011-12-21 08:10:49 PST HINT: In a moment you should be able to reconnect to the database and repeat your command. 2011-12-21 08:10:49 PST LOG: all server processes terminated; reinitializing 2011-12-21 08:10:59 PST FATAL: pre-existing shared memory block is still in use 2011-12-21 08:10:59 PST HINT: Check if there are any old server processes still running, and terminate them. -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-6204-Using-plperl-functions-generate-crash-tp4802111p5092359.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.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 #6204: Using plperl functions generate crash
Shahaf wrote > > I'm running into the same issue. I can "create language plperl;" > successfully, but as soon as I try to create a function (as shown above), > Postgres dies. > > Guimaraes - did you find a solution using standard installers? > No, I didn’t. In fact, þanks God I did not have to insist on trying to make ðe MS Windows aberration work for me. -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-6204-Using-plperl-functions-generate-crash-tp4802111p5092951.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
