Re: Update on Supporting Encryption in Postgresql

From: Murat Kantarcioglu <kanmurat(at)cs(dot)purdue(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Update on Supporting Encryption in Postgresql
Date: 2004-09-10 19:08:16
Message-ID: chsu2v$2jbl$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Our basic claim is to be able to do most of the encryption while we are
reading the page. That is the reason I need the threads. Any suggestion
about the threads are welcome. Thanks.
Murat

Alvaro Herrera wrote:
> On Fri, Sep 10, 2004 at 11:52:26AM -0500, Murat Kantarcioglu wrote:
>
>
>>Can you suggest me a solution to how to do
>>this on Postgresql backend?
>>
>>I am asssuming that somewhere in the code, you are calling a function like
>> getPage(Page_id)
>>to retrieve the page(I am trying to change backend)
>
>
> Probably the code you want to modify is in src/backend/storage/smgr.
> Maybe you want to add a different storage manager (they are pluggable,
> sort of).
>
>
>> getPage(Page_id)
>> {
>> ctr=Hash_Table(Page_id) //return somevalue needed for deccryption
>> Thread_Read(Page_id) // will call the original read code
>> Thread_Encryption.start(ctr, length);
>> when both threads are done finish the encryption
>> }
>
>
> I think it would need extensive, painful and unwelcome modifications to
> use threads to do the job. You could just as well do it sequentially,
> like in
>
> encryptedPage = getPage(page_id);
> clearPage = unencrypt(encryptedPage);
> return clearPage;
>
>
> And the reverse for storage. This may only need modifications to
> mdread() and mdwrite() ... unless your encryption scheme returns a
> different length than the original.
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-09-10 19:11:37 Re: Update on Supporting Encryption in Postgresql
Previous Message Tom Lane 2004-09-10 18:55:47 Re: Making AFTER triggers act properly in PL functions