The attached patch changes the existing behaviour of length(char(n)).
Currently, this is what happens:
template1=# select length('blah'::char(10));
length
10
(1 row)
With this patch:
template1=# select length('blah'::char(10));
length
4
(1 row)
This behaviour was
My server just had a bad crash...
At reboot time, the pg_xlog filesystem didn't mount...
The I have those errors at startup...
is there anything can do to recover?
Jan 27 13:24:11 server postgres[3469]: [3-1] LOG: checkpoint record is at 7/B7668
Jan 27 13:24:11 server postgres[3469]: [4-1]
On Jan 25, 2004, at 3:07 AM, Brian Moore wrote:
it's been said that converting a PGresult into xml is trivial and
that's why it hasn't been done in the codebase as of yet. i have seen
much code that writes xml, and many mistakes are made. most often
improper escaping, or writing to a schema/DTD
Scott Lamb wrote:
On Jan 25, 2004, at 3:07 AM, Brian Moore wrote:
PGresult num_rows='1' num_cols='2'
col_desc num='0' type='int4' format='text' name='foo' /
col_desc num='1' type='int4' format='text' name='bar' /
row num='0'
col num='0'1/col
col num='1'2/col
/row
/PGresult
Tom Lane writes
In the second place, what the code is doing is dependent on an
understanding
of the semantics of IN; I'm not sure it's applicable to, say,
WHERE outervar ANY (SELECT innervar FROM ...)
and it's definitely not applicable to
WHERE outervar ALL (SELECT innervar
Tom Lane writes
In the second place, what the code is doing is dependent on an
understanding
of the semantics of IN; I'm not sure it's applicable to, say,
WHERE outervar ANY (SELECT innervar FROM ...)
and it's definitely not applicable to
WHERE outervar ALL (SELECT innervar
I tried to build plperl on 7.4.1,
On my system
perl -MConfig -e 'print $Config{ccdlflags}'
returns
-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE
however the build ends up using
-rpath,$prefix/lib
Dave
--
Dave Cramer
519 939 0336
ICQ # 1467551
I'm curious what the result of a reverse index does on a table with url
like data, so I did the following
create function fn_strrev(text) returns text as 'return reverse($_[0])'
language 'plperl' with (iscachable);
create index r_url_idx on url( fn_strrev(url));
vacuum analyze;
explain
Simon Riggs wrote:
Tom Lane writes
In the second place, what the code is doing is dependent on an
understanding
of the semantics of IN; I'm not sure it's applicable to, say,
WHERE outervar ANY (SELECT innervar FROM ...)
and it's definitely not applicable to
WHERE outervar ALL
On Fri, 2004-01-23 at 00:21, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
AFAIK the only target build environment for Windows right now is MinGW/gcc
If anyone knows how to get the M$ compilers to work nicely with our build
system that might be
My mistake then. Better to check than let
a logical hole in Thanks for letting me know, Simon
-Original
Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Haney
Sent: Tuesday, January 27, 2004
14:33
To: [EMAIL PROTECTED]
Cc: 'Tom Lane';
[EMAIL
Hi
Is it just me, or is there any way a sort could be relevant in a
subquery? (except on queries containing volatile functions)
select a.* from test1 a, (select id from test1 order by num) as b where
a.id = b.id;
There is no constraint on the order of 'a', so why is pull_up_subqueries
I've been looking in the sql200x draft and there are no function calls
with named arguments.
Thinking more about it, I'm not sure if it really is an important addition
at all. I've got a number of requests for the feature. so there are people
that want it, that much I know.
I don't think it's
[EMAIL PROTECTED] writes:
My server just had a bad crash...
At reboot time, the pg_xlog filesystem didn't mount...
So mount it...
If you're trying to say that the xlog is irretrievably hosed, then see
pg_resetxlog, and be prepared to spend some time checking to see if
anything got corrupted.
Dennis Bjorklund wrote:
Thinking more about it, I'm not sure if it really is an important
addition at all. I've got a number of requests for the feature. so
there are people that want it, that much I know.
I like it very much, and I think mostly everyone else does, too. It's
just a question
On Tue, 27 Jan 2004, Tom Lane wrote:
Date: Tue, 27 Jan 2004 12:02:04 -0500
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: [HACKERS] Most urgent
[EMAIL PROTECTED] writes:
My server just had a bad crash...
At reboot time, the
SQL99 part 2 clause 16.1 contains this note:
NOTE 327 - The characteristics of a transaction begun by a
start transaction statement are as specified in these General
Rules regardless of the characteristics specified by any
preceding set transaction statement. That is, even if one
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane writes
In particular, the optimization paths that involve unique-ifying the
subselect output and then using it as the outer side of a join would
definitely not work for these sorts of things.
I'm not sure if I've understood you correctly in the
Dave Cramer [EMAIL PROTECTED] writes:
create index r_url_idx on url( fn_strrev(url));
explain select * from url where url like fn_strrev('%beta12.html');
QUERY PLAN
-
Seq Scan on url (cost=0.00..13281.70 rows=1
On Tue, Jan 27, 2004 at 17:27:25 +0100,
Dennis Haney [EMAIL PROTECTED] wrote:
Is it just me, or is there any way a sort could be relevant in a
subquery? (except on queries containing volatile functions)
Yes. It is important when a limit or distinct on clause is used in a
subquery.
same answer
davec=# show enable_seqscan;
enable_seqscan
off
(1 row)
davec=# explain analyze select * from url where fn_strrev(url) like
'%beta12.html';
QUERY PLAN
On Tue, 27 Jan 2004, Dave Cramer wrote:
same answer
davec=# show enable_seqscan;
enable_seqscan
off
(1 row)
davec=# explain analyze select * from url where fn_strrev(url) like
'%beta12.html';
That's still an unanchored like clause, besides I think that would get
Dave Cramer [EMAIL PROTECTED] writes:
davec=# explain analyze select * from url where fn_strrev(url) like
'%beta12.html';
Don't you need the % at the right end to have an indexable plan?
I suspect that both of your tries so far are actually semantically
wrong, and that what you intend is
Dennis Haney [EMAIL PROTECTED] writes:
There is no constraint on the order of 'a', so why is pull_up_subqueries
explicitly ignoring subqueries that contain an 'order by'?
Because there would be no place to apply the sort operation. If you are
saying you don't want the sort to occur, why did
Tried, all the suggestions
--dc--
davec=# explain analyze select * from url where fn_strrev(url) like
fn_strrev('%beta12.html');
QUERY PLAN
Peter Eisentraut [EMAIL PROTECTED] writes:
Dennis Bjorklund wrote:
Thinking more about it, I'm not sure if it really is an important
addition at all. I've got a number of requests for the feature. so
there are people that want it, that much I know.
I like it very much, and I think mostly
Peter Eisentraut [EMAIL PROTECTED] writes:
SQL99 part 2 clause 16.1 contains this note:
NOTE 327 - The characteristics of a transaction begun by a
start transaction statement are as specified in these General
Rules regardless of the characteristics specified by any
preceding
Dave Cramer [EMAIL PROTECTED] writes:
Tried, all the suggestions
Mph. It works for me... what PG version are you using exactly,
and are you certain you've selected C locale? (Do you get LIKE
optimization on plain indexes?)
regards, tom lane
I'm using 7.4.1, the db was initdb --locale='C'
and no I don't get them on plain indexes
Dave
On Tue, 2004-01-27 at 13:28, Tom Lane wrote:
Dave Cramer [EMAIL PROTECTED] writes:
Tried, all the suggestions
Mph. It works for me... what PG version are you using exactly,
and are you
Ezra Epstein [EMAIL PROTECTED] writes:
I'd like to extend SET SESSION AUTHORIZATION to support a form
which takes a password.
Uh, a password? What purpose would that serve?
For exactly the opposite usage: allowing a non-privileged user to take on a
different authorization IFF a password
Dave Cramer [EMAIL PROTECTED] writes:
I'm using 7.4.1, the db was initdb --locale='C'
and no I don't get them on plain indexes
Oh? If it's 7.4 then you can confirm the locale selection with
show lc_collate and show lc_ctype (I think the first of these
is what the LIKE optimization
On Fri, Jan 23, 2004 at 10:03:30PM -0500, Bruce Momjian wrote:
Steve Atkins wrote:
When I rebuilt libpq to use threads, I started seeing a bunch of weird
failures in many of the older applications. The change in libpq meant
that libpthread was being dynamically linked into the
Bruno Wolff III wrote:
On Tue, Jan 27, 2004 at 17:27:25 +0100,
Dennis Haney [EMAIL PROTECTED] wrote:
Is it just me, or is there any way a sort could be relevant in a
subquery? (except on queries containing volatile functions)
Yes. It is important when a limit or
Steve Atkins wrote:
My guess is that creating applications against the non-thread libpq and
then replacing it with a threaded libpq is your problem.
Yes. It seems to make no difference whether the application is rebuilt
or not. It's pulling libpthread into a non-thread-aware application
Tom Lane wrote:
Dennis Haney [EMAIL PROTECTED] writes:
There is no constraint on the order of 'a', so why is pull_up_subqueries
explicitly ignoring subqueries that contain an 'order by'?
Because there would be no place to apply the sort operation.
Then why spend time
Interesting it works now, and the good news is it is *WAY* faster, this
might be able to speed up marc's doc search by orders of magnitude
this is searching 100536 rows
select * from url where fn_strrev(url) like fn_strrev('%beta12.html');
1.57ms
explain select * from url where url like
Hello,
With the new preload option is there any benefit/drawback to using
pl/Python versus
pl/pgSQL? And no... I don't care that pl/Python is now considered
untrusted.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support,
On Tue, Jan 27, 2004 at 02:07:44PM -0500, Bruce Momjian wrote:
Steve Atkins wrote:
My guess is that creating applications against the non-thread libpq and
then replacing it with a threaded libpq is your problem.
Yes. It seems to make no difference whether the application is rebuilt
Tom Lane wrote:
Are you sure you're reading that correctly?
Not anymore... :-/ Sorry for the noise. I had remembered that in some
context set transaction and set session characteristics were
interchangeable, but apparently I got it all mixed up.
---(end of
On Tue, 27 Jan 2004, Tom Lane wrote:
In particular, how will you avoid individually trawling through every
function with a matching name to try to match up the arguments?
I don't think you can avoid that. But it's just done once to find the oid
of the real function, so if it's used multiple
On Tue, 27 Jan 2004, Peter Eisentraut wrote:
just a question of what syntax to use. Personally, I would be OK with
=.
That's also what I'm leaning towards now. As Greg suggested, just making
= a special case as a function parameter. And if one want's to call a
function with an expression
On Jan 27, 2004, at 1:16 PM, Steve Atkins wrote:
A hint, though, might be that it's a multiprocess application with a
single master process that controls dozens of child processes. When the
master shuts down it asks all the children to shut down, and then it
deadlocks in the SIGCHILD handler.
It's
How feasible would it be to have a btree index on ctid? I'm thinking it ought
to work simply enough for the normal case of insert/delet/update, but I'm not
completely certain how vacuum, vacuum full, and cluster would interact.
You may think this would be utterly useless, but I have a cunning
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Tue, 27 Jan 2004, Tom Lane wrote:
func_select_candidate() that involve comparing matches at the same
argument position will break down completely.
I was planning to reorder the arguments before the matching according to
the function prototype so
The Pl/Java project that I'm working on is progressing quite nicely. The
beta release that I just uploaded to GBorg at
http://gborg.postgresql.org/project/pljava/projdisplay.php has most of the
functionality that I have intended for the first stable release. If you are
interested, please take a
On Tue, 27 Jan 2004, Tom Lane wrote:
speed hits in parsing them, especially not if the hit occurs whether
one uses the named-parameters feature or not ...
I'll read the rest of the mail more careful tomorrow moring, I just want
to point out directly that for calls that doesn't use named
Dennis Haney kirjutas T, 27.01.2004 kell 21:08:
Tom Lane wrote:
Dennis Haney [EMAIL PROTECTED] writes:
There is no constraint on the order of 'a', so why is pull_up_subqueries
explicitly ignoring subqueries that contain an 'order by'?
Because there would be no place to
Bruce Momjian wrote:
Woh, as far as I know, any application should run fine with -lpthread,
threaded or not. What OS are you on? This is the first I have heard of
this problem.
Perhaps we should try to figure out how other packages handle
multithreaded/singlethreaded libraries? I'm looking
Because I've lost a lot of data using postgresql (and I know for sure this
should'nt happen) I've gone a bit further reading documentations on my
disks and...
I have FUJITSU MAP3367NC 36G 1 rpm disks, those disk have a write
cache of 8Mb, if someone could tell me hox to turn it off...
Ezra Epstein [EMAIL PROTECTED] writes:
I do not think SET SESSION AUTH is a suitable replacement for logging
in. For one thing, it doesn't apply per-user GUC settings. For
OK, what are GUC settings. Can SET SESSION AUTH be extended to do this as
needed?
Not very easily; it's not clear to
IDE or SCSI?
Why do you think the WC is screwing you?
Which driver(s)?
LER
--On Tuesday, January 27, 2004 22:34:46 +0100 [EMAIL PROTECTED] wrote:
Because I've lost a lot of data using postgresql (and I know for sure this
should'nt happen) I've gone a bit further reading documentations on my
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 15:38:30 -0600
From: Larry Rosenman [EMAIL PROTECTED]
To: [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: Write cache
IDE or SCSI?
SCSI
Why do you think the WC is screwing you?
Because after a sys
--On Tuesday, January 27, 2004 22:43:34 +0100 [EMAIL PROTECTED] wrote:
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 15:38:30 -0600
From: Larry Rosenman [EMAIL PROTECTED]
To: [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: Write cache
IDE or SCSI?
SCSI
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 15:45:20 -0600
From: Larry Rosenman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: Write cache
--On Tuesday, January 27, 2004 22:43:34 +0100 [EMAIL PROTECTED] wrote:
On
Dennis Bjorklund [EMAIL PROTECTED] writes:
I'll read the rest of the mail more careful tomorrow moring, I just want
to point out directly that for calls that doesn't use named arguments you
get the exact same speed as before. Except for an extra if() to check if
there are named arguments. I
--On Tuesday, January 27, 2004 22:48:42 +0100 [EMAIL PROTECTED] wrote:
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 15:45:20 -0600
From: Larry Rosenman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: Write cache
--On Tuesday,
Hannu Krosing [EMAIL PROTECTED] writes:
Dennis Haney kirjutas T, 27.01.2004 kell 21:08:
I'm saying the sort makes no sense. So why even bother executing it?
why did you write it?
I believe the most common scenario would be that the subquery was
expanded from a view...
And why is it
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 15:55:49 -0600
From: Larry Rosenman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: Write cache
--On Tuesday, January 27, 2004 22:48:42 +0100 [EMAIL PROTECTED] wrote:
On
--On Tuesday, January 27, 2004 23:01:45 +0100 [EMAIL PROTECTED] wrote:
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 15:55:49 -0600
From: Larry Rosenman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: Write cache
--On Tuesday,
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 16:02:40 -0600
From: Larry Rosenman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: Write cache
--On Tuesday, January 27, 2004 23:01:45 +0100 [EMAIL PROTECTED] wrote:
On
--On Tuesday, January 27, 2004 23:03:56 +0100 [EMAIL PROTECTED] wrote:
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 16:02:40 -0600
From: Larry Rosenman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: Write cache
--On Tuesday,
As a more direct response, there *are* reasons for people to put ORDER
BY in a subselect and expect it to be honored. The typical example
that's been discussed several times in the archives is that you want to
use an aggregate function that is sensitive to the ordering of its input
Not to
Rod Taylor [EMAIL PROTECTED] writes:
As a more direct response, there *are* reasons for people to put ORDER
BY in a subselect and expect it to be honored. The typical example
that's been discussed several times in the archives is that you want to
use an aggregate function that is sensitive to
Greg Stark [EMAIL PROTECTED] writes:
How feasible would it be to have a btree index on ctid?
Why would you want one? Direct access by ctid beats out an index lookup
every time. In any case, vacuum and friends would break such an index
entirely.
regards, tom lane
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
How feasible would it be to have a btree index on ctid?
Why would you want one? Direct access by ctid beats out an index lookup
every time.
Of course. But as I mentioned, I have a cunning plan.
If you have two
[EMAIL PROTECTED] wrote:
Nothing special... And any option I could use would'nt change a thing:
the cache is on the disk itself... I did'nt look physicaly yet but
according to the docs there's no way to disable it lik I always did on
IBM...
I was forced to buy those disk (more expensive, not
Greg Stark [EMAIL PROTECTED] writes:
If you have two indexes (a,ctid) and (b,ctid) and do a query where a=1 and b=2
then it would be particularly easy to combine the two efficiently.
If specially marked btree indexes -- or even all btree indexes -- implicitly
had ctid as a final sort order
On 01/27/04:04/2, Joshua D. Drake wrote:
With the new preload option is there any benefit/drawback to using
pl/Python versus
pl/pgSQL? And no... I don't care that pl/Python is now considered
untrusted.
Feature-wise I'm not exactly sure how pl/Python matches up against pl/pgSQL,
but
Andreas Pflug [EMAIL PROTECTED] writes:
This would be the first time a SCSI disk lies about its write caching.
There are plenty of low-cost (i.e. IDE) disks out there having a hidden
write cache, but AFAIK a generic SCSI tool is usable to enable/disable
the write cache.
A SCSI disk
Bruce Momjian wrote
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If the TODO-list-with-dash isn't the correct place to have looked,
is
there another list of committed changes for the next release?
We tend to rely on the CVS commit logs as the definitive source.
You
can
POSTGRESQL: Summary of Changes since last release (7.4.1)
--
26 Jan 2004
This is a summary of most changes since code versions marked 7_4_1,
rather than a weekly news bulletin, a summary of desired future items,
or the definitive list of
Tom Lane wrote:
Okay ... Chris was kind enough to let me examine the WAL logs and
postmaster stderr log for his recent problem, and I believe that
I have now achieved a full understanding of what happened. The true
bug is indeed somewhere else than slru.c, and we would not have found
it if
Hi,
We have serious problems past 4 days in receiving mail lists from
postgresql.org. Subscribers living in the jp domain are receiving via
a relay host named powergres.sra.co.jp (this is an authorized relay
host for jp domain, and this configuration has been approved by Marc).
After checking
looking into it ... seems somewhere upstream changed their DNS config to
not pull our reverse information ... just had someone else point it out to
me as well :(
I've removed the jp relay temporarily, since it is failing, and hope to
have it resolved within the next 24hrs ...
Thanks ...
On
Tom Lane [EMAIL PROTECTED] writes:
I don't think so. You are thinking only of exact-equality queries ---
as soon as the WHERE clause describes a range of index entries, the
readout wouldn't be sorted by ctid anyway.
But then even bitmap indexes would fail in that way too, or at least have a
Hi,
We have serious problems past 4 days in receiving mail lists from
postgresql.org. Subscribers living in the jp domain are receiving via
a relay host named powergres.sra.co.jp (this is an authorized relay
host for jp domain, and this configuration has been approved by Marc).
After
It seems reverse look up for svr1.postgresql.org fails.
Due to this sendmail denies to receive mails relayed by
svr1.postgresql.org (200.46.204.71).
Jan 25 04:09:55 powergres sendmail[9622]:
i0OJ9qY09622:
ruleset=check_rcpt,
arg1=[EMAIL PROTECTED],
Greg Stark [EMAIL PROTECTED] writes:
Combining indexes via a bitmap intermediate step (which is not really
the same thing as bitmap indexes, IIUC) seems like a more robust
approach than relying on the index entries to be in ctid order.
I would see that as the next step, But it seems to me it
78 matches
Mail list logo
