On 2005-10-26, Tom Lane [EMAIL PROTECTED] wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2005-10-26, Tom Lane [EMAIL PROTECTED] wrote:
Uh, no ... the global setting of add_missing_from does *not* tell you
anything about whether there exist views in the database that were
created under
Stefan Kaltenbrunner wrote:
Seneca Cunningham wrote:
On an powerPC AIX 5.3 box, initdb from 8.1beta4 segfaults at
src/backend/utils/hash/dynahash.c:673. No segfaults occur and all 98
regression tests pass if a test is added to see if keycopy is memcpy and
if it is, go through a loop memcpying
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Christopher Kings-Lynne wrote:
TODO item done for 8.2:
* Add PQescapeIdentifier() to libpq
Someone probably
I talked with neilc in #postgresql about a tool that may help in
determining a suitable rpc value. If rpc is just ratio of random cost
vs. sequential cost, then I can write such a tool. So I did.
The tool takes a directory and do sequential read on all the files
there, followed by exhaustive
Sorry, I should have CC'ed hackers on this. The issue is that because
of interval_justify_hours(), subtracting a fixed interval from a
timestamp and re-adding the same value produces a different result.
---
Bruce Momjian
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Robert Treat wrote:
ISTM even a GUC to enable/disable would have been better scheme than
what we have now; we are basically leaving no options for those who
found the old behavior useful, while what we had before would at least
let
Michael Paesold wrote:
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Robert Treat wrote:
ISTM even a GUC to enable/disable would have been better scheme than
what we have now; we are basically leaving no options for those who
found the old behavior useful, while what we had
Bruce Momjian wrote:
Michael Paesold wrote:
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Robert Treat wrote:
ISTM even a GUC to enable/disable would have been better scheme than
what we have now; we are basically leaving no options for those who
found the old behavior
[ bugs list removed, hackers added.]
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I saw a lot of disussion because I forgot to specify that my tests were
for EST5EDT, but what about the use of interval_justify_hours() in
timestamp_mi(). Is this something we want to
Should we allow CREATE VIEW to run with add_missing_from = true until
we fix CREATE VIEW to handle this cleanly? We emit a warning when we
add a missing FROM too, as I remember.
---
Andrew - Supernews wrote:
On
Bruce Momjian pgman@candle.pha.pa.us writes:
Keep in mind that the addition of the interval_justify_hours() did
generate some regression test changes, so removing
interval_justify_hours() might just take the results back to what we had
in 8.0.
Not hardly. I tried already. The existing
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Keep in mind that the addition of the interval_justify_hours() did
generate some regression test changes, so removing
interval_justify_hours() might just take the results back to what we had
in 8.0.
Not hardly. I tried
If you are going to roll this back in 8.1 to reevaluate the issue, I
think the ANSI/ISO standards should be reviewed as part of that
reevaluation. The standard seems rich enough in this area to
address all of the concerns I've seen expressed on this thread.
All the usual advantages for standards
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Not hardly. I tried already. The existing timestamp_mi behavior is
probably as close to 8.0 as we can get given the change in underlying
representation.
You mean the '6432 hours' is a worse change, OK.
Well, it's sure not a
Hi there folks
I created custom type, and attempt to create gist indexing for it, to
make search wind quick.
on select from * where something 'something'; I get:
WARNING: problem in alloc set GiST temporary context: detected write
past chunk end in block 0x843e6e0, chunk 0x843e994
Can
Kevin Grittner [EMAIL PROTECTED] writes:
The standard seems rich enough in this area to
address all of the concerns I've seen expressed on this thread.
All the usual advantages for standards compliance accrue, as well.
Last I checked, the standard completely failed to deal with daylight
Yohanes Santoso wrote:
I then ran it on various database size on a software 2 7200RPM IDE
RAID-1 volume. I found out that if the dbase size (as from du
dbase_dir) is less than about 500M, I got a ratio of 4.5:1. On a
larger dbase, 3GB, the ratio increases to 10:1.
Surely this is going
Bruce Momjian pgman@candle.pha.pa.us writes:
Should we allow CREATE VIEW to run with add_missing_from = true until
we fix CREATE VIEW to handle this cleanly?
No. Not only is that horridly ugly, it doesn't fix the problem, because
CREATE VIEW is just one case (see also CREATE RULE). If we were
Grzegorz Jaskiewicz [EMAIL PROTECTED] writes:
I created custom type, and attempt to create gist indexing for it, to
make search wind quick.
on select from * where something 'something'; I get:
WARNING: problem in alloc set GiST temporary context: detected write
past chunk end in block
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2005-10-26, Tom Lane [EMAIL PROTECTED] wrote:
Pretending it's the user's mistake isn't
an answer that fits down my craw very well...
I'm not claiming it's the user's mistake. My point is that if the user
did in fact remove add_missing_from
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I found that bgwriter increments usage count of buffers when it writes
the buffers. I feel this behavior is strange, because the behavior of
bgwriter will affect buffer management strategy.
Good point --- we probably don't want it to do that.
If the
On Wednesday 26 October 2005 17:48, Tom Lane wrote:
Looks like you're scribbling on memory that doesn't belong to you.
Check for miscomputed palloc request sizes, etc.
Thanks very much for the tip. I thogut perhaps I am not filling out some parts
of structures, or something.
Can I use valgrind
btw, if you could read russian, we have GiST programming tutorial
http://www.sai.msu.su/~megera/postgres/talks/gist_tutorial.html
Oleg
On Wed, 26 Oct 2005, Tom Lane wrote:
Grzegorz Jaskiewicz [EMAIL PROTECTED] writes:
I created custom type, and attempt to create gist indexing for it,
On Wednesday 26 October 2005 18:34, Oleg Bartunov wrote:
btw, if you could read russian, we have GiST programming tutorial
http://www.sai.msu.su/~megera/postgres/talks/gist_tutorial.html
I did try, but last time I did Russian lessons was around 10 years ago, so ...
babel fish could help btw, but
Ok, I got it, google is my friend ;)
...
Can I use valgrind to find out the root of problem. If so, how should I
invoke it with postgres. Postgres it self was configured with:
...
--
GJ
Binary system, you're either 1 or 0...
dead or alive ;)
---(end of
I cant get the IMMUTABLE modifier meaning.
The 'testme' IMMUTABLE function is invoked 3 times
in the following query:
# select testme(1), testme(1), testme(1);
NOTICE: called
NOTICE: called
NOTICE: called
testme | testme | testme
++
ret| ret|
In the libpq COPY interface function PQputCopyData():
/*
* Check for NOTICE messages coming back from the server. Since the
* server might generate multiple notices during the COPY, we have to
* consume those in a reasonably prompt fashion to prevent the comm
* buffers from filling up and
I'm not seeing it. It seems to me that timestamps can be defined
WITH or WITHOUT time zone, and the semantics of calculating an
interval are fairly clear in either case. An interval doesn't seem
like it should have an associated time zone. Adding an interval
to a timestamp would use the time
strk [EMAIL PROTECTED] writes:
Why is so ? shouldn't the IMMUTABLE keywork make
it a single call ?
No. There is no function value cache. What does happen here is that
the planner folds those calls to constants at plan time, instead of at
run time. Try
select testme(1) from
Alon Goldshuv [EMAIL PROTECTED] writes:
As the code comment suggests, it is extremely important to consume incoming
messages from the server to prevent deadlock. However we should only worry
about it before sending data out.
And, unfortunately, you've broken it. The pqFlush call visible in
Fair warning this was in 8.1beta1 so perhaps this is fixed already.
[EMAIL PROTECTED]:~$ ./start80.sh
pg_ctl: another postmaster may be running; trying to start postmaster anyway
FATAL: pre-existing shared memory block (key 5480001, ID 4063233) is still in
use
HINT: If you're sure there are
Tom,
After sleeping on it, I feel that we should probably just fix the code
(to make the problem go away going forward) and document the possible
need to turn on add_missing_from to load old dump files as an
incompatibility. We've had worse ones.
I'll agree with you here, for (1) reason: if
Hi list
I got memleak fixed, valgrind doesn't quite find problems there, I had to dig
it manually.
Anyway, to the point.
Now that I've created gist index, I want to use it on table, here it goes:
CREATE OPERATOR CLASS gist_enum2916_operators
DEFAULT FOR TYPE enum2916 USING gist
AS
On Wed, Oct 26, 2005 at 11:41:56AM -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Should we allow CREATE VIEW to run with add_missing_from = true
until we fix CREATE VIEW to handle this cleanly?
No. Not only is that horridly ugly, it doesn't fix the problem,
because
I hate to answer my own question, but I think I may have spotted
the issue. I forgot that a TIMESTAMP WITH TIME ZONE is
actually stored without a time zone. This datatype would need
to better comply with the ANSI/ISO standard for the ANSI/ISO
operations on them to work properly.
-Kevin
Kevin
Robert Treat [EMAIL PROTECTED] writes:
the difference being that in 8.0 we printed the full path of the pid file, in
8.1 we do not. there could be a good reason for this,
Yeah: it's now being accessed by a relative path (relative to $PGDATA,
which we have already chdir'd into at this point).
Tom,
And, unfortunately, you've broken it. The pqFlush call visible in that
routine is not the only place that may try to send data (see also
pqPutMsgEnd).
You are right, thanks for pointing that out.
Still, in pqPutMsgEnd we will be sending data only after 8K is reached,
which is about
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
the difference being that in 8.0 we printed the full path of the pid file,
in
8.1 we do not. there could be a good reason for this,
Yeah: it's now being accessed by a relative path (relative to $PGDATA,
which we have already
On 2005-10-26, Tom Lane [EMAIL PROTECTED] wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2005-10-26, Tom Lane [EMAIL PROTECTED] wrote:
Pretending it's the user's mistake isn't
an answer that fits down my craw very well...
I'm not claiming it's the user's mistake. My point is that if
I wrote:
Neil Conway [EMAIL PROTECTED] writes:
On Tue, 2005-25-10 at 17:43 -0400, Tom Lane wrote:
What I suggest we do about this is change addImplicitRTE() to set
inFromCl true for implicitly added RTEs, so that the view rule will
later be dumped as if the query had been written per spec.
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yeah: it's now being accessed by a relative path (relative to $PGDATA,
which we have already chdir'd into at this point).
So we should include PGDATA in the error message (DataDir actually, I
guess).
I don't think that follows. The
On Wednesday 26 October 2005 14:59, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
the difference being that in 8.0 we printed the full path of the pid
file, in 8.1 we do not. there could be a good reason for this,
Yeah: it's now being accessed by a relative path (relative to
Can anyone explain to me why 'localhost' in a .pgpass file matches both
a Unix socket and a tcp localhost connection?
Also, there is no documentation at all that I can see to cover the Unix
socket case. I found the information after much looking through asking
on IRC, where luckily [EMAIL
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yeah: it's now being accessed by a relative path (relative to $PGDATA,
which we have already chdir'd into at this point).
So we should include PGDATA in the error message (DataDir actually, I
guess).
I don't
I've got a customer who was having a problem with a backend running away
with memory. It would hit 46G before finally being running the box
completely out of memory. It didn't appear to be related to hashjoin/agg
or pending triggers, so I had them recompile with debug and assert
turned on. A bit
Jim C. Nasby [EMAIL PROTECTED] writes:
TRAP: FailedAssertion(!((itemid)-lp_flags 0x01), File: nbtsearch.c,
Line: 89)
Looking through the code I see that's something to do with indexes, but
I'm not sure what. Is this likely a corrupted index?
Sounds that way.
If so, is there some way I
On Wed, Oct 26, 2005 at 04:48:22PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
TRAP: FailedAssertion(!((itemid)-lp_flags 0x01), File: nbtsearch.c,
Line: 89)
Looking through the code I see that's something to do with indexes, but
I'm not sure what. Is this likely a
Jim C. Nasby [EMAIL PROTECTED] writes:
On Wed, Oct 26, 2005 at 04:48:22PM -0400, Tom Lane wrote:
Sounds that way.
Is this something that should be logged better than it is?
We don't even know what it is yet, so that question seems a bit premature.
Is there any value in trying to save the
On Mon, Oct 17, 2005 at 09:30:24PM +0100, Simon Riggs wrote:
On Mon, 2005-10-17 at 14:55 -0500, Jim C. Nasby wrote:
On Tue, Oct 11, 2005 at 10:58:58AM +0100, Simon Riggs wrote:
On Mon, 2005-10-10 at 15:14 -0500, Kevin Grittner wrote:
We are looking at doing much more with PostgreSQL over
On Wed, Oct 26, 2005 at 04:03:41PM -0500, Jim C. Nasby wrote:
Is this something that should be logged better than it is? Is there any
value in trying to save the index/table that's busted?
Unfortuatly, it's one of those Assert(expr) lines, they don't generally
give the opportunity for extra
On Tue, Oct 18, 2005 at 06:15:02PM -0400, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
do we maintain anything anywhere for this? mainly, some way of
determining # of 'sorts to disk' vs 'sort in memory', to determine whether
or not sort_mem is set to a good value?
As of
On Wed, Oct 26, 2005 at 11:14:17PM +0200, Martijn van Oosterhout wrote:
On Wed, Oct 26, 2005 at 04:03:41PM -0500, Jim C. Nasby wrote:
Is this something that should be logged better than it is? Is there any
value in trying to save the index/table that's busted?
Unfortuatly, it's one of
Jim C. Nasby [EMAIL PROTECTED] writes:
On Wed, Oct 26, 2005 at 11:14:17PM +0200, Martijn van Oosterhout wrote:
Well, you know the query that generates it?
Well, since query logging only logs when a query finishes...
Don't forget to look at debug_query_string when you get the core file.
On Wed, 26 Oct 2005, Jim C. Nasby wrote:
On Tue, Oct 18, 2005 at 06:15:02PM -0400, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
do we maintain anything anywhere for this? mainly, some way of
determining # of 'sorts to disk' vs 'sort in memory', to determine whether
or not
On Tue, Oct 25, 2005 at 04:37:34PM -0400, Yohanes Santoso wrote:
All of this goes to uphold Tom's general assertion that the default of 4 is
more or less correct
Doesn't this show that 4:1 is a pretty optimistic value considering
that no long-running db files are fragmentation-free?
On Wed, Oct 26, 2005 at 05:47:15PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Wed, Oct 26, 2005 at 11:14:17PM +0200, Martijn van Oosterhout wrote:
Well, you know the query that generates it?
Well, since query logging only logs when a query finishes...
Don't forget
On Wed, Oct 26, 2005 at 06:50:49PM -0300, Marc G. Fournier wrote:
On Wed, 26 Oct 2005, Jim C. Nasby wrote:
On Tue, Oct 18, 2005 at 06:15:02PM -0400, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
do we maintain anything anywhere for this? mainly, some way of
determining # of
On Wed, Oct 26, 2005 at 04:48:22PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
TRAP: FailedAssertion(!((itemid)-lp_flags 0x01), File: nbtsearch.c,
Line: 89)
Looking through the code I see that's something to do with indexes, but
I'm not sure what. Is this likely a
Jim C. Nasby [EMAIL PROTECTED] writes:
Reproduced the crash, but still no core file... where exactly should it
have been put? Would in be outside of $PGDATA?
In 8.0 I'd expect to find it in $PGDATA/base/DBOID/core (or possibly
core.). There are some platforms like Darwin that tend to put
On Wed, Oct 26, 2005 at 06:38:45PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Reproduced the crash, but still no core file... where exactly should it
have been put? Would in be outside of $PGDATA?
In 8.0 I'd expect to find it in $PGDATA/base/DBOID/core (or possibly
On Wed, Oct 26, 2005 at 06:06:19PM -0500, Jim C. Nasby wrote:
On Wed, Oct 26, 2005 at 06:38:45PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Reproduced the crash, but still no core file... where exactly should it
have been put? Would in be outside of $PGDATA?
In 8.0
Jim C. Nasby [EMAIL PROTECTED] writes:
Is there any way to verify what limits are in place for a running
backend?
Damifino.
Also, is an assert guaranteed to dump core?
Yup ... at least, it will call abort().
regards, tom lane
---(end of
Tom,
FreeBSD 5.4 Opteron 64 SMP pass.
--Josh
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On Mon, Oct 24, 2005 at 05:07:40AM -, Andrew - Supernews wrote:
I'm inclined to suspect that the whole sequence c1 f9 d4 c2 d0 c7 d2 b9
was never actually a valid utf-8 string, and that the d2 b9 is only valid
by coincidence (it's a Cyrillic letter from Azerbaijani). I know the 8.0
Jim C. Nasby [EMAIL PROTECTED] writes:
Is there anything in particular you'd like to see from the index file? I
made a copy of it before reindexing...
Could you send me the whole file (off-list)?
regards, tom lane
---(end of
does strip out the invalid characters. However, iconv reads the
entire file into memory before it writes out any data. This is not so
good for multi-gigabyte dump files and doesn't allow for it to be used
in a pipe between pg_dump and psql.
Anyone have any other recommendations? GNU
However I'm running into another problem now. The command:
iconv -c -f UTF8 -t UTF8
does strip out the invalid characters. However, iconv reads the
entire file into memory before it writes out any data. This is not so
good for multi-gigabyte dump files and doesn't allow for it to be used
Josh Berkus wrote:
Tom,
FreeBSD 5.4 Opteron 64 SMP pass.
BSD/OS 4.3.1 i386 SMP passes.
--
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
Hi all,
I am new user of postgres.. I am currently working on a project
for my advisor and the project is to implement an algorithm for
materialiazed view design as explained in this paper
[http://www.vldb.org/conf/1997/P136.PDF - MVPP Generation part and sec
4.1 for selecting views as
Andrej Ricnik-Bay wrote:
How about an ugly kludge ...
split -a 3 -d -b 1048576 ../path/to/dumpfile dumpfile
for i in `ls -1 dumpfile*`; do iconv -c -f UTF8 -t UTF8 $i;done
cat dumpfile* new_dump
Not with UTF-8... You might break in the middle of a multibyte character.
Jeroen
70 matches
Mail list logo
