Re: [PATCHES] [PERFORM] [pgsql-hackers-win32] scalability issues on win32
Attached patch solves the problem for me.Didn't see anything of the problem you described about hangs in my implementation. Probably because mine exits at the first sign of a linebreak. I confirmed the fix. 8.0.0 now starts up with net start (this is where I first noticed the problem). When I get some time I'll investigate if this is related to the problems I was having with the statistics collector. Merlin ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [PERFORM] [pgsql-hackers-win32] scalability issues on win32
Magnus Hagander [EMAIL PROTECTED] writes: Attached patch solves the problem for me.Didn't see anything of the problem you described about hangs in my implementation. Probably because mine exits at the first sign of a linebreak. Applied with some trivial legibility improvements. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] From latin9 to sql_ascii??
Jaime Casanova [EMAIL PROTECTED] writes: Here's the *fixed* patch it's up to you wich one to use. I applied this one. 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: [PATCHES] LockObject patch
Alvaro Herrera [EMAIL PROTECTED] writes: Here is the LockObject patch I was able to come up with. It's almost the same patch that Rod Taylor published two years ago; basically, it expands LOCKTAG with a ClassId attribute, and provides a LockObject method to allow locking arbitrary objects. I wonder whether it wouldn't be possible to clean up the XactLockTable kluge with this --- ie, instead of denoting transaction locks by a special relation ID, denote them by a special class ID. That might just move the kluginess from one place to another, but it's worth thinking about. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] Update for french pg_resetxlog.po file
Hi all, Here is the last update for french .po files. Please apply to current branch. Thanks. -- Guillaume. !-- http://abs.traduc.org/ http://lfs.traduc.org/ http://traduc.postgresqlfr.org/ -- pg_resetxlog-fr.po.bz2 Description: application/bzip ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] LockObject patch
On Mon, Dec 20, 2004 at 03:09:31PM -0500, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Here is the LockObject patch I was able to come up with. It's almost the same patch that Rod Taylor published two years ago; basically, it expands LOCKTAG with a ClassId attribute, and provides a LockObject method to allow locking arbitrary objects. I wonder whether it wouldn't be possible to clean up the XactLockTable kluge with this --- ie, instead of denoting transaction locks by a special relation ID, denote them by a special class ID. That might just move the kluginess from one place to another, but it's worth thinking about. How about locking the special class InvalidOid? We don't use that ATM AFAICS. Anything else would require having a special relation registered, which is where we are now ... -- Alvaro Herrera ([EMAIL PROTECTED]) La rebeldía es la virtud original del hombre (Arthur Schopenhauer) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] LockObject patch
Alvaro Herrera wrote: On Mon, Dec 20, 2004 at 03:09:31PM -0500, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Here is the LockObject patch I was able to come up with. It's almost the same patch that Rod Taylor published two years ago; basically, it expands LOCKTAG with a ClassId attribute, and provides a LockObject method to allow locking arbitrary objects. I wonder whether it wouldn't be possible to clean up the XactLockTable kluge with this --- ie, instead of denoting transaction locks by a special relation ID, denote them by a special class ID. That might just move the kluginess from one place to another, but it's worth thinking about. How about locking the special class InvalidOid? We don't use that ATM AFAICS. When we roll over OID's do we make sure we never return InvalidOid? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend
Re: [PATCHES] LockObject patch
On Mon, Dec 20, 2004 at 03:52:57PM -0500, Bruce Momjian wrote: When we roll over OID's do we make sure we never return InvalidOid? Yes. From GetNewObjectId() /* * Check for wraparound of the OID counter. We *must* not return 0 * (InvalidOid); and as long as we have to check that, it seems a good * idea to skip over everything below BootstrapObjectIdData too. (This * basically just reduces the odds of OID collision right after a wrap * occurs.) Note we are relying on unsigned comparison here. */ -- Alvaro Herrera ([EMAIL PROTECTED]) Es filósofo el que disfruta con los enigmas (G. Coli) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] LockObject patch
Alvaro Herrera [EMAIL PROTECTED] writes: On Mon, Dec 20, 2004 at 03:09:31PM -0500, Tom Lane wrote: I wonder whether it wouldn't be possible to clean up the XactLockTable kluge with this --- ie, instead of denoting transaction locks by a special relation ID, denote them by a special class ID. That might just move the kluginess from one place to another, but it's worth thinking about. How about locking the special class InvalidOid? We don't use that ATM AFAICS. No, that's not an improvement --- if the solution doesn't allow multiple classes of objects then we've not made any step forward. We probably ought to step back and think about what objects we need to be able to lock and what the identifying values are for each kind of object. Offhand I think we have: Whole relations: DBID, REL OID (with special case DBID=0 for shared rels) Pages within rels: DBID, REL OID, BLOCKNUM (same special case) Individual tuples (assuming we go the lockmanager route for this): DBID, REL OID, BLOCKNUM, OFFNUM (same special case) Transactions: XID (would sub-XID be of any use??) Non-relation objects: DBID, CLASS OID, OBJECT OID, OBJECT SUBID (it's reasonable to use DBID=0 for shared objects, eg users) (we could possibly dispense with subid but for now let's assume the same representation as in pg_depend and pg_description) Userlocks: DBID, ID1, ID2 (current implementation limits ID1 to 16 bits, but we could widen that if we wanted) Basically I think what we've got to decide is how to overlay these fields and how to tell the six cases apart. Since subids and offnums are only 16 bits, we could pack all of these cases into 64 bits with a 16-bit type identifier to distinguish the cases. That would mean that LOCKTAG doesn't get any bigger than it is now, and we'd have plenty of room for expansion still with more types. 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: [PATCHES] plperl: enable UTF-8 support
I need someone who understands UTF8 and perl to review this before being applied. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- David Kamholz wrote: Hello, Here's a patch I added against plperl, originally against beta5, now against rc1. It simply checks with GetDatabaseEncoding() if the current database is in UTF-8, and if so, sets the UTF-8 flag on the arguments that are passed to perl. This means that it isn't necessary to utf8::upgrade() every string, as perl has no way of knowing offhand that a string is UTF-8 -- but postgres does, because the database encoding is specified, so it makes sense to turn the flag on. You should also be able to properly manipulate UTF-8 strings now from plperl as opposed to plperlu, because otherwise you'd have to use encoding 'utf8' which was not allowed. It could also eliminate some unexpected bugs if you assume that perl knows the string is unicode. It is enabled only for perl 5.6 and higher, so earlier versions will not be affected. I have been assured by crab that the patch is quite harmless and will not break anything. It would be great to see it in 8 final! :-) Regards, Dave [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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
Re: [PATCHES] plperl: enable UTF-8 support
Moved: This has been saved for the 8.1 release: http:/momjian.postgresql.org/cgi-bin/pgpatches2 --- David Kamholz wrote: Hello, Here's a patch I added against plperl, originally against beta5, now against rc1. It simply checks with GetDatabaseEncoding() if the current database is in UTF-8, and if so, sets the UTF-8 flag on the arguments that are passed to perl. This means that it isn't necessary to utf8::upgrade() every string, as perl has no way of knowing offhand that a string is UTF-8 -- but postgres does, because the database encoding is specified, so it makes sense to turn the flag on. You should also be able to properly manipulate UTF-8 strings now from plperl as opposed to plperlu, because otherwise you'd have to use encoding 'utf8' which was not allowed. It could also eliminate some unexpected bugs if you assume that perl knows the string is unicode. It is enabled only for perl 5.6 and higher, so earlier versions will not be affected. I have been assured by crab that the patch is quite harmless and will not break anything. It would be great to see it in 8 final! :-) Regards, Dave [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 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: [PATCHES] plperl: enable UTF-8 support
Bruce Momjian [EMAIL PROTECTED] writes: I need someone who understands UTF8 and perl to review this before being applied. I looked at it and felt that we couldn't risk it for 8.0 --- although the patch looks simple enough, we don't really know the consequences for compatibility with different Perl versions. I wouldn't object to applying it for 8.1, I just think it's too risky at this point in the 8.0 cycle. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] plperl: enable UTF-8 support
No problem. Moved to 8.1 patches queue. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I need someone who understands UTF8 and perl to review this before being applied. I looked at it and felt that we couldn't risk it for 8.0 --- although the patch looks simple enough, we don't really know the consequences for compatibility with different Perl versions. I wouldn't object to applying it for 8.1, I just think it's too risky at this point in the 8.0 cycle. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend
