out the false alarm, then.
This is from the git gateway as hosted here:
http://repo.or.cz/w/PostgreSQL.git
Owner: [EMAIL PROTECTED]
See the backlog for REL8_3_STABLE here:
http://repo.or.cz/w/PostgreSQL.git?a=shortlog;h=REL8_3_STABLE
As far as I can tell, aside from this problem the branch looks go
h REL8_3_STABLE:
configure
configure.in
doc/bug.template
src/include/pg_config.h.win32
src/interfaces/libpq/libpq.rc.in
src/port/win32ver.rc
Patch with a possible solution attached.
Best regards,
--
Tomas Szepe <[EMAIL PR
> Tomas Szepe <[EMAIL PROTECTED]> writes:
> >> Are you doing anything that would involve lots of updates in these
> >> catalogs --- maybe repeatedly renaming a column, or something like that?
>
> > Hmm, I typically use a pair of
> > "ALTER TABLE
ble DISABLE TRIGGER USER;"/
"ALTER TABLE table ENABLE TRIGGER USER;"
per almost every relation when loading a dump, other than that there's
only the initial db creation code (lots of plpgsql triggers and a couple
immutable functions) and then using temp tables for complicated q
here.
Well, I've never hacked on postgresql, so probably all I can do
is tar/rzip the whole data dir and put it up for download somewhere
(there is no sensitive data).
Thanks for your help,
--
Tomas Szepe <[EMAIL PROTECTED]>
postgresql.conf.gz
Description: application/gunzip
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
0x081cc4ba in exec_simple_query (
query_string=0x83f7c88 "vacuum full verbose analyze;") at postgres.c:963
#10 0x081cd23d in PostgresMain (argc=4, argv=0x83843b0, username=0x8384390
"kala")
at postgres.c:3530
#11 0x081a6785 in ServerLoop () at postmaster.c:3
ng "pg_tablespace" --- only table or database owner can vacuum
it
WARNING: skipping "pg_pltemplate" --- only table or database owner can vacuum
it
VACUUM
This is on x86 Linux. 8.2.6 does not exhibit the problem, or at least I haven't
run into it. What info do I need
o the CVS logs, this was reverted in beta4 --- you sure you
> are testing the right beta?
Yes, I'm 100% positive I'm running 8.3beta4.
Thanks,
--
Tomas Szepe <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 1: if posting/readi
avior
in this respect?
Thanks,
--
Tomas Szepe <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message
28.php
The patch didn't apply on top of vanilla 8.2.2, so I fetched the
current 8.2 CVS head - seems to work fine with our production db.
Thanks!
--
Tomas Szepe <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
EOF
CREATE FUNCTION
CREATE TABLE
CREATE INDEX
ERROR: attribute 1 has wrong type
DETAIL: Table has type character varying, but query expects character varying.
$
Just putting back the old 8.2.1 binaries is enough
(the problem disappears), no need to redump/reinitdb.
System: Linux 2.6.20, x86, gli
screwed up. Or maybe not...
>
> my dump file was as1.out so I...
>
> psql < as1.out
The data went into the $(whoami) database per default.
--
Tomas Szepe <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 6: Have you sea
On Nov-04 2003, Tue, 09:24 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Tomas Szepe <[EMAIL PROTECTED]> writes:
> > Martin, you can probably rule out the cs_CZ (LATIN2) locale as the cause
> > of your problems -- I've been using that one for years on many produc
cs_CZ (LATIN2) locale as the cause
of your problems -- I've been using that one for years on many production
postgres systems (often huge and constantly loaded) and have never observed
the problems you're describing.
--
Tomas Szepe <[EMAIL PROTECTED]>
---
On Oct-15 2003, Wed, 02:08 -0400
Nayib Kiuhan <[EMAIL PROTECTED]> wrote:
> "date" timestamp DEFAULT 'now'
I believe you should be using
"date" timestampt DEFAULT CURRENT_TIMESTAMP(0)
--
Tomas Szepe <[EMAIL PROTECTED]>
nly
increasing by ~100 MiB a day, which, by my calculations, is roughly
proportional to the frequency of data added. (There is still
some minor overhead all right, but it's far from serious.)
So again it's a big thank-you to the whole postgres development
group for yet a
pg_catalog.setval ('seq_wtmp', 3928, true);
pgsql7.4beta3$ pg_dump -a -t seq_wtmp db1
pg_dump: specified table "seq_wtmp" does not exist
seq_wtmp is a perfectly normal sequence.
Bye,
--
Tomas Szepe <[EMAIL PROTECTED]>
--
-
Limit (cost=5152.26..5152.31 rows=20 width=104)
InitPlan
-> Limit (cost=0.00..1.11 rows=1 width=8)
-> Index Scan Backward using stats_hr_start on stats_hr
(cost=0.00..12059890.93 rows=10847279 width=8)
-> Sort (cost=5152.26..5162.55 rows=
> [EMAIL PROTECTED]
>
> Tomas Szepe wrote:
> >>[EMAIL PROTECTED]
> >>
> >>
> >>>indexes:
> >>>stats_min_pkey primary key btree (ip, "start")
> >>>stats_min_start btree ("start")
> >>>stats_h
7.4 should be able to recycle index space
> in that situation, but 7.3 and before can't.
OK, I'll definitely try 7.4 once I'm confident with it.
Thanks for your time,
--
Tomas Szepe <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
.
> > Hmm, you seem to suggest that we might expect a change in this regard
> > as 7.4 ships. Is that right?
>
> 7.4 should improve matters.
Trouble is, I probably can't give it a try on the production machine
unless I'm sure it won't trash the data
ic tables are stats_min and stats_hr.
--
Tomas Szepe <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
> [EMAIL PROTECTED]
>
> Tomas Szepe <[EMAIL PROTECTED]> writes:
> > I'm afraid so. The weird thing is, we once tried running
> > VACUUM FULL followed by REINDEX and although the process
> > took ages to complete, it didn't seem to help either. :(
>
> [EMAIL PROTECTED]
>
> Tomas Szepe <[EMAIL PROTECTED]> writes:
> > We have a production database that happens to receive several
> > thousand row updates per minute. We VACUUM ANALYZE every four
> > hours with max_fsm_pages set to 210, and it'
> [EMAIL PROTECTED]
>
> On Fri, 26 Sep 2003, Tomas Szepe wrote:
>
> > > [EMAIL PROTECTED]
> > >
> > > Did you use -f on the vacuumdb? If not, it did a normal vacuum (which
> > > isn't likely to help) not a full vacuum.
> >
> &g
ime to dump
and restore the whole db (the dump is ~150 MiB gzipped).
--
Tomas Szepe <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 8: explain analyze is your friend
I've now taken a close look at that whole
> file and I think the rest of it is okay, but ... :-(
Tom, you've saved the day again! (Thanks thanks thanks.)
(BTW, it seems the bug can't be triggered on Linux/sparc32).
--
Tomas Szepe <[EMAIL PROTECTED]>
---
> [EMAIL PROTECTED]
>
> > The resolution of this bug is of critical importance to me, will
> > somebody help?
>
> Postgres version? Platform?
Ouch, sorry. PostgreSQL 7.3.3 on x86 Linux.
--
Tomas Szepe <[EMAIL PROTECTED]>
--
ortance to me, will
somebody help?
Thanks, T.
- Forwarded message from Tomas Szepe <[EMAIL PROTECTED]> -
Date: Thu, 10 Jul 2003 11:54:14 +0200
From: Tomas Szepe <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: segfault at aset.c:539
Hi list,
I'm getting an ugly
> [EMAIL PROTECTED]
>
> > Peter Childs <[EMAIL PROTECTED]> writes:
> > > On Fri, 30 May 2003, Tomas Szepe wrote:
> > >> Trouble is, as the rows in the tables get deleted/inserted/updated
> > >> (the frequency being a couple thousand rows
een upgraded
after its compilation.
--
Tomas Szepe <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
ct with the
exception of query times deterioration that apparently corelates to
the db's on-disk size growth.
Thanks for your suggestions,
--
Tomas Szepe <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
> As Tom said, you probably need higher FSM settings, but also, do you have
> any long lived transactions (say from some kind of persistent connection
> system) that might be preventing vacuum from removing rows?
No, not at all.
--
Tomas Szepe <[EMA
> [EMAIL PROTECTED]
>
> Peter Childs <[EMAIL PROTECTED]> writes:
> > On Fri, 30 May 2003, Tomas Szepe wrote:
> >> Trouble is, as the rows in the tables get deleted/inserted/updated
> >> (the frequency being a couple thousand rows per minute), the database
&g
| r | 865 | 565
contract_ips_pkey | i | 605 | 565
> What does VACUUM FULL VERBOSE stats_min; give you?
Sorry, I can't run a VACUUM FULL at this time.
We're in production use.
--
Tomas Szepe <[EMAIL PROTECTED]&g
accept my apologies if I've overlooked a relevant piece of
information in the docs. I'm in an urgent need of getting this
problem resolved.
--
Tomas Szepe <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
36 matches
Mail list logo
