Jeff Amiel wrote:
My entire shop has set up a betting pool on the outcome of this...so I
hope you post results regardless of the outcome, Kamil.
Heh, is the pool still open? Maybe I can make at least something from it :-D
(in all seriousness, we hope you find/fix the problem before things
get
Kynn Jones wrote:
I'm hoping to get some advice on a design question I'm grappling with.
I have a database now that in many respects may be regarded as an
collection of a few hundred much smaller "parallel databases", all
having the same schema. What I mean by this is that, as far as the
inten
Richard Huxton wrote:
Kamil Srot wrote:
In the version used on this particular server, there is no
automatic/programing way of changing
the schema. Upgrades are done manually and application itself doesn't
need schema changes
for routine operations...
In that case, you can settle the m
Alvaro Herrera wrote:
Adrian Klaver wrote:
I have a question. First a little history. Right now, the people who know
better than I are fairly certain Postgres is not changing things on its own
and the developer is certain the CMS software is not doing schema changes. As
I understand it log
Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
Also, I'd write a simple "ping" script to check for the table that
runs every 5 seconds or so.
I had gathered that the table was being touched constantly by his app,
so that it'd be immediately obvious when it had gone away. If th
Adrian Klaver wrote:
I have a question. First a little history. Right now, the people who know
better than I are fairly certain Postgres is not changing things on its own
and the developer is certain the CMS software is not doing schema changes. As
I understand it logging has been cranked up to
Tom Lane wrote:
Kamil Srot <[EMAIL PROTECTED]> writes:
Erik Jones wrote:
Have you verified that the table's files are still on disk after
it's "disappeared"?
Do not have any idea how to do it... I wasn't able to access it using
any DML/
Tom Lane wrote:
Kamil Srot <[EMAIL PROTECTED]> writes:
From above mentioned duplications of relatio names and what Tom wrote
recently (doesn't see like WA problem), it looks like the relation name
is/gets corrupted in some way and this corruption is internally taken
over
brian wrote:
Just wondering: what's the name of this table? What's its function? I
think you mentioned that it's pretty well static. But what is it
holding? Maybe that'll provide a clue as to where to look.
The system is actually management of website&eshop with webbased UI ...
the table is
Erik Jones wrote:
On Aug 27, 2007, at 4:44 PM, Kamil Srot wrote:
Also, in your original post you mentioned a "proprietal CMS
system". Is this proprietary to your company or one that you've
purchased? The fact that the same table going on multiple dbs all
being run by
Andrew Sullivan wrote:
On Mon, Aug 27, 2007 at 11:44:38PM +0200, Kamil Srot wrote:
When this problem appeared for the first time, I had clearly the
wraparound problem... I did vacuum it and partially restored the data...
I don't think vacuum would "fix" a wrap around
brian wrote:
Kamil Srot wrote:
> Erik Jones wrote
Also, in your original post you mentioned a "proprietal CMS
system". Is this proprietary to your company or one that you've
purchased? The fact that the same table going on multiple dbs all
being run by that CMS system
Also, in your original post you mentioned a "proprietal CMS system".
Is this proprietary to your company or one that you've purchased? The
fact that the same table going on multiple dbs all being run by that
CMS system certainly makes it worthy of suspicion.
This is software developed in
Tom Lane wrote:
Kamil Srot <[EMAIL PROTECTED]> writes:
# select xmin, age(xmin) from pg_class;
xmin|age
---+
2 | 2147483647
2 | 2147483647
2 | 2147483647
2 | 2147483647
2 | 2147483647
2 | 2147
Andrew Sullivan wrote:
I can easily rewrite it to use the vacuumdb command, but I doubt it'll
make any difference.
The point is that you don't have to rewrite it. Just run "vacuumdb
-a" and it vacuums _all_ databases.
Oh, I have it now! It takes some time, but at the end, I'll unders
Andrew Sullivan wrote:
On Mon, Aug 27, 2007 at 10:03:04PM +0200, Kamil Srot wrote:
Sure, I ment it like I'll do the FULL vacuum less often than daily and
do daily the plain vacuum command.
If you have your servers set up correctly, you should never need to
perform VACUUM
Andrew Sullivan wrote:
On Mon, Aug 27, 2007 at 07:15:44PM +0200, Kamil Srot wrote:
OK, I'll drop the full part and do it less often...
This doesn't address your problem, but when you move from VACUUM FULL
to VACUUM, you want to do it _more_ often, not less.
Sure, I me
Alvaro Herrera wrote:
Kamil Srot wrote:
Martijn van Oosterhout wrote:
On Mon, Aug 27, 2007 at 06:57:54PM +0200, Kamil Srot wrote:
Correct...the script does echo "vacuum full;" | $PGDIR/bin/psql -U
postgres $db for each database...
Hope it's correct?
Martijn van Oosterhout wrote:
On Mon, Aug 27, 2007 at 06:57:54PM +0200, Kamil Srot wrote:
Correct...the script does echo "vacuum full;" | $PGDIR/bin/psql -U
postgres $db for each database...
Hope it's correct?
Well, I'd drop the "full" part, it tends t
Martijn van Oosterhout wrote:
On Mon, Aug 27, 2007 at 06:37:17PM +0200, Kamil Srot wrote:
I don't say, it's gone by itself, I'm asking for help debuging this
situation and hopefully find a solution. For the first time it happened,
it had the same symptoms - this specific ta
brian wrote:
Tom Lane wrote:
Kamil Srot <[EMAIL PROTECTED]> writes:
One more thing:
The project runs proprietal CMS system and there are more instances
of it with the same database layout in different databases. Every
time the "lost" table is the same one - the bussiest o
Hi guys!
I use pgsql for some time already and am happy with it. Heh, sure this
post has it's big BUT :-)
Starting few months ago, one of our projects encoutered loss of one DB
table (in that time, it was version 8.0 or so...) I did some research
and found out, the vacuuming was set wrong an
22 matches
Mail list logo
