RE: In-placre persistance change of a relation - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: In-placre persistance change of a relation
Date
Msg-id TYAPR01MB2990D25E5CE77A095ADC90A3FEE60@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: In-placre persistance change of a relation  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses RE: In-placre persistance change of a relation  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Re: In-placre persistance change of a relation  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
Hi Horiguchi-san,


Thank you for making a patch so quickly.  I've started looking at it.

What makes you think this is a PoC?  Documentation and test cases?  If there's something you think that doesn't work or
areconcerned about, can you share it? 

Do you know the reason why data copy was done before?  And, it may be odd for me to ask this, but I think I saw someone
referredto the past discussion that eliminating data copy is difficult due to some processing at commit.  I can't find
it.



(1)
@@ -168,6 +168,8 @@ extern PGDLLIMPORT int32 *LocalRefCount;
  */
 #define BufferGetPage(buffer) ((Page)BufferGetBlock(buffer))

+struct SmgrRelationData;

This declaration is already in the file:

/* forward declared, to avoid having to expose buf_internals.h here */
struct WritebackContext;

/* forward declared, to avoid including smgr.h here */
struct SMgrRelationData;


Regards
Takayuki Tsunakawa




pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Strange behavior with polygon and NaN
Next
From: Amit Kapila
Date:
Subject: Re: POC: Cleaning up orphaned files using undo logs