Re: [BUGS] BUG #6230: strange changes in behavior of string functions
"Dmitry Ryabov" writes:
> In the version 9.1 I was surprised to find that the function "upper" now is
> not working as before. For example:
> select upper ('SISTEM AYGıTLARı') = 'SISTEM AYGITLARI'
> in postgresql 9.0 returns true, but in postgresql 9.1 - false.
It sounds like you didn't use the same locale settings when creating
your 9.1 database. Check LC_CTYPE and LC_COLLATE settings.
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 #6230: strange changes in behavior of string functions
The following bug has been logged online:
Bug reference: 6230
Logged by: Dmitry Ryabov
Email address: dmitry-rya...@mail.ru
PostgreSQL version: 9.1
Operating system: Windows x64
Description:strange changes in behavior of string functions
Details:
In the version 9.1 I was surprised to find that the function "upper" now is
not working as before. For example:
select upper ('SISTEM AYGıTLARı') = 'SISTEM AYGITLARI'
in postgresql 9.0 returns true, but in postgresql 9.1 - false. Such behavior
now occurs under the transformations of other national symbols. In the
release notes that I have not found mention of such changes. Question: is
the bug? Sorry for my bad English.
--
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 #6227: No arguments for COPY OIDS and HEADER
On Wed, Sep 28, 2011 at 11:05, Tom Lane wrote: > "Itagaki Takahiro" writes: >> Our documentation says OIDS and HEADER options in COPY command take [ >> boolean ] arguments, but actually they don't accept any arguments. We can >> only set them to TRUE by specifying their names. > > Um, these examples all work fine for me in HEAD: Ah, I was wrong. The new COPY syntax with parentheses accepts boolean values: OK: COPY tbl FROM '/file' WITH (OIDS true) NG: COPY tbl FROM '/file' WITH OIDS true So, no bugs in the docs. Sorry. -- Itagaki Takahiro -- 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 #6227: No arguments for COPY OIDS and HEADER
"Itagaki Takahiro" writes: > Our documentation says OIDS and HEADER options in COPY command take [ > boolean ] arguments, but actually they don't accept any arguments. We can > only set them to TRUE by specifying their names. Um, these examples all work fine for me in HEAD: regression=# copy tenk1 to '/dev/null' with (oids); COPY 1 regression=# copy tenk1 to '/dev/null' with (oids true); COPY 1 regression=# copy tenk1 to '/dev/null' with (oids false); COPY 1 regression=# copy tenk1 to '/dev/null' with (format csv, header); COPY 1 regression=# copy tenk1 to '/dev/null' with (format csv, header true); COPY 1 regression=# copy tenk1 to '/dev/null' with (format csv, header false); COPY 1 Also, regression=# copy tenk1 to '/dev/null' with (oids fals); ERROR: oids requires a Boolean value so it is checking the argument. 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 #6229: Postgresql crashes after: LOG: statistics buffer is full
Alvaro Herrera writes: > Excerpts from Max Kunz's message of mar sep 27 13:50:57 -0300 2011: >> i have detected a problem after postgres logs "statistics buffer is full": >> The database achieves farther on connections from the clients but no one >> could process a statement and neither of the connection was closed. >> It was also not possible to shutdown postgresql regularly. > The 8.1 branch is no longer supported. You need to upgrade, at least to > 8.2; but since that's going to lose support just past December 2011, you > should look into something more recent than that too. FWIW, I suspect the problem is at a much deeper level and "statistics buffer is full" is just a minor symptom. If the stats buffer process is stuck, that should really have no effect on the system other than failure to deliver statistics updates. Probably the reason why it's reporting this is that the stats collector process is stuck, and perhaps the underlying reason for that is also affecting regular backends. But there's not nearly enough info here to diagnose the true cause. In any case I agree with Alvaro that 8.1.3 is horribly obsolete, and you should at least update to the end of the 8.1 release branch if you can't easily migrate to a supported branch. 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 #6229: Postgresql crashes after: LOG: statistics buffer is full
Excerpts from Max Kunz's message of mar sep 27 13:50:57 -0300 2011: > > The following bug has been logged online: > > Bug reference: 6229 > Logged by: Max Kunz > Email address: ad...@m4ximus.de > PostgreSQL version: 8.1.3 > Operating system: Suse > Description:Postgresql crashes after: LOG: statistics buffer is full > Details: > > Hello, > > i have detected a problem after postgres logs "statistics buffer is full": > The database achieves farther on connections from the clients but no one > could process a statement and neither of the connection was closed. > It was also not possible to shutdown postgresql regularly. The 8.1 branch is no longer supported. You need to upgrade, at least to 8.2; but since that's going to lose support just past December 2011, you should look into something more recent than that too. If you really can't do anything about it, you should be using 8.1.21 which has more than four years of bugfixes on top of 8.1.3. -- Á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 #6229: Postgresql crashes after: LOG: statistics buffer is full
The following bug has been logged online: Bug reference: 6229 Logged by: Max Kunz Email address: ad...@m4ximus.de PostgreSQL version: 8.1.3 Operating system: Suse Description:Postgresql crashes after: LOG: statistics buffer is full Details: Hello, i have detected a problem after postgres logs "statistics buffer is full": The database achieves farther on connections from the clients but no one could process a statement and neither of the connection was closed. It was also not possible to shutdown postgresql regularly. Is there a dependence on statistics buffer, while processing statements? I've read a lot about similar problems on the internet, but could not finde a satisfying solution. Is that a known problem? Here is the statistic collector configuration: # - Query/Index Statistics Collector - stats_start_collector = on stats_command_string = on #stats_block_level = off stats_row_level = on #stats_reset_on_server_start = off I need the collector to perform autovacuum. Is it helpful to disable the command_string? I am very greatful for any idea to avoid this problem in future. best regards, Max -- 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] Problems with ENUM type manipulation in 9.1
On Tue, Sep 27, 2011 at 5:06 AM, wrote: > Hello, > > I've encountered some problems with the updated ENUM in PosgreSQL 9.1: > > 1. We can use ALTER TYPE to add enum values, but there is no matching command > to remove values, which makes this an incomplete solution. you can manually delete from pg_enum. this is dangerous; if you delete an enum value that is in use anywhere, behavior is undefined. > 2. "ALTER TYPE ... ADD cannot be executed from a function or multi-command > string" (or from a transaction block), which makes it quite useless for our > purposes. We update our databases using SQL patches. Patches are applied in > a single transaction, so that any failure during execution causes the entire > patch to be rolled back. This command cannot be made part of such a patch. > Even if that wasn't an issue, we would still have a problem, because the > command cannot be used in a DO block. Why would we want to do that? In order > to check first what values are already in the ENUM, lest we attempt to add an > existing value. sql patches work fine. sql script != multi command string. The difference is that you are trying to send several commands in a single round trip (PQexec) vs sending one query at a time which is the way you are supposed to do it (and this works perfectly fine with transactions). ALTER/ADD not working in-function is a minor annoying inconvience I'll admit. > 3. In earlier PostgreSQL versions we used custom procedures (based on > procedures developed by Dmitry Koterov > http://en.dklab.ru/lib/dklab_postgresql_enum/) to add and delete ENUM values. > These procedures manipulate pg_enum table directly. I've updated them to take > into account the new column in pg_enum that was added in 9.1. However, > although adding enums this way seems to work (new values appear in the > pg_enum table), attempting to use these new enums results in errors, such as > this: "enum value 41983 not found in cache for enum [...]". Is it possible > to reset this cache after altering the pg_enum table? restarting the session should do it -- as I said, manipulating pg_enum is dangerous. agree with Kevin -- these are not bugs. merlin -- 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 #6228: Failed to set permissions on the installed files
The following bug has been logged online: Bug reference: 6228 Logged by: Craig Email address: lumberjackches...@gmail.com PostgreSQL version: 8.2 Operating system: Windows Server 2008 R2 Description:Failed to set permissions on the installed files Details: Hi, I have read the FQA and understand that 8.2 is not supported on Windows 7, but I have successfully installed it on my development server running server 2008 R2 before without this problem. I think that this may be a windows issue rather than a postgre bug, but I thought I'd ask for help anyway. Thank you in advance for any advice. The exact words of any error message you see when the installation fails: FAILED TO SET PERMISSIONS ON THE INSTALLED FILES. PLEASE SEE THE LOGFILE IN C:/Program Files(x86)/PostgreSQL/8.2/tmp/pgperm.log The exact version of PostgreSQL you are installing 8.2.21 Whether you installed a 32-bit or 64-bit release of PostgreSQL: 32-bit The operating system and version you are using, eg: "Windows Sever 2008 R2 Standard" Whether you are running a 32-bit or 64-bit version of your operating system 64-bit How you ran the installer. Command-line arguments, what user account you ran it from, etc. Ran using Administrator account through mstsc /console What antivirus and/or software firewall products you have installed, if any, even if they are disabled NO 3rd party firewall or anti-virus software installed. Which, if any, of the troubleshooting instructions you have already tried: FAQ: http://wiki.postgresql.org/wiki/Running_%26_Installing_PostgreSQL_On_Native_ Windows#Common_installation_errors http://forums.enterprisedb.com/posts/list/2044.page#7503 http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=%2Fco m.ibm.tivoli.itbsm.doc_4.1%2Fbsmi144.htm Whether a previous version of PostgreSQL was installed, and if so: No previous versions were installed Collect the installer log file: Failed to set permissions on the installed files. Please see the logfile in 'C:\Program Files (x86)\PostgreSQL\8.2\tmp\pgperm.log'. === Logging stopped: 9/22/2011 11:47:22 === Get the contents of the PostgreSQL server error log: see pgperm.log (On Windows Vista and Windows 7): The UAC security level UAC was disabled Whether you started the installer by logging in as Administrator, started it from from your own normal user account, or ran it using the "Run As Administrator" menu option. Installer was ran using the Administrator account through mstsc /console Whether your computer is a part of a Windows domain. Home computers usually are not, business computers usually are. No Whether you have any Group Policy configured No, I have not configured any GP. This is a fresh installation of the OS. Windows Event log: - http://schemas.microsoft.com/win/2004/08/events/event";> - 1013 2 0 0x80 1697 Application s15453983 - Product: PostgreSQL 8.2 -- Failed to set permissions on the installed files. Please see the logfile in 'C:\Program Files (x86)\PostgreSQL\8.2\tmp\pgperm.log'. (NULL) (NULL) (NULL) (NULL) (NULL) 7B31463730314442442D313636302D343130382D423130412D464234333545413633 4246307D Environemt variables: C:\Users\Administrator>set ALLUSERSPROFILE=C:\ProgramData AOLDIR=C:\project-open APPDATA=C:\Users\Administrator\AppData\Roaming CLIENTNAME=WIN-FKC0EEI78J6 CommonProgramFiles=C:\Program Files\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files COMPUTERNAME=S15453983 ComSpec=C:\Windows\system32\cmd.exe FP_NO_HOST_CHECK=NO HOMEDRIVE=C: HOMEPATH=\Users\Administrator LOCALAPPDATA=C:\Users\Administrator\AppData\Local LOGONSERVER=\\S15453983 MAILENABLE_PATH=C:\PARALL~1\Plesk\MAILSE~1\MAILEN~1 NUMBER_OF_PROCESSORS=8 OS=Windows_NT Path=C:\Parallels\Plesk\Mail Servers\Mail Enable\BIN;C:\PARALL~1\Plesk\ADDITI~1\ Perl\bin\;C:\Parallels\Plesk\Additional\Python\;C:\Windows\system32;C:\Windo ws;C :\Windows\System32\Wbem;C:\Parallels\Plesk\Mail Servers\Mail Enable\BIN64;C:\Pro gram Files (x86)\PostgreSQL\8.2\bin;C:\project-open\bin PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyw PGPASSWORD=Qwer.1234 plesk_bin=C:\Parallels\Plesk\admin\bin plesk_cli=C:\Parallels\Plesk\bin plesk_dir=C:\Parallels\Plesk\ plesk_vhosts=C:\Inetpub\vhosts\ PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=AMD64 Family 16 Model 2 Stepping 3, AuthenticAMD PROCESSOR_LEVEL=16 PROCESSOR_REVISION=0203 ProgramData=C:\ProgramData ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program Files PROMPT=$P$G PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ PUBLIC=C:\Users\Public SESSIONNAME=RDP-Tcp#0 SystemDrive=C: SystemRoot=C:\Windows TEMP=C:\Users\ADMINI~1\AppData\Local\Temp TMP=C:\Users\ADMINI~1\AppData\Local\Temp USERDOMAIN=S15453983 USERNAME=Administrator USERPROFILE=C:\Users\Administrator windir=C
Re: [BUGS] Problems with ENUM type manipulation in 9.1
wrote: > I've encountered some problems with the updated ENUM in PosgreSQL > 9.1: No matter how I tilt my head, I can't see any of those issues as bugs. You have two feature requests and a question about how to work around problems you're having with direct modifications to the system tables. These probably all belong on the pgsql-general list. The exception would be that if you are thinking about implementing the requested features and contributing them to community PostgreSQL, you could discuss that on the -hackers list. -Kevin -- 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] Timezone issues with Postrres
Excerpts from pratikchirania's message of mar sep 27 08:22:45 -0300 2011: > Hi, > > Thanks for the replies and confirmation. > Can you provide me with any defect number or some equivalent for tracking > purpose? Hmm, this was fixed in the master Git branch (what's going to become 9.2 eventually) but not backpatched to 9.0. http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4c5d837e69cf92e906acfa3000d848d4524beee9 You should probably grab the patch, apply locally, and recompile. -- Á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
Re: [BUGS] Timezone issues with Postrres
Hi, Thanks for the replies and confirmation. Can you provide me with any defect number or some equivalent for tracking purpose? Regards, Pratik -- View this message in context: http://postgresql.1045698.n5.nabble.com/Timezone-issues-with-Postgres-tp4809498p4844991.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
[BUGS] Problems with ENUM type manipulation in 9.1
Hello, I've encountered some problems with the updated ENUM in PosgreSQL 9.1: 1. We can use ALTER TYPE to add enum values, but there is no matching command to remove values, which makes this an incomplete solution. 2. "ALTER TYPE ... ADD cannot be executed from a function or multi-command string" (or from a transaction block), which makes it quite useless for our purposes. We update our databases using SQL patches. Patches are applied in a single transaction, so that any failure during execution causes the entire patch to be rolled back. This command cannot be made part of such a patch. Even if that wasn't an issue, we would still have a problem, because the command cannot be used in a DO block. Why would we want to do that? In order to check first what values are already in the ENUM, lest we attempt to add an existing value. 3. In earlier PostgreSQL versions we used custom procedures (based on procedures developed by Dmitry Koterov http://en.dklab.ru/lib/dklab_postgresql_enum/) to add and delete ENUM values. These procedures manipulate pg_enum table directly. I've updated them to take into account the new column in pg_enum that was added in 9.1. However, although adding enums this way seems to work (new values appear in the pg_enum table), attempting to use these new enums results in errors, such as this: "enum value 41983 not found in cache for enum [...]". Is it possible to reset this cache after altering the pg_enum table? Thanks, Dmitry Dmitry Epstein | Developer Allied Testing T + 7 495 544 48 69 Ext 417 www.alliedtesting.com We Deliver Quality. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
