Re: [BUGS] Postmaster can't stop with pg_ctl
Thank you for your reply. On Wed, 25 Apr 2007 10:22:25 -0400 Tom Lane [EMAIL PROTECTED] wrote: Alvaro Herrera [EMAIL PROTECTED] writes: takuya koide wrote: 4) send 'SIGSTOP' signal to postgres If you stop a process by SIGSTOP you must make it run again with SIGCONT. Otherwise it's just not processing signals, so it'll obviously not shut down. I don't think this is a bug. SIGSTOP is a debugging tool, which would be rendered nigh useless if the postmaster tried to override it automatically. So definitely NOTABUG in my opinion too. For end-user, Debugging is not important and daily working, too. So for developper, if PostgreSQL have a debug option, it seems that it is no problem. (When it is used debug option, it not shutdown as like current working) Thank you. Best Regards --- Takuya Koide NEC System Technologies, Ltd. ---(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
[BUGS] BUG #3254: unexpected data beyond EOF in block
The following bug has been logged online: Bug reference: 3254 Logged by: Mario Santini Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.3 Operating system: CentOS Description:unexpected data beyond EOF in block Details: Hello, I use Mediawiki 1.9.3 with PostgreSQL 8.2.3 on a Linux CentOS : Linux kabul.sodalia.it 2.6.9-34.ELsmp #1 SMP Wed Mar 8 00:27:03 CST 2006 i686 i686 i386 GNU/Linux And cpu : x86info v1.13. Dave Jones 2001-2003 Feedback to [EMAIL PROTECTED]. Found 4 CPUs MP Table: # APIC ID Version State Family Model StepFlags #0 0x14BSP, usable 15 4 10 0xbfebfbff #6 0x14AP, usable 15 4 10 0xbfebfbff -- CPU #1 /dev/cpu/0/cpuid: No such file or directory eax in: 0x, eax = 0005 ebx = 756e6547 ecx = 6c65746e edx = 49656e69 eax in: 0x0001, eax = 0f4a ebx = 06020800 ecx = 659d edx = bfebfbff eax in: 0x0002, eax = 605b5001 ebx = ecx = edx = 007d7040 eax in: 0x0003, eax = ebx = ecx = edx = eax in: 0x0004, eax = 4121 ebx = 01c0003f ecx = 001f edx = eax in: 0x0005, eax = 0040 ebx = 0040 ecx = edx = eax in: 0x8000, eax = 8008 ebx = ecx = edx = eax in: 0x8001, eax = ebx = ecx = 0001 edx = 2000 eax in: 0x8002, eax = 20202020 ebx = 20202020 ecx = 20202020 edx = 20202020 eax in: 0x8003, eax = 6e492020 ebx = 286c6574 ecx = 58202952 edx = 286e6f65 eax in: 0x8004, eax = 20294d54 ebx = 20555043 ecx = 30382e33 edx = 007a4847 eax in: 0x8005, eax = ebx = ecx = edx = eax in: 0x8006, eax = ebx = ecx = 08006040 edx = eax in: 0x8007, eax = ebx = ecx = edx = eax in: 0x8008, eax = 3024 ebx = ecx = edx = Family: 15 Model: 4 Stepping: 10 Type: 0 Brand: 0 CPU Model: Pentium 4 Xeon (Foster) Original OEM Processor name string: Intel(R) Xeon(TM) CPU 3.80GHz Feature flags: Onboard FPU Virtual Mode Extensions Debugging Extensions Page Size Extensions Time Stamp Counter Model-Specific Registers Physical Address Extensions Machine Check Architecture CMPXCHG8 instruction Onboard APIC SYSENTER/SYSEXIT Memory Type Range Registers Page Global Enable Machine Check Architecture CMOV instruction Page Attribute Table 36-bit PSEs CLFLUSH instruction Debug Trace Store ACPI via MSR MMX support FXSAVE and FXRESTORE instructions SSE support SSE2 support CPU self snoop Hyper-Threading Automatic clock Control Pending Break Enable Extended feature flags: est tm2 cntx-id Pentium 4 specific MSRs: /dev/cpu/0/msr: No such file or directory Instruction trace cache: Size: 12K uOps 8-way associative. L1 Data cache: Size: 16KB Sectored, 8-way associative. line size=64 bytes. Instruction TLB: 4K, 2MB or 4MB pages, fully associative, 64 entries. Data TLB: 4KB or 4MB pages, fully associative, 64 entries. Processor serial: -0F4A---- The physical package supports 2 logical processors Connector type: Socket603 (PGA603 Socket) MTRR registers: MTRRcap (0xfe): MTRRphysBase0 (0x200): MTRRphysMask0 (0x201): MTRRphysBase1 (0x202): MTRRphysMask1 (0x203): MTRRphysBase2 (0x204): MTRRphysMask2 (0x205): MTRRphysBase3 (0x206): MTRRphysMask3 (0x207): MTRRphysBase4 (0x208): MTRRphysMask4 (0x209): MTRRphysBase5 (0x20a): MTRRphysMask5 (0x20b): MTRRphysBase6 (0x20c): MTRRphysMask6 (0x20d): MTRRphysBase7 (0x20e): MTRRphysMask7 (0x20f): MTRRfix64K_0 (0x250): MTRRfix16K_8 (0x258): MTRRfix16K_A (0x259): MTRRfix4K_C8000 (0x269): MTRRfix4K_D 0x26a: MTRRfix4K_D8000 0x26b: MTRRfix4K_E 0x26c: MTRRfix4K_E8000 0x26d: MTRRfix4K_F 0x26e: MTRRfix4K_F8000 0x26f: MTRRdefType (0x2ff): 3.8Ghz processor (estimate). -- CPU #2 eax in: 0x, eax = 0005 ebx = 756e6547 ecx = 6c65746e edx = 49656e69 eax in: 0x0001, eax = 0f4a ebx = 06020800 ecx = 659d edx = bfebfbff eax in: 0x0002, eax = 605b5001 ebx = ecx = edx = 007d7040 eax in: 0x0003, eax = ebx = ecx = edx = eax in: 0x0004, eax = 4121 ebx = 01c0003f ecx = 001f edx = eax in: 0x0005, eax = 0040 ebx = 0040 ecx = edx = eax in: 0x8000, eax = 8008 ebx = ecx = edx = eax in: 0x8001, eax = ebx = ecx = 0001 edx = 2000 eax in:
Re: [BUGS] BUG #3252: Select Order by time
Hi Kevin,
Thanks for the response. I am a little embarrassed and I was in fact hoping
that my stupid Report would just dissolve away in the abyss. In your
responding I am of course quite bowled over that - Hey there are people
genuinely out there - unlike reports one may send to mickeysoft who are
probably paid handsomely.
You are of course right. I do not know what I was seeing - might have been
something to do with it being about 3:00am my time.
Interesting that 24:00 is accepted by Postgres. Didn't know that.
Again, Thank you for the effort you have expended to look into my (really
stupid) bug report.
Regards
Lee
Lee Chua
-Original Message-
From: Kevin Grittner [mailto:[EMAIL PROTECTED]
Sent: Thursday, 26 April 2007 6:15 AM
To: Lee Chua; Tom Lane
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #3252: Select Order by time
On Wed, Apr 25, 2007 at 12:42 AM, in message
[EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Lee Chua [EMAIL PROTECTED] writes:
When we select and order by time we get 00:00:00 as the latest time of
the
day.
Really? It works as expected for me:
regression=# create table foo(f1 time);
CREATE TABLE
regression=# insert into foo values ('1:00:00'),('2:00:00'),('0:00:00'),
regression- # ('23:00:00'), ('23:59:59');
INSERT 0 5
regression=# select * from foo order by f1;
f1
--
00:00:00
01:00:00
02:00:00
23:00:00
23:59:59
(5 rows)
I just wanted to point out that midnight is supported at both ends -- the
start of the day as 00:00:00, and the end of the day as 24:00:00. Perhaps
the application software is not distinguishing these?
Modifying Tom's example to insert one more row, you will see:
f1
--
00:00:00
01:00:00
02:00:00
23:00:00
23:25:59
24:00:00
(6 rows)
I know there are some who require this behavior. (I had to add it to a
database product years ago when it was used to develop an application for
fire departments.)
-Kevin
Re: [BUGS] BUG #3254: unexpected data beyond EOF in block
Mario Santini [EMAIL PROTECTED] writes: I use Mediawiki 1.9.3 with PostgreSQL 8.2.3 on a Linux CentOS : Linux kabul.sodalia.it 2.6.9-34.ELsmp #1 SMP Wed Mar 8 00:27:03 CST 2006 i686 i686 i386 GNU/Linux Query failed: ERROR: unexpected data beyond EOF in block 1311 of relation quot;pg_toast_17041quot; HINT: This has been seen to occur with buggy kernels; consider updating your system. I see there is similar post in the mailing list, but I could not find any solution. Is this a PostgreSQL bug? No, it's a kernel bug, as the message clearly says. The previous reports have been on SUSE rather than CentOS, but in any case the fix is a kernel update. regards, tom lane ---(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 #3048: pg_dump dumps intarray metadata incorrectly
Oleg, I still haven't seen this patch applied to CVS. --- Oleg Bartunov wrote: On Mon, 2 Apr 2007, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom, do you want this fixed for 8.2.X? Tom Lane wrote: Yeah. I'd say that intarray's attempt to override the default status of the built-in gin opclass is simply a bad idea and should be removed. I don't recall having seen a response from Oleg or Teodor, and would like their input before making a final decision --- but at the moment I think we should take that out. Oleg or Teodor, I need a comment on this. We agree with Tom in this case and we'll remove update of system catalog. But, I want to rise the problem again - pg_dump doesn't track changes of system catalog. The problem could be more pronounced in case of built-in FTS, if somebody with superuser rights changes fts configurations in system catalog. Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared lock object
I wrote: Also, we have a generic issue that making fresh entries in a hashtable might result in a concurrent hash_seq_search scan visiting existing entries more than once; that's definitely not something any of the existing callers are thinking about. I'm too tired to think about fixes right now, but we've definitely found a hotbed of actual and potential bugs. I've committed a fix for this; it'll be in the next set of releases. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] setseed accepts bad seeds
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Kris Jurka wrote: On Wed, 11 Apr 2007, Tom Lane wrote: It's not really possible to use it incorrectly, AFAICS. Any value you might pass to it will result in a specific new seed value. Nowhere is there any guarantee of what the mapping is, and it's obviously impossible to guarantee that the mapping is one-to-one, so any user assumptions about what a specific seed value might mean seem broken regardless. Then please consider this patch which checks the range and maps the provided value to the entire seed space. Kris Jurka Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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
