Strange deletion problem

Re: Strange deletion problem

This is a multi-part message in MIME format.
--------------020201030100030601040108
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

hello, John

2010.03.30 10:57, John Lister rašė:
> - Is there any other statements that could be causing the rows to be=20
> removed that I've missed
Please see |TRUNCATE.|
> - Is there anything that could be deleting them without generating a=20
> log entry for the statement?
Don't think so...
> - Is it possible that data corruption of either the index/table is=20
> making my delete statements removed more rows?
Maybe you have foreign key with "On delete cascade" ?
> - Is it a possibly bug?
I don't know of such bug, but I'm no bug expert as well. I guess=20
everything is possible.


--=20
Julius Tuskenis
Programavimo skyriaus vadovas
UAB nSoft
mob. +37068233050


--------------020201030100030601040108
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




">


hello, John



2010.03.30 10:57, John Lister rašė:

type=3D"cite">

- Is there any other statements th=
at
could be causing the rows to be removed that I've missed

type=3D"cite">

- Is there anything that could be
deleting them without generating a log entry for the statement? iv>

type=3D"cite">

- Is it possible that data
corruption of either the index/table is making my delete statements
removed more rows?

type=3D"cite">

- Is it a possibly bug? v>

--=20

Julius Tuskenis

Programavimo skyriaus vadovas

UAB nSoft

mob. +37068233050

Re: Strange deletion problem

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01CAD05B.932BC100
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


2010/3/30 John Lister

Hi, I have a table which is constantly updated through out the day =
with no problems, I'm running Postgresql 8.3.8 in ubuntu karmic. =
However, within the last week for some reason overnight it is being =
emptied and I can't work out why. I've set log_min_duration_statement to =
0 so that postgresql dumps out every query made to the db but it hasn't =
brought anything up. During the period between from when I know the =
table is ok to the next morning when it is empty I can see entries in =
the logs for the expected 200 or so deletions, but during this period =
approx 15k rows are removed. The odd thing is that there is nothing else =
in the logs that references the table (I've looked for the obvious =
deletion and trunctate statements).

The table is modified using JDBC prepared statements so I see 3 =
entries for each of the expected delete statements (parse, bind, =
execute) and the statement is as follows:

delete from product_list where retailer_id=3D? and product_id=3D?


Therefore I have a few questions:
- Is there any other statements that could be causing the rows to be =
removed that I've missed
- Is there anything that could be deleting them without generating a =
log entry for the statement?
- Is it possible that data corruption of either the index/table is =
making my delete statements removed more rows?
- Is it a possibly bug?



Hi,
- maybe there are some other settings for this database (they are not =
stored in the file), check the pg_settings table in the database
- maybe you're looking in a wrong log file - sometimes do (they change =
from time to time - depending on the configuration)
- ensure that the logging is done to file and to THIS file, because =
there are more logging settings than just log_min_duration and sometimes =
it can be messed up
- try to restart the database and see if there isn't any other file =
created as usually I observe that after deleting current log file, the =
database doesn't recreate while logging so the logs are not stored.

Cheers for replying, I've checked the config and nothing seems to be =
amiss, as I'm running ubuntu the defaults seem to be to dump to stderr =
and somehow this is redirect to the log file, there doesn't seem to be =
any other log files used - although it is possible the ubuntu startup =
scripts inject the logfile on startup?
Unfortunately I can't restart the database easily, whatever changed =
seemed to have happened on friday without a restart so I'm hoping I can =
find and undo it...

John

------=_NextPart_000_0022_01CAD05B.932BC100
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

ï»=BF

style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

2010/3/30 John Lister < =
href=3D"mailto:john.lister-ps@kickstone.com">john.lister-ps@ kickstone.com=
>

style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: =
#ccc 1px solid">

Hi, I have a table which is =
constantly updated=20
through out the day with no problems, =
I'm running Postgresql 8.3.8=20
in ubuntu karmic. However, within the last week for some reason =
overnight it=20
is being emptied and I can't work out why. I've set=20
log_min_duration_statement to 0 so that postgresql dumps out every =
query=20
made to the db but it hasn't brought anything up. During the period =
between=20
from when I know the table is ok to the next morning when it is =

empty I can see entries in the logs for the expected 200 or so=20
deletions, but during this period approx 15k rows are removed. The =
odd thing=20
is that there is nothing else in the logs that references the table =
(I've=20
looked for the obvious deletion and trunctate =
statements).

 

