Hello,
13.06.2019 11:10, Michael Paquier wrote:
> The last trace of tss_htup has been removed as of 2e3da03, and I see
> no mention of it in the related thread. Andres, is that intentional
> for table AMs to keep a trace of a currently-fetched tuple for a TID
> scan or something that can be remove
On Thu, Jun 13, 2019 at 11:28:42AM +0300, Alexander Lakhin wrote:
> Yes, you're right. I've completed the patch for a possible elimination
> of the field.
For now I have discarded this one, and committed the rest as the
inconsistencies stand out. Good catches by the way.
Your patch was actually
Hello Michael,
13.06.2019 11:10, Michael Paquier wrote:
> On Wed, Jun 12, 2019 at 05:34:06PM +0300, Alexander Lakhin wrote:
>> I can't see another inconsistencies for v12 for now, but there are some
>> that appeared before.
>> If this work can be performed more effectively or should be
>> postponed
On Wed, Jun 12, 2019 at 05:34:06PM +0300, Alexander Lakhin wrote:
> I can't see another inconsistencies for v12 for now, but there are some
> that appeared before.
> If this work can be performed more effectively or should be
> postponed/canceled, please let me know.
Note sure that it is much prod
Hello Amit,
Can you also review the following fixes?:
2.1. bt_binsrch_insert -> _bt_binsrch_insert (an internal inconsistency)
2.2. EWOULDBOCK -> EWOULDBLOCK (a typo)
2.3. FORGET_RELATION_FSYNC & FORGET_DATABASE_FSYNC ->
SYNC_FORGET_REQUEST (orphaned after 3eb77eba)
2.4. GetNewObjectIdWithIndex ->
