On 28/08/2007 15:48, Jeff Amiel wrote:
Alien or supernatural intervention: 18-1
Obscure postgresql bug nobody else has ever seen: 25-1
That's the sort of confidence in the DBMS we all like to see! :-)
Ray.
---
Raymond O'Donnell,
At 03:15 PM 8/28/2007, Kamil Srot wrote:
Andrew, Alvaro... well, sure SQL injection is possibility I cannot
ignore... (and sure as "dad" of this
application, I think it's not the case :-) ... just kidding...
As even the injected SQL will be shown in the logs, so we'll know
more after some time.
On Aug 28, 2007, at 9:41 AM, Kamil Srot wrote:
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,
Kamil Srot wrote:
Heh, is the pool still open? Maybe I can make at least something from
it :-D
Current odds
Application bug: even money
Application configuration issue: 2-1
Rogue cron job or other maintenance process: 4-1
Somebody messing with you (or SQL injection): 8-1
XID wrap
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
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.
(in all seriousness, we hope you find/fix the problem before things get
really ugly)
Kamil Srot wrote:
Richard Huxton wrote:
Kamil Srot wrote:
In the version used o
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 matter
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 matter by making sure your app
On Mon, Aug 27, 2007 at 05:58:26PM -0400, 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 vacuu
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
On Tue, Aug 28, 2007 at 02:03:29AM +0200, Kamil Srot wrote:
> The system is actually management of website&eshop with webbased UI ...
Um, are you sure you don't have a SQL-injection problem, and someone
is doing Something Bad to you?
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact that tec
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 that's
not so, then defini
On Aug 27, 2007, at 7:57 PM, Kamil Srot wrote:
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/DDL co
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 crank
On Monday 27 August 2007 5:57 pm, Kamil Srot wrote:
> 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 ac
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/DDL commands... can try it on a binary
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/DDL commands... can try it on a binary backup of the damaged DB
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 to another instanc
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 that CMS system certain
Kamil Srot wrote:
brian wrote:
IMHO, it's not at all improbable, given that this software is
connecting to the same databases you are seeing affected by this
phenomenon. Not to mention that it's proprietary, so fewer eyes
have gone over it.[1] I suggested earlier grepping for 'drop' in
your
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 problem in the wa
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 certainly makes it wo
On 8/27/07, Kamil Srot <[EMAIL PROTECTED]> wrote:
> I really need to make sure, the next problem (if it's necessary to let
> it happen) will be the last one... :-(
Have you set your log_statement to 'ddl' in postgresql.conf?
That way you'll have a log of every single ddl that goes through the
da
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 that CMS system certainly makes it wort
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 to another instance of relation
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 problem in the way you
describe. I don't think
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 certainly makes it worthy of suspic
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
On Aug 27, 2007, at 4:08 PM, 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
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 | 2147483647
23683801
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 | 2147483647
> 236838019
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
On Mon, Aug 27, 2007 at 10:31:11PM +0200, Kamil Srot wrote:
> The script is very simple one:
Well, I don't see anything obvious, but. . .
> 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 "va
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 FULL.
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 FULL.
> Well, I do list all database
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 ment it like I'l
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.
But given what you've posted, I am not even a little bit con
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?
Well, I'd
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?
>>>
>>
>> Well, I'd drop the "full" part
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 to bloat indexes. Also, did
you c
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 to bloat indexes. Also, did
you check it was actually completing (no e
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 table was missing an
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 table was missing and
> transaction counter was
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 one (mostly
read)..
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 one (mostly read)... and
everytime
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 one (mostly read)... and
> everytime the "lost
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
50 matches
Mail list logo
