Re: good exception handling archiecutre

Поиск
Список
Период
Сортировка
От
Тема Re: good exception handling archiecutre
Дата
Msg-id 418EC9BD4D7125488CCAC5C7C559A2480CCB59@MS10.lsc.net
обсуждение исходный текст
Ответ на Re: good exception handling archiecutre  (Alban Hertroys <dalroi@solfertje.student.utwente.nl>)
Список pgsql-general
Thanks Alban,

I was able to do this using DBLINK. Thanks a lot for your help.

Regards,
Atul Goel

-----Original Message-----
From: Alban Hertroys [mailto:dalroi@solfertje.student.utwente.nl]
Sent: 16 August 2010 18:07
To: Atul Goel
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] good exception handling archiecutre

On 16 Aug 2010, at 10:45, <Atul.Goel@globaldatapoint.com> <Atul.Goel@globaldatapoint.com> wrote:

> Hi Alban,
>
> Thanks for the reply.
>
> I checked that Notify will not work till the transaction is commited. So in our case since the transaction is being
rolledback there will be no notify. 

Ah, you're right! I totally forgot about that...

> Is there any other way of inter process communication in Postgres.

Of course there is :)

There's nothing stopping you from writing a few custom functions in an untrusted language that does your IPC for you. C
comesto mind, but PL/Perlu, PL/PythonU, etc. should be able to do it as well (and probably easier). 

Usually if you're talking about performing I/O external to the database you'll get warned that transactions involving
thosecalls can't be rolled back, but in this case that's exactly what you want. 

Now I know that Postgres uses some IPC internally as well (at least shared memory), so maybe it's possible to use some
ofthe internal mechanisms. I have no idea whether that's possible or at all advisable, I'm sure someone (probably Tom)
willchime in regarding that. 

Cheers!

> -----Original Message-----
> From: Alban Hertroys [mailto:dalroi@solfertje.student.utwente.nl]
> Sent: 13 August 2010 17:50
> To: Atul Goel
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] good exception handling archiecutre
>
> On 13 Aug 2010, at 14:07, <Atul.Goel@globaldatapoint.com> <Atul.Goel@globaldatapoint.com> wrote:
>
>> How can we do error logging in Postgres. I am trying to create a LOG_AND_STOP method which would be generic to the
code.I have pasted the code I have written. This code returns no data which is understandable as the error is thrown to
theexternal world. 
>>
>> Can I write the code somehow.
>>
>> CREATE SCHEMA test
>>  AUTHORIZATION postgres;
>>
>> CREATE TABLE test.error_log
>> (
>>  error_desc text
>> );
>>
>>
>> CREATE OR REPLACE FUNCTION test.log_and_stop(err_desc text)
>>  RETURNS void AS
>> $BODY$
>> Declare
>> x integer;
>> begin
>> begin
>> insert into test.error_log values (err_desc);
>> end;
>> begin
>> raise exception '%',err_desc;
>
> Your transaction got rolled back here, hence the lack of data in your error_log table.
>
> I don't think there's any way to log errors into a table from within the same transaction, you'll probably need to
usea separate connection for the logging. I think LISTEN/NOTIFY may come in handy there. 
>
>> end;
>> end;
>> $BODY$
>>  LANGUAGE 'plpgsql' VOLATILE
>>  COST 100;
>> ALTER FUNCTION test.log_and_stop(text) OWNER TO postgres;
>
> Alban Hertroys
>
> --
> If you can't see the forest for the trees,
> cut the trees and you'll see there is no forest.
>
>
>
>
>
> This e-mail is confidential and should not be used by anyone who is not the original intended recipient. Global
DataPointLimited does not accept liability for any statements made which are clearly the sender's own and not expressly
madeon behalf of Global DataPoint Limited. No contracts may be concluded on behalf of Global DataPoint Limited by means
ofe-mail communication. Global DataPoint Limited Registered in England and Wales with registered number 3739752
RegisteredOffice Middlesex House, 34-42 Cleveland Street, London W1T 4LB 
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.


!DSPAM:1157,4c697045967631814717658!


This e-mail is confidential and should not be used by anyone who is not the original intended recipient. Global
DataPointLimited does not accept liability for any statements made which are clearly the sender's own and not expressly
madeon behalf of Global DataPoint Limited. No contracts may be concluded on behalf of Global DataPoint Limited by means
ofe-mail communication. Global DataPoint Limited Registered in England and Wales with registered number 3739752
RegisteredOffice Middlesex House, 34-42 Cleveland Street, London W1T 4LB 

В списке pgsql-general по дате отправления:

Предыдущее
От: Philippe Lang
Дата:
Сообщение: Re: Non-reentrant plperlu function & concurrent access
Следующее
От:
Дата:
Сообщение: Re: good exception handling archiecutre