[BUGS] BUG #2484: pg_dump not support < redirect
The following bug has been logged online: Bug reference: 2484 Logged by: Yu-Lung Shao Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4-1 Operating system: WinXP Home Description:pg_dump not support < redirect Details: file: backup.cmd pg_dump.exe dbname -U postgres -W -f dbname.sql < password.txt in 8.0.3 is work in 8.1.4 is not work need manual key in password. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2484: pg_dump not support < redirect
> Bug reference: 2484 > Logged by: Yu-Lung Shao > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.4-1 > Operating system: WinXP Home > Description:pg_dump not support < redirect > Details: > > file: backup.cmd > > pg_dump.exe dbname -U postgres -W -f dbname.sql < password.txt > > in 8.0.3 is work > > in 8.1.4 is not work need manual key in password. The bug is in 8.0.3 (and <= 8.1.3 as well), fixed in the latest versions. If you want to pass the password to pg_dump, use pgpass.conf or the PGPASSWORD environment variable. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] [Win32] Problem with rename()
>>> On 16.06.2006 at 23:21:21, in message <[EMAIL PROTECTED]>, Bruce Momjian wrote: > Yea. Where you using WAL archiving? We will have a fix in 8.1.5 to > prevent multiple archivers from starting. Perhaps that was a cause. > Not at the time, no. The rename in question was just a regular WAL segment rename. > Yes, I just reread that thread. I also am confused where to go from > here. > Yeah, it's unfortunate that our best theory (a _commit on a deleted file) just didn't seem to be supported by the evidence. Although the servers which see a heavy SELECT load are now Linux, we still have a couple of Windows servers receiving the normal replication traffic. We still get regular fsync errors after the scheduled CLUSTERs so if you do find a fix (or come up with a new theory), there's a test bed there (at least for now). > Were you the only one use Win32 in heavy usage? You were on Win2003. > Were there some bugs in the OS that got fixed later. ... > Yep. What has me baffled is why no one else is seeing the problem. > We had a rash of reports, and now all is quiet. > We might be somewhat more susceptible than most too. Due to the way our middle tier parcels out queries, some connections might sit idle for a long time. Per Tom's explanation in the original thread, this is an important factor. Ultimately if a concurrent rename isn't possible in Windows (and that looks likely), it's going to be a problem as things stand now. Pete ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] 7.4.13 initdb fails on Turkish locale
Hi, Description of problem: initdb fails on tr_TR.UTF-8. OS is Fedora Core 5 on a 32 bit platform, and an up2date system. Version-Release number of selected component (if applicable): PostgreSQL 7.4.13. How reproducible: Always Steps to Reproduce: 1. Compile PostgreSQL 7.4.13 2. Create data dir 3. Run initdb with --locale=tr_TR.UTF-8 Actual results: -bash-3.1$ bin/initdb -D data/ --locale=tr_TR.UTF-8 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 tr_TR.UTF-8. creating template1 database in data//base/1... FATAL: XX000: failed to initialize DateStyle to "ISO, MDY" LOCATION: InitializeGUCOptions, guc.c:1881 initdb: failed Expected results: The initdb should succeed. Additional information: AFAIR we have fixed this early 7.4 series, but it is back now. I'm not sure when this reappeared. I haven't tested 7.4.X for a long time. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] 7.4.13 initdb fails on Turkish locale
Devrim GUNDUZ <[EMAIL PROTECTED]> writes: > AFAIR we have fixed this early 7.4 series, but it is back now. I'm not > sure when this reappeared. I haven't tested 7.4.X for a long time. No, that's never worked in 7.4 ... we didn't add the pg_strcasecmp code until 8.0 devel cycle. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] 7.4.13 initdb fails on Turkish locale
Hi Tom, On Sat, 2006-06-17 at 18:12 -0400, Tom Lane wrote: > Devrim GUNDUZ <[EMAIL PROTECTED]> writes: > > AFAIR we have fixed this early 7.4 series, but it is back now. I'm > not > > sure when this reappeared. I haven't tested 7.4.X for a long time. > > No, that's never worked in 7.4 ... we didn't add the pg_strcasecmp > code until 8.0 devel cycle. I mean this one: === http://www.postgresql.org/docs/7.4/static/release-7-4-2.html Partial fix for Turkish-locale issues initdb will succeed now in Turkish locale, but there are still some inconveniences associated with the i/I problem. = Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] 7.4.13 initdb fails on Turkish locale
Devrim GUNDUZ <[EMAIL PROTECTED]> writes: > On Sat, 2006-06-17 at 18:12 -0400, Tom Lane wrote: >> No, that's never worked in 7.4 ... we didn't add the pg_strcasecmp >> code until 8.0 devel cycle. > I mean this one: > http://www.postgresql.org/docs/7.4/static/release-7-4-2.html > Partial fix for Turkish-locale issues > initdb will succeed now in Turkish locale, but there are still some > inconveniences associated with the i/I problem. Hmm. I wonder what we tested back then? I traced through it, and the reason it's failing is that strcasecmp() is telling assign_datestyle() that "iso" and "ISO" are not equal, and as far as I can tell none of the relevant code has changed in the 7.4 branch. Maybe the release note is just wrong. I dug around in the archives and found this discussion: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00709.php That patch was never committed because it didn't pass regression. AFAICT the only real solution would be to introduce pg_strcasecmp into 7.4, ie backport this patch: http://archives.postgresql.org/pgsql-committers/2004-05/msg00037.php which seems entirely unreasonable to me. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
