Обсуждение: Trigger AFTER UPDATE OR INSERT
Hello frnds, I have a trigger on a table with After UPDATE OR INSERT ..that insert a record in an another table..........If the Trigger Fire Correctly the row is inserted or updated in the database as the case is. But if it is not fire correctly then the table is also not updated on which the trigger is.............. Is it the right .................? if yes......How to insert the record in the table if the trigger is failed. Regards, Yogesh Arora.
On 10/19/07, yogesh <yogesh.arora.daffodil@gmail.com> wrote: > Hello frnds, > I have a trigger on a table with After UPDATE OR INSERT ..that insert > a record in an another table..........If the Trigger Fire Correctly > the row is inserted or updated in the database as the case is. But if > it is not fire correctly then the table is also not updated on which > the trigger is.............. > > Is it the right .................? if yes......How to insert the > record in the table if the trigger is failed. Yes, it's right. Triggers are part of a transaction (or run their own) so if the trigger fails, so does the transaction. If you really need to have something insert rather or not the transaction succeeds, you can either use savepoints so that you can roll back to before the error then insert the row anyway, or use dblink to connect to the db through another backend and commit your data that way. You might want to give more info on exactly what you're trying to do so the folks on the list can make better informed recommendations.
On Oct 19, 11:05 pm, scott.marl...@gmail.com ("Scott Marlowe") wrote:
> On 10/19/07, yogesh <yogesh.arora.daffo...@gmail.com> wrote:
>
> > Hello frnds,
> > I have a trigger on a table with After UPDATE OR INSERT ..that insert
> > a record in an another table..........If the Trigger Fire Correctly
> > the row is inserted or updated in the database as the case is. But if
> > it is not fire correctly then the table is also not updated on which
> > the trigger is..............
>
> > Is it the right .................? if yes......How to insert the
> > record in the table if the trigger is failed.
>
> Yes, it's right. Triggers are part of a transaction (or run their
> own) so if the trigger fails, so does the transaction.
>
> If you really need to have something insert rather or not the
> transaction succeeds, you can either use savepoints so that you can
> roll back to before the error then insert the row anyway, or use
> dblink to connect to the db through another backend and commit your
> data that way.
>
> You might want to give more info on exactly what you're trying to do
> so the folks on the list can make better informed recommendations.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
Hello Scott,
Thanks to you....
you got the right point point what i want to know.......
are you saying about programming or any other way to done
it........to insert a row even if the Trigger fails or succeeds
Regards,
Yogesh Arora
On 10/20/07, yogesh <yogesh.arora.daffodil@gmail.com> wrote:
> On Oct 19, 11:05 pm, scott.marl...@gmail.com ("Scott Marlowe") wrote:
> > Yes, it's right. Triggers are part of a transaction (or run their
> > own) so if the trigger fails, so does the transaction.
> >
> > If you really need to have something insert rather or not the
> > transaction succeeds, you can either use savepoints so that you can
> > roll back to before the error then insert the row anyway, or use
> > dblink to connect to the db through another backend and commit your
> > data that way.
> >
> > You might want to give more info on exactly what you're trying to do
> > so the folks on the list can make better informed recommendations.
> Hello Scott,
> Thanks to you....
> you got the right point point what i want to know.......
>
> are you saying about programming or any other way to done
> it........to insert a row even if the Trigger fails or succeeds
Read up on savepoints here:
http://www.postgresql.org/docs/8.2/static/sql-savepoint.html
I have a backup done with "pg_dump" utility. For some reason the backup file has 8 phisical bad sectors (17 KB of data) Now when I try to restore the backup all tables are created successfully and data of almost all tables restores successfully too, but one table (the most important) appear empty. When I do a pg_restore <backup_file> its show all sql instructions and data until arrive to the "damaged sector" and throws a "out of memory" exception. I want to know if is possible to fix the backup file removing the blocks in the "bad sectors" in order to restore all other information. something like file dump surgery :) Thanks! Anibal
The dumped file is just a plain-text file (Depending on the data types within your database) You should be able to open the backup you made with pg_dump in your favourite editor such as vi and search through for the dodgy data. Clear out the bad stuff, write it back to disk and you should be good to go. Obviously this won't "save" the damaged portion of the data, and it may have unpredictable effects when you take in to account any foreign keys etc you may have in the database that depends on this data. Cheers, ~p > -----Original Message----- > From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin- > owner@postgresql.org] On Behalf Of Anibal David Acosta > Sent: Monday, 22 October 2007 11:16 > To: pgsql-admin@postgresql.org > Subject: [ADMIN] Please help (backup) > > I have a backup done with "pg_dump" utility. > > For some reason the backup file has 8 phisical bad sectors (17 KB of data) > > Now when I try to restore the backup all tables are created successfully > and data of almost all tables restores successfully too, but one table > (the most important) appear empty. > > When I do a pg_restore <backup_file> its show all sql instructions and > data until arrive to the "damaged sector" and throws a "out of memory" > exception. > > I want to know if is possible to fix the backup file removing the blocks > in the "bad sectors" in order to restore all other information. > > something like file dump surgery :) > > Thanks! > > Anibal > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org THINK BEFORE YOU PRINT - Save paper if you don't really need to print this *******************Confidentiality and Privilege Notice******************* The material contained in this message is privileged and confidential to the addressee. If you are not the addressee indicated in this message or responsible for delivery of the message to such person, you may not copy or deliver this message to anyone, and you should destroy it and kindly notify the sender by reply email. Information in this message that does not relate to the official business of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta. Weatherbeeta, its employees, contractors or associates shall not be liable for direct, indirect or consequential loss arising from transmission of this message or any attachments e-mail.