The table is modified using JDBC =
prepared=20
statements so I see 3 entries for each of the expected delete =
statements=20
(parse, bind, execute) and the statement is as =
follows:

 

delete from product_list where =
retailer_id=3D?=20
and product_id=3D?

 

 

Therefore I have a few =
questions:

- Is there any other statements =
that could be=20
causing the rows to be removed that I've missed

- Is there anything that could be =
deleting them=20
without generating a log entry for the statement?

- Is it possible that data =
corruption of either=20
the index/table is making my delete statements removed more=20
rows?

- Is it a possibly =
bug?

size=3D2> 

Hi,

- maybe there are some other settings for this database (they are =
not=20
stored in the file), check the pg_settings table in the database

- maybe you're looking in a wrong log file - sometimes do (they =
change=20
from time to time - depending on the configuration)

- ensure that the logging is done to file and to THIS file, =
because there=20
are more logging settings than just log_min_duration and sometimes it =
can be=20
messed up

- try to restart the database and see if there isn't any other =
file=20
created as usually I observe that after deleting current log file, the =

database doesn't recreate while logging so the logs are not=20
stored.

Re: Strange deletion problem

You could create a statement level delete trigger on the relevant table,
then get it to snapshot all the contents of the pg_stat_activity table
(which will show all running queries) into some sort of log table.

If you look at the plpgsql documentation (part of the postgresql manual
for your release) there is a section on triggers and an example on
maintaining a summary table; this is sort of the pattern you want to adop=
t,
except that what you insert into the "summary" table will be something
like:

"insert into my_table_delete_log (select * from pg_stat_activity where
current_query not like '%%');"

If you want to run something similar at the row level instead, beware tha=
t
you may then see it trigger 15K times and thus you could end up with 15K
copies of the active queries ...

You might also want to add a sequence column to your log table so you can
be sure which order the queries were inserted, although if you're using
statement level logging, you'll should see distinct query and backend sta=
rt
timestamps anyway.

Just an idea - never tried it myself - so probably best to test it out on
a test database of some sort first!

Cheers,
Robin


On Tue, 30 Mar 2010 22:51:46 +0100, "John Lister"
wrote:
> 2010/3/30 John Lister
>=20
> Hi, I have a table which is constantly updated through out the day
> with no problems, I'm running Postgresql 8.3.8 in ubuntu karmic.
> However, within the last week for some reason overnight it is being
> emptied and I can't work out why. I've set
log_min_duration_statement
> to 0 so that postgresql dumps out every query made to the db but it
> hasn't brought anything up. During the period between from when I
know
> the table is ok to the next morning when it is empty I can see
entries
> in the logs for the expected 200 or so deletions, but during this
> period approx 15k rows are removed. The odd thing is that there is
> nothing else in the logs that references the table (I've looked for
the
> obvious deletion and trunctate statements).
>=20
> The table is modified using JDBC prepared statements so I see 3
> entries for each of the expected delete statements (parse, bind,
> execute) and the statement is as follows:
>=20
> delete from product_list where retailer_id=3D? and product_id=3D?
>=20
>=20
> Therefore I have a few questions:
> - Is there any other statements that could be causing the rows to b=
e
> removed that I've missed
> - Is there anything that could be deleting them without generating =
a
> log entry for the statement?
> - Is it possible that data corruption of either the index/table is
> making my delete statements removed more rows?
> - Is it a possibly bug?
>=20
>=20
>=20
> Hi,
> - maybe there are some other settings for this database (they are not
> stored in the file), check the pg_settings table in the database
> - maybe you're looking in a wrong log file - sometimes do (they chang=
e
> from time to time - depending on the configuration)
> - ensure that the logging is done to file and to THIS file, because
> there are more logging settings than just log_min_duration and
sometimes
> it can be messed up
> - try to restart the database and see if there isn't any other file
> created as usually I observe that after deleting current log file, th=
e
> database doesn't recreate while logging so the logs are not stored.
>=20
> Cheers for replying, I've checked the config and nothing seems to be
> amiss, as I'm running ubuntu the defaults seem to be to dump to stderr
and
> somehow this is redirect to the log file, there doesn't seem to be any
> other log files used - although it is possible the ubuntu startup
scripts
> inject the logfile on startup?
> Unfortunately I can't restart the database easily, whatever changed
seemed
> to have happened on friday without a restart so I'm hoping I can find
and
> undo it...
>=20
> John

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Strange deletion problem

