[PATCHES] is it a bug ?
Hello, When selecting (from php) using this select : SELECT msgid,content,timecreated,soa FROM sms_mo WHERE (LOWER(content) LIKE 'club%') AND (da='87000') AND (timecreated '2005-02-18 17:00:00') ORDER BY msgid ASC I get this error : PANIQUE: ERRORDATA_STACK_SIZE exceeded server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. when applying that select into phppgadmin interface there's no error. but when commenting the line : #client_encoding = LATIN9 in /var/lib/pgsql/data/postgresql.conf i will no longer have an error... but got problems with charsets (i use frensh accents and arab characters) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] is it a bug ?
here's what logs contain : ATTENTION: Laisse de côté les caractères UTF-8 inconvertibles 0xc389 ATTENTION: Laisse de côté les caractères UTF-8 inconvertibles 0xf474e9 ATTENTION: Laisse de côté les caractères UTF-8 inconvertibles 0xf474e9 ATTENTION: Laisse de côté les caractères UTF-8 inconvertibles 0xf474e9 ATTENTION: Laisse de côté les caractères UTF-8 inconvertibles 0xf474e9 PANIQUE: ERRORDATA_STACK_SIZE exceeded INSTRUCTION : SELECT MsgId as msgid,Content as content,TimeCreated as tc,SOA as oa FROM sms_mo WHERE ((LOWER(Content) LIKE 'club%')) AND ((DA='87000')) AND (TimeCreated '2005-02-18 17:00:00') ORDER BY MsgId ASC; TRACE: processus serveur (PID 4359) a été arrêté par le signal 6 TRACE: Arrêt des autres processus serveur actifs TRACE: Tous les processus serveur se sont arrêtés, réinitialisation TRACE: le système de bases de données a été interrompu à 2005-02-26 16:11:25 CET TRACE: l'enregistrement du point de vérification est à 0/7BF31E0 TRACE: ré-exécution de l'enregistrement à 0/7BF31E0 ; l'annulation de l'enregistrement est à 0/0 ; arrêt TRUE TRACE: prochain identifiant de transaction : 70998 ; prochain OID : 535489 TRACE: le système de bases de données n'a pas été arrêté proprement ; restauration automatique en cours TRACE: la ré-exécution commence à 0/7BF321C TRACE: enregistrement de longueur nulle sur 0/7C05940 TRACE: ré-exécution faite à 0/7C05918 TRACE: le système de bases de données est prêt On Thu, 3 Mar 2005 09:15:20 +0100, Zouari Fourat [EMAIL PROTECTED] wrote: Hello, When selecting (from php) using this select : SELECT msgid,content,timecreated,soa FROM sms_mo WHERE (LOWER(content) LIKE 'club%') AND (da='87000') AND (timecreated '2005-02-18 17:00:00') ORDER BY msgid ASC I get this error : PANIQUE: ERRORDATA_STACK_SIZE exceeded server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. when applying that select into phppgadmin interface there's no error. but when commenting the line : #client_encoding = LATIN9 in /var/lib/pgsql/data/postgresql.conf i will no longer have an error... but got problems with charsets (i use frensh accents and arab characters) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] is it a bug ?
Zouari Fourat [EMAIL PROTECTED] writes: here's what logs contain : ATTENTION: Laisse de côté les caractères UTF-8 inconvertibles 0xc389 ATTENTION: Laisse de côté les caractères UTF-8 inconvertibles 0xf474e9 ATTENTION: Laisse de côté les caractères UTF-8 inconvertibles 0xf474e9 ATTENTION: Laisse de côté les caractères UTF-8 inconvertibles 0xf474e9 ATTENTION: Laisse de côté les caractères UTF-8 inconvertibles 0xf474e9 PANIQUE: ERRORDATA_STACK_SIZE exceeded [ been expecting someone who knows more than me to step forward, but ... ] What I think is happening here is that PG is expecting the translated messages in your .po files to have the same encoding as your database encoding, but they aren't. Can you convert the .po files to match your preferred encoding? (Obviously this is something we need to improve...) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] is it a bug ?
Tom Lane wrote: [ been expecting someone who knows more than me to step forward, but ... ] What I think is happening here is that PG is expecting the translated messages in your .po files to have the same encoding as your database encoding, but they aren't. Can you convert the .po files to match your preferred encoding? No, this again means that you have to have a consistent database encoding and LC_CTYPE. The gettext library will automatically convert between the original encoding in the file and the encoding at run time as declared by LC_CTYPE. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] is it a bug ?
excuse me but i dont understand what should i do ? On Thu, 3 Mar 2005 11:28:50 +0100, Peter Eisentraut [EMAIL PROTECTED] wrote: Tom Lane wrote: [ been expecting someone who knows more than me to step forward, but ... ] What I think is happening here is that PG is expecting the translated messages in your .po files to have the same encoding as your database encoding, but they aren't. Can you convert the .po files to match your preferred encoding? No, this again means that you have to have a consistent database encoding and LC_CTYPE. The gettext library will automatically convert between the original encoding in the file and the encoding at run time as declared by LC_CTYPE. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] is it a bug ?
Zouari Fourat wrote: excuse me but i dont understand what should i do ? The locale you specified when you ran initdb needs to match the encoding of the database. The equivalent pairs are usually named like this: Locale Encoding de_DELATIN1 [EMAIL PROTECTED] LATIN9 de_DE.utf8 UNICODE Pick the analogous pairs for you language environment. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [INTERFACES] bcc32.mak for libpq broken? (distro 8.0.0) (fwd)
The problem is something else. Gives the same message. Bruce Momjian pgman@candle.pha.pa.us rta: Bernyi Gbor wrote: Dear Bruce, Didn't work: Fatal bcc32.mak 169: No terminator specified for in-line file operator Look forward to hear of you again, Gabor OK, new bcc32.mak attached. It turns out the actions were indented with spaces instead of tabs. -- 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 7: don't forget to increase your free space map settings
Re: [PATCHES] Faster install-sh in C
Alvaro Herrera wrote: I wrote an install program in C. It's supposed to replace the config/install-sh script, limited to the functionality we need, i.e. what is in Makefiles in the Pg main source tree. The main objective of this exercise is to reduce make install execution time; a part of that is being able to install multiple files with one command. What's the status of this patch? -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Display Pg buffer cache (WIP)
Neil Conway wrote: I don't like accessing shared data structures without acquiring the appropriate locks; even if it doesn't break anything, it seems like just asking for trouble. In order to be able to inspect a buffer's tag in Tom's new locking scheme (not yet in HEAD, but will be in 8.1), you need only hold a per-buffer lock. That will mean acquiring and releasing a spinlock for each buffer, which isn't _too_ bad... I am looking at this bit now. I take the first part to mean that don't need to wrap LWLockAcquire(BufMgrLock, LW_EXCLUSIVE) ... LWLockRelease(BufMgrLock) around the inspection of the buffers (?) This per buffer lock, are we talking about LockBuffer(buf, BUFFER_LOCK_SHARE) ... releaseBuffer(buf) ? If so, it looks like I need to do some stuff with ResourceOwners, otherwise ReleaseBuffer will fail (or am I wandering up the wrong track here?). I am using anoncvs from yesterday, so if Tom's new scheme is *very* new I may be missing it. Thanks Mark ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Display Pg buffer cache (WIP)
Mark Kirkwood wrote: If so, it looks like I need to do some stuff with ResourceOwners, otherwise ReleaseBuffer will fail (or am I wandering up the wrong track here?). I am using anoncvs from yesterday, so if Tom's new scheme is *very* new I may be missing it. It's so new, in fact, it's not in CVS yet :) I believe the latest revision of the patch is here: http://archives.postgresql.org/pgsql-patches/2005-02/msg00115.php The locking scheme is described here: http://archives.postgresql.org/pgsql-hackers/2005-02/msg00391.php Holding the per-buffer header spinlock should be enough to ensure the tag doesn't change. To get a globally consistent snapshot of the state of the bufmgr, I believe it should be sufficient to also share-lock the BufMappingLock for the duration of the scan. The latter will prevent new pages from being loaded in the buffer pool, so I'm not sure if it's worth doing. If you do decide to hold the BufMappingLock, it might make sense to: 1. allocate an array of NBuffers elements 2. acquire BufferMappingLock in share mode 3. sequentially scan through the buffer pool, copying data into the array 4. release the lock 5. on each subsequent call to the SRF, format and return an element of the array Which should reduce the time to lock is held. This will require allocating NBuffers * size_of_stats memory (where size_of_stats will be something like 16 bytes). -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Display Pg buffer cache (WIP)
Mark Kirkwood [EMAIL PROTECTED] writes: I am using anoncvs from yesterday, so if Tom's new scheme is *very* new I may be missing it. It's not committed yet ;-) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
