Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
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 arrives, postmaster sets the corresp
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, we
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 output
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 fi
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 http://www.w3.org/TR/xpath2
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 (f
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 t
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, and
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 more
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
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.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/plpgsql/before_plpgsql_serv
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
Heikki Linnakangas 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 for function RTEs
>> and I don'
On Wed, Feb 25, 2009 at 6:44 PM, Teodor Sigaev 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 subscription:
htt
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
---
Pavel Stehule 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
--
Sent via pgsql-hackers m
2009/3/2 Tom Lane :
> Pavel Stehule 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
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:
http://archives.postgresql.org/pgsql-patches/
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
ru_RU.KOI8-R=
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
> conversi
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
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 avoid
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
Heikki Linnakangas 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 something into pq_send_raw_string to ch
2009/3/2 Tom Lane :
> Pavel Stehule 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
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. gingetb
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
s
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) || 'days
On Mon, Mar 2, 2009 at 4:43 PM, Merlin Moncure 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 table range as
>>> Tom Lane 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 --- are ther
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 stat
Merlin Moncure 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 pgsql-hackers mailing
On Mon, Mar 2, 2009 at 2:14 PM, Heikki Linnakangas
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 already complained
> about tha
On Mon, Mar 2, 2009 at 3:02 PM, Jeff Davis 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 one. If th
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 o
On Mon, Mar 2, 2009 at 8:29 PM, Tom Lane wrote:
> Merlin Moncure 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.
hm... Why can't you
Merlin Moncure writes:
> On Mon, Mar 2, 2009 at 8:29 PM, Tom Lane wrote:
>> Merlin Moncure 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
>>
Heikki Linnakangas 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 need a completely separate impleme
Hi Suzuki-san,
On Thu, Feb 26, 2009 at 5:03 AM, Koichi Suzuki 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 I updated it.
Re
On Tue, Mar 3, 2009 at 1:47 PM, Fujii Masao wrote:
> Hi Suzuki-san,
>
> On Thu, Feb 26, 2009 at 5:03 AM, Koichi Suzuki 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 yo
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 param
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 t
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] h
43 matches
Mail list logo
