Re: [HACKERS] Immediate shutdown and system(3)

2009-03-02 Thread Heikki Linnakangas
Fujii Masao wrote: On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: I'm leaning towards option 3, but I wonder if anyone sees a better solution. 4. Use the shared memory to tell the startup process about the shutdown state. When a shutdown signal

Re: [HACKERS] xpath processing brain dead

2009-03-02 Thread Peter Eisentraut
Andrew Dunstan wrote: can you point me at any call in libxml2 which will evaluate an xpath expression in the context of a nodeset instead of a document? Quite apart from anything else, xpath requires there to be a (single) context node (see http://www.w3.org/TR/xpath20/#context ). For a doc,

Re: [HACKERS] a proposal for an extendable deparser

2009-03-02 Thread Heikki Linnakangas
Dave Gudeman wrote: I don't need to add new node types or add any syntax; it is the output that I'm concerned with. What I want is a way to print a tree according to some pretty strict rules. For example, I want a special syntax for function RTEs and I don't want the v::type notation to be

Re: [HACKERS] xpath processing brain dead

2009-03-02 Thread Simon Riggs
On Sun, 2009-03-01 at 18:22 -0500, Andrew Dunstan wrote: I think the XML type needs to conform to the SQL/XML spec. However, we are trying to apply XPath, which has a different data model, to that type - hence the impedance mismatch. I think that the best we can do (for 8.4, having fixed

Re: [HACKERS] xpath processing brain dead

2009-03-02 Thread Andrew Dunstan
Peter Eisentraut wrote: Andrew Dunstan wrote: can you point me at any call in libxml2 which will evaluate an xpath expression in the context of a nodeset instead of a document? Quite apart from anything else, xpath requires there to be a (single) context node (see

Re: [HACKERS] xpath processing brain dead

2009-03-02 Thread Andrew Dunstan
Simon Riggs wrote: On Sun, 2009-03-01 at 18:22 -0500, Andrew Dunstan wrote: I think the XML type needs to conform to the SQL/XML spec. However, we are trying to apply XPath, which has a different data model, to that type - hence the impedance mismatch. I think that the best we can do

Re: [HACKERS] xpath processing brain dead

2009-03-02 Thread Hannu Krosing
On Mon, 2009-03-02 at 07:54 -0500, Andrew Dunstan wrote: Simon Riggs wrote: On Sun, 2009-03-01 at 18:22 -0500, Andrew Dunstan wrote: I think the XML type needs to conform to the SQL/XML spec. However, we are trying to apply XPath, which has a different data model, to that type -

Re: [HACKERS] xpath processing brain dead

2009-03-02 Thread Peter Eisentraut
Hannu Krosing wrote: Is it just that in you _can't_ use Xpath on fragments, and you _need_ to pass full documents to Xpath ? At least this is my reading of Xpath standard. It is easy to read the XPath standard that way, because the concept of fragments is not defined outside of SQL/XML,

Re: [HACKERS] xpath processing brain dead

2009-03-02 Thread Andrew Dunstan
Hannu Krosing wrote: Is it just that in you _can't_ use Xpath on fragments, and you _need_ to pass full documents to Xpath ? At least this is my reading of Xpath standard. I think that's possibly overstating it., unless I have missed something (W3 standards are sometimes not much

Re: [HACKERS] xpath processing brain dead

2009-03-02 Thread Hannu Krosing
On Mon, 2009-03-02 at 15:25 +0200, Peter Eisentraut wrote: Hannu Krosing wrote: Is it just that in you _can't_ use Xpath on fragments, and you _need_ to pass full documents to Xpath ? At least this is my reading of Xpath standard. It is easy to read the XPath standard that way,

Re: [HACKERS] Re: [COMMITTERS] pgsql: Redefine _() to dgettext() instead of gettext() so that it uses

2009-03-02 Thread Hiroshi Saito
Hi Peter-san. I see the problem for being an original domain in plpgsql. It differs from what codeset meant at postmaster by Japanese windows Please see, this look at the problem on which SJIS enters into a message.

Re: [HACKERS] regression test crashes at tsearch

2009-03-02 Thread Teodor Sigaev
Um, I think your patch like the overkill reaction of C-locale... Patch makes char2wchar and wchar2char symmetric to C-locale. However, I tried your patch. make check MULTIBYTE=euc_jp NO_LOCALE=true ... === All 120 tests passed. === Anyway, either should

Re: [HACKERS] a proposal for an extendable deparser

2009-03-02 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Dave Gudeman wrote: I don't need to add new node types or add any syntax; it is the output that I'm concerned with. What I want is a way to print a tree according to some pretty strict rules. For example, I want a special syntax

Re: [HACKERS] regression test crashes at tsearch

2009-03-02 Thread Greg Stark
On Wed, Feb 25, 2009 at 6:44 PM, Teodor Sigaev teo...@sigaev.ru wrote: mbstowcs/wcstombs doesn't work with C-locale in other OSes too, so that's not needed. Say what? What OSes is that? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

[HACKERS] proposal: psql - breaking rows in white chars for wrapped format

2009-03-02 Thread Pavel Stehule
Hello Current wrapped format doesn't break rows well (after white chars). I propose change this behave (to more typical for text): Current: postgres=# \pset format wrappedOutput format is wrapped. postgres=# select a from test; a

Re: [HACKERS] proposal: psql - breaking rows in white chars for wrapped format

2009-03-02 Thread Tom Lane
Pavel Stehule pavel.steh...@gmail.com writes: Current wrapped format doesn't break rows well (after white chars). I propose change this behave (to more typical for text): This was suggested and rejected already. Please read the earlier thread. regards, tom lane --

Re: [HACKERS] proposal: psql - breaking rows in white chars for wrapped format

2009-03-02 Thread Pavel Stehule
2009/3/2 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: Current wrapped format doesn't break rows well (after white chars). I propose change this behave (to more typical for text): This was suggested and rejected already.  Please read the earlier thread.          

[HACKERS] GIN, partial matches, lossy bitmaps

2009-03-02 Thread Heikki Linnakangas
While reading the GIN code, I just rediscovered that the GIN partial match support suffers from the same problem that I criticized the fast insert patch about, and searching the archives I found that I already complained about that back in April:

Re: [HACKERS] regression test crashes at tsearch

2009-03-02 Thread Teodor Sigaev
Say what? What OSes is that? See attached test program. It tries to convert multibyte russian word in UTF8 to wide char with C, ru_RU-KOI8-R and ru_RU.UTF-8 locales. The word contains 6 letters. FreeBSD 7.2 (short output): C== mbstowcs returns 12

Re: [HACKERS] [BUGS] BUG #4680: Server crashed if using wrong (mismatch) conversion functions

2009-03-02 Thread Tom Lane
I wrote: In any case, that's orthogonal to the part that I was focusing on, which was to try to prevent error recursion as a result of trouble in the encoding conversion subsystem. It looks like we could do that with some additional hacking in send_message_to_frontend() to avoid conversion,

Re: [HACKERS] regression test crashes at tsearch

2009-03-02 Thread Greg Stark
Hmm well the KOI8 tests unsurprisingly produce random results on non- KOI8 input. It's pure chance you didn't get EILSEQ. What errno did you get for the C locale test? On which input character? Perhaps it's sihnalljng EILSEQ for every byte 0x80 ? That seems broken to me but perhaps not to a

[HACKERS] Re: [BUGS] BUG #4680: Server crashed if using wrong (mismatch) conversion functions

2009-03-02 Thread Heikki Linnakangas
Tom Lane wrote: I wrote: In any case, that's orthogonal to the part that I was focusing on, which was to try to prevent error recursion as a result of trouble in the encoding conversion subsystem. It looks like we could do that with some additional hacking in send_message_to_frontend() to

[HACKERS] sanity check on max_fsm_relations

2009-03-02 Thread Robert Treat
I have an app that needs to create about 50 partitions per day. I'm planning to boost up max_fsm_relations to about 100,000, so I won't have to worry about changing it again until I can upgrade to 8.4 ;-) According to the docs, this should take about 6MB of shmem, which is no big deal, but I'm

Re: [HACKERS] [BUGS] BUG #4680: Server crashed if using wrong (mismatch) conversion functions

2009-03-02 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Looks ok to me. I'm still a bit uneasy about the assumption that the error message is 7-bit ACII. Maybe that's just because I don't fully understand all the conditions how we can end up in recursion, so I would still put

Re: [HACKERS] proposal: psql - breaking rows in white chars for wrapped format

2009-03-02 Thread Pavel Stehule
2009/3/2 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: Current wrapped format doesn't break rows well (after white chars). I propose change this behave (to more typical for text): This was suggested and rejected already.  Please read the earlier thread.          

Re: [HACKERS] GIN, partial matches, lossy bitmaps

2009-03-02 Thread Jeff Davis
On Mon, 2009-03-02 at 21:14 +0200, Heikki Linnakangas wrote: If I'm reading the code correctly, item pointers of all matching heap tuples are first collected into a TIDBitmap, and then amgetnext returns tuples from that one by one. If the bitmap becomes lossy, an error is thrown.

Re: [HACKERS] regression test crashes at tsearch

2009-03-02 Thread Teodor Sigaev
Hmm well the KOI8 tests unsurprisingly produce random results on non-KOI8 input. It's pure chance you didn't get EILSEQ. Because KOI8 is not multibyte encoding. What errno did you get for the C locale test? On which input character?Perhaps it's sihnalljng EILSEQ for every byte 0x80 ? That

[HACKERS] statistics horribly broken for row-wise comparison

2009-03-02 Thread Merlin Moncure
It looks like for row-wise comparison, only the first column is used for generating the expected row count. This can lead to bad plans in some cases. Test case (takes seconds to minutes hardware depending): create table range as select v as id, v % 500 as key, now() + ((random() * 1000) ||

Re: [HACKERS] statistics horribly broken for row-wise comparison

2009-03-02 Thread Merlin Moncure
On Mon, Mar 2, 2009 at 4:43 PM, Merlin Moncure mmonc...@gmail.com wrote: It looks like for row-wise comparison, only the first column is used for generating the expected row count.  This can lead to bad plans in some cases. Test case (takes seconds to minutes hardware depending): create

Re: [HACKERS] add_path optimization

2009-03-02 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote: After a lot of distractions, I've finished applying the planner fixes that seem necessary in view of your report about poorer planning in 8.4 than 8.3. When you have a chance, it would be useful to do a thorough test of CVS HEAD on your data and query mix

Re: [HACKERS] Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets

2009-03-02 Thread Bryce Cutt
Here is the new patch. Our experiments show no noticeable performance issue when using the patch for cases where the optimization is not used because the number of extra statements executed when the optimization is disabled is insignificant. We have updated the patch to remove a couple of if

Re: [HACKERS] statistics horribly broken for row-wise comparison

2009-03-02 Thread Tom Lane
Merlin Moncure mmonc...@gmail.com writes: It looks like for row-wise comparison, only the first column is used for generating the expected row count. [ shrug... ] Short of multi-column statistics, it's hard to see how to do better. regards, tom lane -- Sent via

Re: [HACKERS] GIN, partial matches, lossy bitmaps

2009-03-02 Thread Robert Haas
On Mon, Mar 2, 2009 at 2:14 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: While reading the GIN code, I just rediscovered that the GIN partial match support suffers from the same problem that I criticized the fast insert patch about, and searching the archives I found that I

Re: [HACKERS] GIN, partial matches, lossy bitmaps

2009-03-02 Thread Robert Haas
On Mon, Mar 2, 2009 at 3:02 PM, Jeff Davis pg...@j-davis.com wrote: On Mon, 2009-03-02 at 21:14 +0200, Heikki Linnakangas wrote: If I'm reading the code correctly, item pointers of all matching heap tuples are first collected into a TIDBitmap, and then amgetnext returns tuples from that one by

Re: [HACKERS] Hot standby, running xacts, subtransactions

2009-03-02 Thread Robert Treat
On Wednesday 25 February 2009 16:43:54 Simon Riggs wrote: On Wed, 2009-02-25 at 13:33 -0800, Josh Berkus wrote: You raised that as an annoyance previously because it means that connection in hot standby mode may be delayed in cases of heavy, repeated use of significant numbers of

Re: [HACKERS] statistics horribly broken for row-wise comparison

2009-03-02 Thread Merlin Moncure
On Mon, Mar 2, 2009 at 8:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: Merlin Moncure mmonc...@gmail.com writes: It looks like for row-wise comparison, only the first column is used for generating the expected row count. [ shrug... ]  Short of multi-column statistics, it's hard to see how to do

Re: [HACKERS] statistics horribly broken for row-wise comparison

2009-03-02 Thread Tom Lane
Merlin Moncure mmonc...@gmail.com writes: On Mon, Mar 2, 2009 at 8:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: Merlin Moncure mmonc...@gmail.com writes: It looks like for row-wise comparison, only the first column is used for generating the expected row count. [ shrug... ]  Short of

Re: [HACKERS] Immediate shutdown and system(3)

2009-03-02 Thread ITAGAKI Takahiro
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: 1. Implement a custom version of system(3) using fork+exec that let's us trap SIGQUIT and send e.g SIGTERM or SIGINT to the child instead. It might be a bit tricky to get this right in a portable way; Windows would certainly

Re: [HACKERS] V4 of PITR performance improvement for 8.4

2009-03-02 Thread Fujii Masao
Hi Suzuki-san, On Thu, Feb 26, 2009 at 5:03 AM, Koichi Suzuki koichi@gmail.com wrote: My reply to Gregory's comment didn't have any objections.   I believe, as I posted to Wiki page, latest posted patch is okay and waiting for review. One of your latest patches doesn't match with HEAD, so

Re: [HACKERS] V4 of PITR performance improvement for 8.4

2009-03-02 Thread Fujii Masao
On Tue, Mar 3, 2009 at 1:47 PM, Fujii Masao masao.fu...@gmail.com wrote: Hi Suzuki-san, On Thu, Feb 26, 2009 at 5:03 AM, Koichi Suzuki koichi@gmail.com wrote: My reply to Gregory's comment didn't have any objections.   I believe, as I posted to Wiki page, latest posted patch is okay and

[HACKERS] SIGHUP during recovery

2009-03-02 Thread Fujii Masao
Hi, Currently, the startup process ignores SIGHUP. The attached patch allows the startup process to re-read config file: when SIGHUP arrives, the startup process also receives the signal from postmaster and reload the settings in main redo apply loop. Obviously, this is useful to change the

[HACKERS] Why do we keep UnusedLock1 in LWLockId?

2009-03-02 Thread ITAGAKI Takahiro
Hi, There is UnusedLock1 in LWLockId enumerations in storage/lwlock.h . | UnusedLock1,/* FreeSpaceMapLock used to be here */ I thought it is for keeping LWLockId same as 8.3 at first, but we've already split SInvalLock to SInvalReadLock and SInvalWriteLock. So

[HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1668)

2009-03-02 Thread KaiGai Kohei
The series of SE-PostgreSQL patches for v8.4 were updated: [1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1668.patch [2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1668.patch [3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1668.patch [4/5]