Re: [HACKERS] [BUGS] ECPG CONNECT TO DEFAULT segfault
Zitat von Michael Fuhr [EMAIL PROTECTED]: This is exactly what I did fix with the work mentioned in the hackers thread. It should work nicely with CVS HEAD. Could you please try this? Try what? I don't see a patch, link, or suggested fix in the thread -- just your original message and the two followups by Tom Lane and me. Or was the fix discussed in a different thread? Sorry, something didn't work on my side as I thought they would. I just noticed that I did not commit my changes. They are now. So using the cvs version or the next release candidate should fix the problem. I'm sorry, but I do not have a patch against 7.4 at the moment. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: 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
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
Le 29 déc. 04, à 23:38, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: Le 29 d=E9c. 04, =E0 18:05, Tom Lane a =E9crit : Backtracing the core dump from that crash would do fine. Here you go (gdb) bt #0 0x010a in ?? () #1 0x046e9cce in queryin (buf=3DCannot access memory at address 0x0 ) at query.c:543 #2 0x046e9e44 in mqtxt_in (fcinfo=3D0xb688) at query.c:620 #3 0x0019d790 in OidFunctionCall3 (functionId=3D61367, arg1=3D2762304,=20= arg2=3D0, arg3=3D4294967295) at fmgr.c:1408 #4 0x00091298 in stringTypeDatum (tp=3D0x2a26e9, string=3D0x2a2640 1,=20= atttypmod=3D-1) at parse_type.c:338 Hmm. I was hoping to spot some obviously machine-dependent code nearby to the crash point, but I don't see anything wrong in that area. You might try rebuilding tsearch with -O0 (if it wasn't already) in hopes that the backtrace becomes more accurate. The tsearch test passes when compiled with -O0 (postgres is still compiled with -O2) regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: Hmm. I was hoping to spot some obviously machine-dependent code nearby to the crash point, but I don't see anything wrong in that area. You might try rebuilding tsearch with -O0 (if it wasn't already) in hopes that the backtrace becomes more accurate. The tsearch test passes when compiled with -O0 (postgres is still compiled with -O2) Ugh. That suggests it could be a compiler bug. Are you using the latest available compiler version for your platform? regards, tom lane ---(end of broadcast)--- TIP 3: 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
Re: [HACKERS] Shared row locking
On Wed, 29 Dec 2004 19:57:15 -0500, Tom Lane [EMAIL PROTECTED] wrote: Manfred Koizar [EMAIL PROTECTED] writes: I don't see too much of a difference between #1 (an on-disk structure buffered in shared memory) and #2 (a shared memory structure spilling to disk). If you stand back that far, maybe you can't see a difference ;-) ... Well, I tried to step back a bit to see the whole picture. You think I went too far this time? :-) but the proposal on the table was for an extremely special-purpose on-disk structure. I'd prefer to see first if we can solve a more general problem, namely the fixed size of the existing lock table. I haven't been digging into the code for some time (:-() -- but isn't this basically a key/value mapping with random access? My concern is that as soon as you start to push entries out of the memory structure you have to implement some kind of on-disk structure to support fast lookups, which sooner or later might lead to something that looks suspiciously like the existing hash or btree code. So the question is whether starting by making nbtree more flexible isn't the lower hanging fruit... Servus Manfred ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] TODO item: make world safe for spaces in build/install paths
Pursuant to Theodore Petrosky's recent trouble report, I thought I would see what happens if you try to build Postgres in a directory whose path contains spaces, or if the install prefix contains spaces. It doesn't work, not even close. It looks to me like there are a couple of hundred places in the Makefiles that would need to be fixed by adding quotes around various references to $(libdir) and related variables. I'm afraid that VPATH builds with spaces in the path to the original source tree are not realistically fixable at all; certainly prep_buildtree cannot easily be fixed (it misparses the output of find) and it looks like we'd need upstream Autoconf changes as well to get configure to work fully in that scenario. I don't think it's appropriate to try to fix this at RC3 stage, seeing that it's not a regression --- this never worked before either. But maybe we should add it to the TODO list to consider working on someday. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Shared row locking
Manfred Koizar [EMAIL PROTECTED] writes: So the question is whether starting by making nbtree more flexible isn't the lower hanging fruit... Certainly not; indexes depend on locks, not vice versa. You'd not be able to do that without introducing an infinite recursion into the system design. In any case nbtree is much more heavyweight than we need for this --- the lock table does not want WAL support for example, nor REINDEX/VACUUM, nor support for arbitrary index lookup conditions, nor even multiple datatypes or multiple index columns. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
Le 30 déc. 04, à 16:05, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: Hmm. I was hoping to spot some obviously machine-dependent code nearby to the crash point, but I don't see anything wrong in that area. You might try rebuilding tsearch with -O0 (if it wasn't already) in hopes that the backtrace becomes more accurate. The tsearch test passes when compiled with -O0 (postgres is still compiled with -O2) Ugh. That suggests it could be a compiler bug. Are you using the latest available compiler version for your platform? Hi, The problem is that when compiled with -O2, the pushval_morph func address is 0x0 (in query.c). It goes away with the following patch, which might not be a proper solution Regards, Rémi Zara Index: query.c === RCS file: /projects/cvsroot/pgsql/contrib/tsearch/query.c,v retrieving revision 1.16 diff -u -r1.16 query.c --- query.c 9 Nov 2004 06:09:33 - 1.16 +++ query.c 30 Dec 2004 19:10:46 - @@ -616,6 +616,7 @@ charpbuf[16384], *cur; #endif + elog(DEBUG5, pushval_morph address is %p, pushval_morph); initmorph(); query = queryin((char *) PG_GETARG_POINTER(0), pushval_morph); res = clean_fakeval(GETQUERY(query), len); -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: Ugh. That suggests it could be a compiler bug. Are you using the latest available compiler version for your platform? The problem is that when compiled with -O2, the pushval_morph func address is 0x0 (in query.c). It goes away with the following patch, which might not be a proper solution If that isn't a compiler bug, I don't know what is. Report it to the gcc boys. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Shared row locking
On Thu, 30 Dec 2004 13:36:53 -0500, Tom Lane [EMAIL PROTECTED] wrote: Certainly not; indexes depend on locks, not vice versa. You'd not be able to do that without introducing an infinite recursion into the system design. Wouldn't you have to face the same sort of problems if you spill part of the lock table to disk? While you do I/O you have to hold some lock. In either case there has to be a special class of locks that are pinned in memory. In any case nbtree is much more heavyweight than we need for this Having funcionality we don't need is not a showstopper ... unless heavyweight implies slow, which I have to admit may well be the case. Servus Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bgwriter behavior
On Mon, 2004-12-27 at 22:21, Bruce Momjian wrote:
Should we consider at least adjusting the meaning of bgwriter_percent?
Yes. As things stand, this is the only change that seems safe.
Here's a very short patch that implements this change within BufferSync
in bufmgr.c
- No algorithm changes
- No error message changes
- Only change is the call to StrategyDirtyBufferList is made using the
maximum number of buffers that will be cleaned, rather than uselessly
trawling through all of shared_buffers
This changes the meaning of bgwriter_percent from percent of dirty
buffers to percent of shared_buffers. The default settings of 1% of
1000 buffers gives up to 10 dirty block writes every 250ms
Benefit: allows performance tuning by increases options for setting
bgwriter_delay which would otherwise have an ineffectually high minimum
setting
Risk: low
1-line doc patch to follow, if this is approved.
--
Best Regards, Simon Riggs
Index: src/backend/storage/buffer/bufmgr.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/storage/buffer/bufmgr.c,v
retrieving revision 1.182
diff -d -c -r1.182 bufmgr.c
*** src/backend/storage/buffer/bufmgr.c 24 Nov 2004 02:56:17 - 1.182
--- src/backend/storage/buffer/bufmgr.c 30 Dec 2004 23:52:24 -
***
*** 681,686
--- 681,687
{
BufferDesc **dirty_buffers;
BufferTag *buftags;
+ int dirty_buffers_maxlen = 1;
int num_buffer_dirty;
int i;
***
*** 688,717
if (percent == 0 || maxpages == 0)
return 0;
/*
! * Get a list of all currently dirty buffers and how many there are.
* We do not flush buffers that get dirtied after we started. They
! * have to wait until the next checkpoint.
*/
! dirty_buffers = (BufferDesc **) palloc(NBuffers * sizeof(BufferDesc *));
! buftags = (BufferTag *) palloc(NBuffers * sizeof(BufferTag));
LWLockAcquire(BufMgrLock, LW_EXCLUSIVE);
- num_buffer_dirty = StrategyDirtyBufferList(dirty_buffers, buftags,
- NBuffers);
! /*
! * If called by the background writer, we are usually asked to only
! * write out some portion of dirty buffers now, to prevent the IO
! * storm at checkpoint time.
! */
! if (percent 0)
! {
! Assert(percent = 100);
! num_buffer_dirty = (num_buffer_dirty * percent + 99) / 100;
! }
! if (maxpages 0 num_buffer_dirty maxpages)
! num_buffer_dirty = maxpages;
/* Make sure we can handle the pin inside the loop */
ResourceOwnerEnlargeBuffers(CurrentResourceOwner);
--- 689,719
if (percent == 0 || maxpages == 0)
return 0;
+ /* Set number of buffers we will clean at LRUs of buffer lists */
+ if (percent 0 ) {
+ Assert(percent = 100);
+ dirty_buffers_maxlen = (NBuffers * percent + 99) / 100;
+ }
+ if (maxpages 0 dirty_buffers_maxlen maxpages)
+ dirty_buffers_maxlen = maxpages;
+
+ /* if checkpoint time */
+ if (percent == -1 maxpages == -1)
+ dirty_buffers_maxlen = NBuffers;
+
/*
! * Get a list of dirty buffers to clean and how many there are.
* We do not flush buffers that get dirtied after we started. They
! * have to wait until the next call of this function
*/
! dirty_buffers =
! (BufferDesc **) palloc(dirty_buffers_maxlen * sizeof(BufferDesc *));
! buftags = (BufferTag *) palloc(dirty_buffers_maxlen * sizeof(BufferTag));
LWLockAcquire(BufMgrLock, LW_EXCLUSIVE);
! num_buffer_dirty = StrategyDirtyBufferList(dirty_buffers, buftags,
! dirty_buffers_maxlen);
/* Make sure we can handle the pin inside the loop */
ResourceOwnerEnlargeBuffers(CurrentResourceOwner);
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Bgwriter behavior
Simon Riggs wrote: On Mon, 2004-12-27 at 22:21, Bruce Momjian wrote: Should we consider at least adjusting the meaning of bgwriter_percent? Yes. As things stand, this is the only change that seems safe. Here's a very short patch that implements this change within BufferSync in bufmgr.c - No algorithm changes - No error message changes - Only change is the call to StrategyDirtyBufferList is made using the maximum number of buffers that will be cleaned, rather than uselessly trawling through all of shared_buffers This changes the meaning of bgwriter_percent from percent of dirty buffers to percent of shared_buffers. The default settings of 1% of 1000 buffers gives up to 10 dirty block writes every 250ms Benefit: allows performance tuning by increases options for setting bgwriter_delay which would otherwise have an ineffectually high minimum setting Risk: low 1-line doc patch to follow, if this is approved. I am not objecting to the patch, but what value is there in having both bgwriter_percent and bgwriter_maxpages? Seems both are redundant and that one would be enough. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] RC3 in ... ~12 hours ...
Baring any cries of *STOP* ... I'm going to try and get it packaged first thing in the morning ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] rc1 packaged ...
'k, I'm upgraded for 1.79 and RC3 ... On Tue, 21 Dec 2004, Peter Eisentraut wrote: Marc G. Fournier wrote: 'k, I'm about to screw up rc2 for this too ... FreeBSD ports is 'stuck' at 1.78 ... Well, file a bug to get it updated? just went to http://sourceforge.net/projects/docbook, and there are two '1.79's ... do both need to be installed, or just one of them? The second one is the documentation. You don't need that unless you plan to read it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 3: 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
[HACKERS] hardcoded decimal point '.'
NUMERIC data type is hardcoded to use '.' as the decimal point. FLOATs are in fact hardcoded the same way (they use strtod() and sprintf() while pgsql's LC_NUMERIC is always C). The only data type that localizes decimal point is MONEY. it makes many problems when the decimal point is not '.' (for example, ','). is it a bug or a feature? ---(end of broadcast)--- TIP 3: 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
Re: [HACKERS] Shared row locking
Manfred Koizar [EMAIL PROTECTED] writes: On Thu, 30 Dec 2004 13:36:53 -0500, Tom Lane [EMAIL PROTECTED] wrote: Certainly not; indexes depend on locks, not vice versa. You'd not be able to do that without introducing an infinite recursion into the system design. Wouldn't you have to face the same sort of problems if you spill part of the lock table to disk? While you do I/O you have to hold some lock. See LWLocks ... or spinlocks underneath those. But (some) operations on tables and indexes make use of heavyweight locks. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RC3 in ... ~12 hours ...
Yay I assume that any changes will be in CVS at that point? I have a bunch of patches and some new files for the OS/2 port that I plan on submitting as a diff to the 8.0 GA when that comes about. Is that the appropriate time? BTW - I did get all the NLS stuff working as well. Lorne In [EMAIL PROTECTED], on 12/30/04 at 09:38 PM, Marc G. Fournier [EMAIL PROTECTED] said: Baring any cries of *STOP* ... I'm going to try and get it packaged first thing in the morning ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: 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