Thanks to all that helped, I've eventually solved it, I set up a cron job to
monitor the table every minute to help me narrow down the time frame when
the event happened - the thought of scanning 20+Gb log files for the 6hr
period it happened again didn't fill me with joy. I also added
log_statement=all and changed log_prefix to give me a clue, additionally I
added a trigger to log all changes to an audit_table in case I still missed
it. I was using row level triggers as I didn't realise that postgresql had
statement level ones, so you learn something new every day.

It turns out one of the developers had for some insane reason put "delete
from product_list" into an overnight batch job. Bizarrely this wasn't
appearing in the logs when I used log_min_duration_statement=0, but
log_statement=all, which is something else I've learnt.

Right off to shoot the developer in the leg as we speak..

John
----- Original Message -----
From: "robin"
To: "John Lister"
Cc:
Sent: Wednesday, March 31, 2010 8:00 AM
Subject: Re: [ADMIN] Strange deletion problem


> You could create a statement level delete trigger on the relevant table,
> then get it to snapshot all the contents of the pg_stat_activity table
> (which will show all running queries) into some sort of log table.
>
> If you look at the plpgsql documentation (part of the postgresql manual
> for your release) there is a section on triggers and an example on
> maintaining a summary table; this is sort of the pattern you want to
> adopt,
> except that what you insert into the "summary" table will be something
> like:
>
> "insert into my_table_delete_log (select * from pg_stat_activity where
> current_query not like '%%');"
>
> If you want to run something similar at the row level instead, beware that
> you may then see it trigger 15K times and thus you could end up with 15K
> copies of the active queries ...
>
> You might also want to add a sequence column to your log table so you can
> be sure which order the queries were inserted, although if you're using
> statement level logging, you'll should see distinct query and backend
> start
> timestamps anyway.
>
> Just an idea - never tried it myself - so probably best to test it out on
> a test database of some sort first!
>
> Cheers,
> Robin
>
>
> On Tue, 30 Mar 2010 22:51:46 +0100, "John Lister"
> wrote:
>> 2010/3/30 John Lister
>>
>> Hi, I have a table which is constantly updated through out the day
>> with no problems, I'm running Postgresql 8.3.8 in ubuntu karmic.
>> However, within the last week for some reason overnight it is being
>> emptied and I can't work out why. I've set
> log_min_duration_statement
>> to 0 so that postgresql dumps out every query made to the db but it
>> hasn't brought anything up. During the period between from when I
> know
>> the table is ok to the next morning when it is empty I can see
> entries
>> in the logs for the expected 200 or so deletions, but during this
>> period approx 15k rows are removed. The odd thing is that there is
>> nothing else in the logs that references the table (I've looked for
> the
>> obvious deletion and trunctate statements).
>>
>> The table is modified using JDBC prepared statements so I see 3
>> entries for each of the expected delete statements (parse, bind,
>> execute) and the statement is as follows:
>>
>> delete from product_list where retailer_id=? and product_id=?
>>
>>
>> Therefore I have a few questions:
>> - Is there any other statements that could be causing the rows to be
>> removed that I've missed
>> - Is there anything that could be deleting them without generating a
>> log entry for the statement?
>> - Is it possible that data corruption of either the index/table is
>> making my delete statements removed more rows?
>> - Is it a possibly bug?
>>
>>
>>
>> Hi,
>> - maybe there are some other settings for this database (they are not
>> stored in the file), check the pg_settings table in the database
>> - maybe you're looking in a wrong log file - sometimes do (they change
>> from time to time - depending on the configuration)
>> - ensure that the logging is done to file and to THIS file, because
>> there are more logging settings than just log_min_duration and
> sometimes
>> it can be messed up
>> - try to restart the database and see if there isn't any other file
>> created as usually I observe that after deleting current log file, the
>> database doesn't recreate while logging so the logs are not stored.
>>
>> Cheers for replying, I've checked the config and nothing seems to be
>> amiss, as I'm running ubuntu the defaults seem to be to dump to stderr
> and
>> somehow this is redirect to the log file, there doesn't seem to be any
>> other log files used - although it is possible the ubuntu startup
> scripts
>> inject the logfile on startup?
>> Unfortunately I can't restart the database easily, whatever changed
> seemed
>> to have happened on friday without a restart so I'm hoping I can find
> and
>> undo it...
>>
>> John
>


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin