On Tue, Sep 11, 2007 at 11:27:50AM +0900, Tatsuo Ishii wrote:
SELECT * FROM japanese_table ORDER BY convert(japanese_text using
utf8_to_euc_jp);
Without using convert(), he will get random order of data. This is
because Kanji characters are in random order in UTF-8, while Kanji
characters
On Tue, 2007-09-11 at 14:50 +0900, Tatsuo Ishii wrote:
On Tue, 2007-09-11 at 12:29 +0900, Tatsuo Ishii wrote:
Please show me concrete examples how I could introduce a
vulnerability
using this kind of convert() usage.
Try the sequence below. Then, try to dump and then reload the
Try the sequence below. Then, try to dump and then reload the database.
When you try to reload it, you will get an error:
ERROR: invalid byte sequence for encoding UTF8: 0xbd
I know this could be a problem (like chr() with invalid byte pattern).
And that's enough of a problem already. We
On Tue, 2007-09-11 at 14:50 +0900, Tatsuo Ishii wrote:
On Tue, 2007-09-11 at 12:29 +0900, Tatsuo Ishii wrote:
Please show me concrete examples how I could introduce a
vulnerability
using this kind of convert() usage.
Try the sequence below. Then, try to dump and then reload
On Tue, 11 Sep 2007, Teodor Sigaev wrote:
I tried to understand how ts_rank works, but I failed. What does Cover
function do? How does it work? What is the DocRepresentation data
structure like? I can see the definition of the struct, and the
get_docrep function to convert to that format, but
Andrew Dunstan wrote:
Instead of the code point, I'd prefer the actual encoding of
the character as argument to chr() and return value of ascii().
And frankly, I don't know how to do it sanely anyway. A character
encoding has a fixed byte pattern, but a given byte pattern
doesn't have
a
Tom Lane wrote:
I thought about ways to include GUC settings directly into CREATE
FUNCTION, but it seemed pretty ugly and inconsistent with the
existing syntax. So I'm thinking of supporting only the above
syntaxes, meaning it'll take at least two commands to create a secure
SECURITY DEFINER
I've completed a review of all of the LWlocking in the backends. This is
documented in the enclosed file. I would propose that we use this as
comments in lwlock.h or in the README, if people agree.
A number of points emerge from that analysis:
1. The ProcArrayLock is acquired Exclusive-ly by
On Wed, 2006-09-13 at 21:45 -0400, Tom Lane wrote:
Anyway, given that there's this one nonobvious gotcha, there might be
others. My recommendation is that we take this off the open-items list
for 8.2 and revisit it in the 8.3 cycle when there's more time.
Well, its still 8.3 just...
As
On 9/11/07, Simon Riggs [EMAIL PROTECTED] wrote:
5. ReadNewTransactionId() is only called now by GetNextXidAndEpoch(),
but I can't find a caller of that anywhere in core or contrib. Can those
now be removed?
GetNextXidAndEpoch() is needed for external modules to use
8-byte transaction ids
On Tue, 2007-09-11 at 13:31 +0300, Marko Kreen wrote:
On 9/11/07, Simon Riggs [EMAIL PROTECTED] wrote:
5. ReadNewTransactionId() is only called now by GetNextXidAndEpoch(),
but I can't find a caller of that anywhere in core or contrib. Can those
now be removed?
GetNextXidAndEpoch() is
Marko Kreen wrote:
On 9/9/07, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
I brought back clownfish(still a bit dubious about the unexplained
failures which seem vmware emulation bugs but this one seems to be
easily reproduceable) onto the buildfarm and enabled --with-openssl
after the the
On Tue, 11 Sep 2007, Tom Lane wrote:
dugong has been failing contribcheck repeatably for the last day or so,
with a very interesting symptom: CREATE DATABASE is failing with
The reason for that is that I've been trying to switch from 9.1 to 10.0
version of the ICC compiler. A month ago, I've
Sergey E. Koposov [EMAIL PROTECTED] writes:
On Tue, 11 Sep 2007, Tom Lane wrote:
dugong has been failing contribcheck repeatably for the last day or so,
with a very interesting symptom: CREATE DATABASE is failing with
The reason for that is that I've been trying to switch from 9.1 to 10.0
Simon Riggs [EMAIL PROTECTED] writes:
As discussed in the other thread Final Thoughts for 8.3 on LWLocking
and Scalability, XidCacheRemoveRunningXids() is now the only holder of
an X lock during normal processing,
Nonsense. Main transaction exit also takes an exclusive lock, and is
far more
Zdenek Kotala [EMAIL PROTECTED] writes:
I have a question about what does happen if search path is not defined
for SECURITY DEFINER function. My expectation is that SECURITY DEFINER
function should defined empty search patch in this case.
Your expectation is incorrect. We are not in the
This could be a compiler bug, or it could be our fault --- might need
a volatile on some pointer or other, for example, to prevent the
compiler from making an otherwise legitimate assumption. So it seems
worth chasing it down.
Tom, Thank you for the directions, I'll try to do what you
Simon Riggs [EMAIL PROTECTED] writes:
1. The ProcArrayLock is acquired Exclusive-ly by only one remaining
operation: XidCacheRemoveRunningXids(). Reducing things to that level is
brilliant work, Florian and Tom.
It would be brilliant if it were true, but it isn't. Better look again.
On 9/11/07, Zdenek Kotala [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
This is crashing because of the crippled OpenSSL on some version
of Solaris. Zdenek Kotala posted a workaround for that, I am
cleaning it but have not found the time to finalize it.
I'll try to post v03 of Zdenek's
Since the money type has a locale dependent input and output format, there has
to be some context saved when a database dump is created. For example, if
your environment uses a locale that uses the opposite point-vs-comma
conventions from English (e.g., de_DE), then the following will fail to
On Tue, 2007-09-11 at 10:21 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
1. The ProcArrayLock is acquired Exclusive-ly by only one remaining
operation: XidCacheRemoveRunningXids(). Reducing things to that level is
brilliant work, Florian and Tom.
It would be brilliant if
Sergey E. Koposov [EMAIL PROTECTED] writes:
BTW, does ICC have any switch corresponding to gcc's -fno-strict-aliasing?
I see that configure tries to feed that switch to it, but it might
want some other spelling.
Apparently in none of the ICC manuals -fno-strict-aliasing is described,
but
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I have a question about what does happen if search path is not defined
for SECURITY DEFINER function. My expectation is that SECURITY DEFINER
function should defined empty search patch in this case.
Your expectation is incorrect. We
Marko Kreen wrote:
On 9/11/07, Zdenek Kotala [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
This is crashing because of the crippled OpenSSL on some version
of Solaris. Zdenek Kotala posted a workaround for that, I am
cleaning it but have not found the time to finalize it.
I'll try to post v03
On Tue, 2007-09-11 at 09:58 -0400, Tom Lane wrote:
Can we let go of this for 8.3, please?
OK, we've moved forward, so its a good place to break.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 1: if
Well, the first thing I'd suggest is trying to localize which Assert
makes it fail. From the bug's behavior I think it is highly probable
that the problem is in fsync signalling, which puts it either in
bgwriter.c or md.c. Try recompiling those modules separately without
cassert (leaving all
Actually, in the log file I also see some messages about has_seq_search:
КОМАНДА: CREATE DATABASE contrib_regression TEMPLATE=template0
NOTICE: database contrib_regression does not exist, skipping
ERROR: too many active hash_seq_search scans
ERROR: too many active hash_seq_search scans
Sergey E. Koposov [EMAIL PROTECTED] writes:
Actually, in the log file I also see some messages about has_seq_search:
=EB=EF=ED=E1=EE=E4=E1: CREATE DATABASE contrib_regression TEMPLATE=3Dtem=
plate0
NOTICE: database contrib_regression does not exist, skipping
ERROR: too many active
On Mon, 2007-09-10 at 23:20 -0400, Tom Lane wrote:
The reason we have a problem here is that we've been choosing
convenience over safety in encoding-related issues. I wonder if we must
stoop to having a strict_encoding_checks GUC variable to satisfy
everyone.
That would be satisfactory to
Sergey E. Koposov [EMAIL PROTECTED] writes:
Actually, in the log file I also see some messages about has_seq_search:
ERROR: too many active hash_seq_search scans
ERROR: too many active hash_seq_search scans
ERROR: too many active hash_seq_search scans
BTW, I just made a commit to include
Am Dienstag, 11. September 2007 15:53 schrieb Tom Lane:
Zdenek Kotala [EMAIL PROTECTED] writes:
I have a question about what does happen if search path is not defined
for SECURITY DEFINER function. My expectation is that SECURITY DEFINER
function should defined empty search patch in this
It seems to me last run
(http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dugongdt=2007-09-11%2016:05:01)
points to problem with hash implementation.
*** ./expected/tsdicts.out Tue Sep 11 20:05:23 2007
--- ./results/tsdicts.out Tue Sep 11 20:18:38 2007
***
*** 301,306
Teodor Sigaev [EMAIL PROTECTED] writes:
It seems to me last run
(http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dugongdt=2007-09-11%2016:05:01)
points to problem with hash implementation.
dynahash.c is used all over the system, though. If it were broken by a
compiler issue, it's hard to
On Tue, 11 Sep 2007, Tom Lane wrote:
NOTICE: database contrib_regression does not exist, skipping
ERROR: too many active hash_seq_search scans
ERROR: too many active hash_seq_search scans
ERROR: too many active hash_seq_search scans
ERROR: too many active hash_seq_search scans
With
Peter Eisentraut [EMAIL PROTECTED] writes:
Well, a SECURITY DEFINER function either sets its own search path, in which
case a default search path would have no effect, or it doesn't set its own
search path, in which case it's already broken (albeit in a different way).
So setting a default
Sergey E. Koposov [EMAIL PROTECTED] writes:
On Tue, 11 Sep 2007, Tom Lane wrote:
NOTICE: database contrib_regression does not exist, skipping
ERROR: too many active hash_seq_search scans
ERROR: too many active hash_seq_search scans
ERROR: too many active hash_seq_search scans
ERROR: too
On Tue, 11 Sep 2007, Tom Lane wrote:
Sergey E. Koposov [EMAIL PROTECTED] writes:
On Tue, 11 Sep 2007, Tom Lane wrote:
NOTICE: database contrib_regression does not exist, skipping
ERROR: too many active hash_seq_search scans
ERROR: too many active hash_seq_search scans
ERROR: too many
Sergey E. Koposov [EMAIL PROTECTED] writes:
Yes, indeed. After several make installcheck's
I get
ERROR: too many active hash_seq_search scans, cannot start one on smgr
relation table
ERROR: too many active hash_seq_search scans, cannot start one on smgr
relation table
Hm, so that must
Simon Riggs wrote:
On Tue, 2007-09-11 at 10:21 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
1. The ProcArrayLock is acquired Exclusive-ly by only one
remaining operation: XidCacheRemoveRunningXids(). Reducing things
to that level is brilliant work, Florian and Tom.
It would
Jeff Davis [EMAIL PROTECTED] writes:
On Mon, 2007-09-10 at 23:20 -0400, Tom Lane wrote:
It might work the way you are expecting if the database uses SQL_ASCII
encoding and C locale --- and I'd be fine with allowing convert() only
when the database encoding is SQL_ASCII.
I prefer this option.
On Tue, 2007-09-11 at 14:48 -0400, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
On Mon, 2007-09-10 at 23:20 -0400, Tom Lane wrote:
It might work the way you are expecting if the database uses SQL_ASCII
encoding and C locale --- and I'd be fine with allowing convert() only
when the
On Tue, 2007-09-11 at 19:32 +0200, Florian G. Pflug wrote:
Simon Riggs wrote:
On Tue, 2007-09-11 at 10:21 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
1. The ProcArrayLock is acquired Exclusive-ly by only one
remaining operation: XidCacheRemoveRunningXids(). Reducing
Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
On Mon, 2007-09-10 at 23:20 -0400, Tom Lane wrote:
It might work the way you are expecting if the database uses SQL_ASCII
encoding and C locale --- and I'd be fine with allowing convert() only
when the database encoding is SQL_ASCII.
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think really the technically cleanest solution would be to make
convert() return bytea instead of text; then we'd not have to put
restrictions on what encoding or locale it's working inside of.
However, it's not clear to me whether
Peter Eisentraut [EMAIL PROTECTED] writes:
Since the money type has a locale dependent input and output format, there
has
to be some context saved when a database dump is created. For example, if
your environment uses a locale that uses the opposite point-vs-comma
conventions from
Tatsuo Ishii [EMAIL PROTECTED] writes:
If we make convert() operate on bytea and return bytea, as Tom
suggested, would that solve your use case?
The problem is, the above use case is just one of what I can think of.
Another use case is, something like this:
SELECT
Sergey E. Koposov wrote:
With hash_seq_search ERROR, it was partially a false alarm. I've had
some old postgres daemon hanging around and writing that to the log.
Although I remember seeing that hash_seq_search message recently when
dealing with this bug, it does not show up in the course
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Since the money type has a locale dependent input and output format, there
has
to be some context saved when a database dump is created. For example, if
your environment uses a locale that uses the opposite point-vs-comma
On Tue, 11 Sep 2007, Andrew Dunstan wrote:
Your buildfarm member must be seriously misconfigured if you can get the logs
from different postmasters comingled. Every run gets its own logfile in its
own inst directory.
No, everything I'm doing now about that bug, I'm doing in the very
Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
8.0.14, 7.4.18, 7.3.20. The CVS branches are nearly ready. The
releases will happen sometime early next week. The packagers have been
contacted.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB
Bruce Momjian wrote:
Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
8.0.14, 7.4.18, 7.3.20. The CVS branches are nearly ready. The
releases will happen sometime early next week. The packagers have been
contacted.
Does this mean that if I commit something in these days
Alvaro Herrera wrote:
Bruce Momjian wrote:
Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
8.0.14, 7.4.18, 7.3.20. The CVS branches are nearly ready. The
releases will happen sometime early next week. The packagers have been
contacted.
Does this mean that if I
While editing Bruce's README.HOT documentation I ran into a problem.
I had idly added the following text after thinking about the different
sorts of snapshots we use:
---
Another unpleasant consequence is that it is no longer very meaningful to
use SnapshotAny in an index scan: if the index was
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
This risk seems rather overstated, as it's unlikely that someone using
money would choose to reload their data into a DB with a fundamentally
incompatible locale setting.
It doesn't sound unlikely at all to me. For example,
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
This risk seems rather overstated, as it's unlikely that someone using
money would choose to reload their data into a DB with a fundamentally
incompatible locale setting.
It doesn't sound unlikely at all to
I found CVS HEAD is broken and the following error is reported.
My environment is RHEL4 Update 2 x86_64 with gcc 3.4.4 and flex 2.5.33.
In file included from ../../../src/include/port.h:17,
from ../../../src/include/c.h:841,
from
I just saw that my buildfarm member (running ICC 9.0 on linux) failed
after the latest change to configure
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2007-09-11%2020:45:01
I was the one who sent in the first patch to configure to add the check
for ICC, and as I recall at the
Hi hackers,
I note that we currently expose the usefulness of the quote_identifier
function to the user with quote_ident(text).
Is there any reason we shouldn't do the same with quote_qualified_identifier?
We could just add a quote_qualified_ident(text, text) ... it would
make forming dynamic
On 9/12/07, Tom Lane [EMAIL PROTECTED] wrote:
It would break functions that actually want to use a caller-specified
search path, and protect themselves by explicitly schema-qualifying
every other reference than one to some caller-specified object. Which
admittedly is notationally a pain in
However ISTM we would also need something like
length(bytea, name) returns int
-- counts the number of characters assuming that the bytea is in
-- the given encoding
Hmm, I wonder if counting chars is consistent regardless of the
encoding the string is in. To me it sounds
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
The suspect is flex (or yy template file). It defines __unused to
be empty, but netdb.h uses __unused as a variable.
Egad. Shouldn't there be villagers breaking down the flex hackers'
front door with torches and pitchforks in hand? Why is it our
Jeremy Drake [EMAIL PROTECTED] writes:
I just saw that my buildfarm member (running ICC 9.0 on linux) failed
after the latest change to configure
Argh! Can someone quote chapter and verse from the ICC manual about
this? I was just following what Sergey said was the approved spelling
of the
On Wed, 12 Sep 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
I just saw that my buildfarm member (running ICC 9.0 on linux) failed
after the latest change to configure
Argh! Can someone quote chapter and verse from the ICC manual about
this? I was just following what
63 matches
Mail list logo
