Re: [BUGS] BUG #7524: Partitioning
[Adding the OP back to CC, in case he's not subscribed to the list] Mark Kirkwood wrote: > On 09/09/12 14:01, Kevin Grittner wrote: >> "Pieter Viljoen Sr." wrote: >> >>> The TWO most important factors in hindering us to convert to >>> Postgres are the following: >>> >>> Parallel execution of queries. >>> >>> No Table Partitioning >> >> Not a bug, so off-topic for this list. If you need help figuring >> out how best to use PostgreSQL, or whether it is a good fit for >> your use-case, a post to pgsql-nov...@postgresql.org would be more >> appropriate. >> >> > > Or even -hackers - but it would make sense to ask 2 questions along > the lines of: > > 1/ What is the current state of table partitioning...is anyone > working on something a bit more native than abusing inheritance? > > 2/ Is anyone working on parallel query execution? Yeah, I should have mentioned keeping each thread to a single topic. But I would still think -novice or -general would be more appropriate unless he was looking to write or sponsor packages for the features; so it depends. -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] BUG #7528: Spurious empty log file created
The following bug has been logged on the website: Bug reference: 7528 Logged by: Alexander Jerusalem Email address: aj...@topolyte.com PostgreSQL version: 9.2.0 Operating system: Linux (Ubuntu x86_64, kernel version 2.6.18) Description: I have the following log configuration in postgresql.conf: log_destination = 'csvlog' logging_collector = on log_directory = 'pg_log' log_filename = 'pg-%Y-%m-%d_%H%M%S.log' log_rotation_age = 1d log_rotation_size = 10MB After removing all files from pg_log and relaunching the postgres server, pg_log contains two files instead of one: pg-xxx.log and pg-xxx.csv. According to the documentation, only pg-xxx.csv should exist. And in fact only pg-xxx.csv is actually written to whilst pg-xxx.log remains empty. Using a .csv extenson or no extension at all for the log_filename setting doesn't help either. Postgres always creates a file named exactly as the log_filename setting says and a second one with .csv appended. -- 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 #7528: Spurious empty log file created
aj...@topolyte.com writes: > After removing all files from pg_log and relaunching the postgres server, > pg_log contains two files instead of one: pg-xxx.log and pg-xxx.csv. > According to the documentation, only pg-xxx.csv should exist. Not sure where you read that, but the plain log file is always created. It's there to support code that might randomly write on stderr, for instance third-party code such as Perl. 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] initdb.exe changes --locale option
I'm using the "postgresql-9.2.0-1-windows.exe" installer, from Enterprise DB, on a Windows Vista 32-bit computer. The issue was noticed with the GUI installer, where I chose the local option "English, New Zealand" from a drop-down menu, but the resulting database cluster has "English_United States.1252". With initdb.exe, I see that --locale has unexpected behaviour. I'll present a few examples that each represent key : value, where key is set with --local="key" and value is from the output: The database cluster will be initialized with locale "value". C : C English : English_United States.1252 French : French_France.1252 nonsense : English_United Kingdom.1252 French, Canada : French_France.1252 French_Canada : French_Canada.1252 English, Canada : English_United States.1252 English_New_Zealand : English_United Kingdom.1252 English, New Zealand : English_United States.1252 English_New Zealand : English_New Zealand.1252 There are some interesting interpretations in the above, but I understand they probably depend on the OS (Windows Vista, in this case). In the install-postgresql.log file I see attempts to get a list of available system locales: Executing C:\Users\mwtoews\AppData\Local\Temp\postgresql_installer\getlocales.exe Script exit code: 0 Script output: AfrikaansxxCOMMASPxxSouthxxSPxxAfrica=Afrikaans, South Africa AlbanianxxCOMMASPxxAlbania=Albanian, Albania ... EnglishxxCOMMASPxxCanada=English, Canada ... EnglishxxCOMMASPxxNewxxSPxxZealand=English, New Zealand ... EnglishxxCOMMASPxxUnitedxxSPxxKingdom=English, United Kingdom EnglishxxCOMMASPxxUnitedxxSPxxStates=English, United States ... FrenchxxCOMMASPxxCanada=French, Canada FrenchxxCOMMASPxxFrance=French, France where it appears that the value after "=" is used to populate the drop-down menu. -Mike -- 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] initdb.exe changes --locale option
Furthermore, to compare with initdb.exe from 9.1 on the same computer, here are the key : value pairs from the --locale="key" and locale used. >"C:\Program Files\PostgreSQL\9.1\bin\initdb.exe" --version initdb (PostgreSQL) 9.1.4 C : C English : English French : French nonsense : English_United Kingdom.1252 French, Canada : French, Canada French_Canada : French_Canada English, Canada : English, Canada English_New_Zealand : English_United Kingdom.1252 English, New Zealand : English, New Zealand English_New Zealand : English_New Zealand -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Probable bug with CreateFakeRelcacheEntry
I haven't produced a real problem in a small test case (yet), but I convinced myself that it's wrong enough to be called a bug. If you add the following assertion to BufferAlloc: Assert(relpersistence == RELPERSISTENCE_PERMANENT || relpersistence == RELPERSISTENCE_UNLOGGED || relpersistence == RELPERSISTENCE_TEMP); (which seems like a reasonable assertion to me), then do: create table foo(i int); insert into foo values(1); vacuum foo; vacuum foo; insert into foo values(2); Then do an immediate shutdown, then restart, you hit the assertion. The problem is using CreateFakeRelcacheEntry, which has the following comment: Only the fields related to physical storage, like rd_rel, are initialized, so the fake entry is only usable in low-level operations like ReadBuffer(). That doesn't seem right, because ReadBuffer needs relpersistence set. One of the consequences is that you can get buffers with the wrong flags set; in particular, missing BM_PERMANENT, which seems like it could be a serious problem. Are there other areas where we might have similar problems? Regards, Jeff Davis -- 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] initdb.exe changes --locale option
Hi On Mon, Sep 10, 2012 at 10:07 PM, Mike Toews wrote: > I'm using the "postgresql-9.2.0-1-windows.exe" installer, from > Enterprise DB, on a Windows Vista 32-bit computer. > > The issue was noticed with the GUI installer, where I chose the local > option "English, New Zealand" from a drop-down menu, but the resulting > database cluster has "English_United States.1252". > > With initdb.exe, I see that --locale has unexpected behaviour. I'll > present a few examples that each represent key : value, where key is > set with --local="key" and value is from the output: The database > cluster will be initialized with locale "value". > > C : C > English : English_United States.1252 > French : French_France.1252 > nonsense : English_United Kingdom.1252 > French, Canada : French_France.1252 > French_Canada : French_Canada.1252 > English, Canada : English_United States.1252 > English_New_Zealand : English_United Kingdom.1252 > English, New Zealand : English_United States.1252 > English_New Zealand : English_New Zealand.1252 > > There are some interesting interpretations in the above, but I > understand they probably depend on the OS (Windows Vista, in this Bizzarre. > case). In the install-postgresql.log file I see attempts to get a list > of available system locales: > > Executing > C:\Users\mwtoews\AppData\Local\Temp\postgresql_installer\getlocales.exe > Script exit code: 0 > > Script output: > AfrikaansxxCOMMASPxxSouthxxSPxxAfrica=Afrikaans, South Africa > AlbanianxxCOMMASPxxAlbania=Albanian, Albania You can ignore most of that - the weirdness there is just the format we present the data to the Bitrock installer code in for it to populate the list. Ugly as sin, but entirely generated from the local system. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
