[BUGS] BUG #8195: Postgre SQL Database displayed as log in even after running a hide command on terminal
The following bug has been logged on the website: Bug reference: 8195 Logged by: Warren Brodie Email address: warren_bro...@hotmail.com PostgreSQL version: 9.0.0 Operating system: OS X 10.8.3 Description: Hi there, I am using a piece of software called poker tracker that uses a Postgre SQL database. Up until now I have support dealings with them but they are unable to resolve the issue and have put me onto yourselves I will include all correspondence with them so you can see the steps I have taken: Hi Warren - Something like that would be run from a terminal application so do this: 1. In PokerTracker4 click File - Backup, put check marks in everything on the left and remove all those you can from the middle. This is to backup your database(s) first just in case something goes wrong later. Save the backup file someplace safe. 2. Open Applications - Utilities - Terminal 3. Copy/paste this into the new terminal window: sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add PostgreSQL Press the 'enter' key on the keyboard after copying/pasting that. You may be prompted for your Mac administrator password so you'll need to know that. 4. Afterward reboot, see if the PostgreSQL user was hidden on the login screen then start PokerTracker4 to make sure it doesn't say something like unable to connect Mike --- Hi Mike, I have done exactly as you have said but the log in is still there. Last login: Thu May 30 00:09:35 on console (null):~ WarrenBrodie$ sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add PostgreSQL Password: (null):~ WarrenBrodie$ Thats what comes up when I enter my password in the terminal and then when I restart it is still there. Regards, Warren Brodie -- Hi Warren - I talked to our Mac expert and he says to do this: 1. Open the terminal again if needed; 2. Copy/paste this (and press the 'enter' key): sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add postgres After that reboot to confirm PokerTracker4 still works and that the PostgreSQL account no longer shows. Let me know what happens. Mike -- And the problem has still not solved I can send screenshots through so you have a better understanding of the problem if you wish. Regards, Warren Brodie -- 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 #8193: A few cosmetic misspell fixes.
The following bug has been logged on the website: Bug reference: 8193 Logged by: Lajos Veres Email address: vla...@gmail.com PostgreSQL version: 9.2.4 Operating system: Linux Description: Found a few small misspell with this: https://github.com/vlajos/misspell_fixer I created a small patch here: http://www.pastebin.ca/2385261 Lajos -- 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 #8191: Wrong bit conversion
The following bug has been logged on the website: Bug reference: 8191 Logged by: Gerald Luger Email address: ger...@hexboss.com PostgreSQL version: 9.2.1 Operating system: Windows 8 Description: SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64) RESULT: 1000, 0001, 0001 -- 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 #8194: hardware
The following bug has been logged on the website: Bug reference: 8194 Logged by: Daniel Couto Email address: daniel.cout...@hotmail.com PostgreSQL version: 9.2.4 Operating system: Windwos Description: Gostaria de saber quais são os requisitos minimos de hardware para que posso instalar no meu pc o PostGreeSQL. Obrigado -- 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 #8196: problem with left join and is null check
The following bug has been logged on the website: Bug reference: 8196 Logged by: Ara Email address: aray1...@yahoo.com PostgreSQL version: 9.1.9 Operating system: ubuntu Description: I have to tables which I'm joining with left join query. SELECT count(*) FROM table A LEFT JOIN table B ON ... result has 200 000 rows, for 190 000 of them there is no value for columns of table B (result of join) ISSUE: When I'm trying to filter result with WHERE B.some_column IS NULL query works more then 5 min (never waited for result). MORE INFO: When I'm filtering results with WHERE B.some_column IS NULL OR B.some_column = 'some value that some_column would never had' the query takes 2 second and gives normal result (190 000). -- 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 #8191: Wrong bit conversion
ger...@hexboss.com writes: SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64) RESULT: 1000, 0001, 0001 I believe those are all operating as intended. 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 #8191: Wrong bit conversion
Shouldn't I expect all results to be 000...0001? Otherwise it would be 1 != 1? -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, May 31, 2013 5:34 PM To: Gerald Luger Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #8191: Wrong bit conversion ger...@hexboss.com writes: SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64) RESULT: 1000, 0001, 0001 I believe those are all operating as intended. 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 #8197: Error Message When trying to install PS8.1
The following bug has been logged on the website: Bug reference: 8197 Logged by: Rob Mapletoft Email address: healthycomput...@persona.ca PostgreSQL version: Unsupported/Unknown Operating system: SBS 2011 64 bit Description: The files belonging to this database system will be owned by user postgres. This user must also own the server process. The database cluster will be initialized with locale C. fixing permissions on existing directory C:/Program Files (x86)/PostgreSQL/8.1/data ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/global ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/pg_xlog ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/pg_xlog/archive_status ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/pg_clog ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/pg_subtrans ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/pg_twophase ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/pg_multixact/members ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/pg_multixact/offsets ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/base ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/base/1 ... ok creating directory C:/Program Files (x86)/PostgreSQL/8.1/data/pg_tblspc ... ok selecting default max_connections ... 10 selecting default shared_buffers ... 50 creating configuration files ... ok creating template1 database in C:/Program Files (x86)/PostgreSQL/8.1/data/base/1 ... Execution of PostgreSQL by a user with administrative permissions is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromises. See the documentation for more information on how to properly start the server. child process was terminated by signal 1 initdb: removing contents of data directory C:/Program Files (x86)/PostgreSQL/8.1/data Failed to run initdb: 1! Please see logfile in C:\Program files (x86)\PostgreSQL\8.1\tmp\initdb.log Note! you must read/copy this logfile before you click OK, or it will be automatically removed. -- 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 #8191: Wrong bit conversion
On 5/31/2013 4:29 PM, Gerald Luger wrote: Shouldn't I expect all results to be 000...0001? Otherwise it would be 1 != 1? SQL's BIT type is big endian, a hangover from its IBM mainframe heritage. -- john r pierce 37N 122W somewhere on the middle of the left coast -- 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 #8191: Wrong bit conversion
On 01/06/13 12:29, John R Pierce wrote: On 5/31/2013 4:29 PM, Gerald Luger wrote: Shouldn't I expect all results to be 000...0001? Otherwise it would be 1 != 1? SQL's BIT type is big endian, a hangover from its IBM mainframe heritage. I don't think it has anything to do with byte sex (I know of 3 ways to store integers in memory, and I suspect there are more !). Don't confuse how things are displayed with how they are stored in memory. Just that 1 = two to the power of zero so it seems logical to start numbering the bits to represent the powers of 2. Cheers, Gavin
Re: [BUGS] BUG #8191: Wrong bit conversion
On 01/06/13 13:01, Gavin Flower wrote: On 01/06/13 12:29, John R Pierce wrote: On 5/31/2013 4:29 PM, Gerald Luger wrote: Shouldn't I expect all results to be 000...0001? Otherwise it would be 1 != 1? SQL's BIT type is big endian, a hangover from its IBM mainframe heritage. I don't think it has anything to do with byte sex (I know of 3 ways to store integers in memory, and I suspect there are more !). Don't confuse how things are displayed with how they are stored in memory. Just that 1 = two to the power of zero so it seems logical to start numbering the bits to represent the powers of 2. Cheers, Gavin Hmm... On second thoughts, it is strange that the first 2 examples affect bits on the left hand side! So now I think, that all 3 examples should logically be: RESULT: 0001, BUT, But, But... It appears for varchar padding is done on the right hand side, so maybe that is why the first 2examples are as they are (suggestive, not proof!). Cheers, Gavin
Re: [BUGS] BUG #8191: Wrong bit conversion
On 5/31/2013 6:01 PM, Gavin Flower wrote: SQL's BIT type is big endian, a hangover from its IBM mainframe heritage. I don't think it has anything to do with byte sex (I know of 3 ways to store integers in memory, and I suspect there are more !). I was thinking of bit sex, not byte. IBM numbers bits such that bit 0 is the most significant bit of a word. -- john r pierce 37N 122W somewhere on the middle of the left coast
Re: [BUGS] BUG #8191: Wrong bit conversion
Gerald Luger geraldlu...@hexboss.com writes: Shouldn't I expect all results to be 000...0001? Well, no. The SQL spec is pretty clear about the interpretation of this: b'1'::bit(64) You're taking a bit string of length 1 and casting it to bit string of length 64. That's done by appending zeroes on the right, per spec. The x'1' notation isn't in SQL99 AFAICS, but we consider that x'1' means the same as b'0001', and then the conversion from bit(4) to bit(64) is done by padding zeroes on the right. Your last case, 1::bit(64) represents casting an integer to bit(64). This operation isn't in the SQL spec either, unless I missed something. We treat this as conversion of the integer's twos-complement representation to a bit string, presuming big-endian representation of the integer. Now you can quibble with various of the details above, but in the end they are all arbitrary decisions. We've made them that way, and it would take a pretty impressive argument to persuade us to break existing applications by changing them. 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
