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 ->
On Mon, Jun 3, 2019 at 10:56 PM Tom Lane wrote:
>
> Amit Langote writes:
> > On 2019/05/30 18:51, Amit Kapila wrote:
> >> I think it will be better to include postgres_fdw in the comment in
> >> some way so that if someone wants a concrete example, there is
> >> something to refer to.
>
> > Maybe
Hello Amit,
07.06.2019 7:30, Amit Kapila wrote:
> Leaving the changes related to the above two points, I have combined
> all the changes and fixed the things as per my review in the attached
> patch. Alexander, see if you can verify once the combined patch. I
> am planning to commit the attached
On Tue, Jun 4, 2019 at 7:36 AM Amit Kapila wrote:
>
> Hi Andres,
>
> I have added you here as some of these are related to commits done by
> you. So need your opinion on the same. I have mentioned where your
> feedback will be helpful.
>
> > 10. HeapTupleSatisfiesSnapshot -> HeapTupleSatisfiesVi
Hi Andres,
I have added you here as some of these are related to commits done by
you. So need your opinion on the same. I have mentioned where your
feedback will be helpful.
On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin wrote:
>
> 6. ExecGetResultSlot - remove (not used since introduction i
On Mon, Jun 3, 2019 at 10:56 PM Tom Lane wrote:
>
> Amit Langote writes:
> > On 2019/05/30 18:51, Amit Kapila wrote:
> >> I think it will be better to include postgres_fdw in the comment in
> >> some way so that if someone wants a concrete example, there is
> >> something to refer to.
>
> > Maybe
Amit Langote writes:
> On 2019/05/30 18:51, Amit Kapila wrote:
>> I think it will be better to include postgres_fdw in the comment in
>> some way so that if someone wants a concrete example, there is
>> something to refer to.
> Maybe a good idea, but this will be the first time to mention postgre
On 2019/05/30 18:51, Amit Kapila wrote:
> On Wed, May 29, 2019 at 6:12 AM Amit Langote wrote:
>> On 2019/05/28 20:26, Amit Kapila wrote:
>>> Can we ensure some way that only FDW's rely on it not any other part
>>> of the code?
>>
>> Hmm, I can't think of any way of doing than other than manual insp
On Wed, May 29, 2019 at 6:12 AM Amit Langote
wrote:
>
> On 2019/05/28 20:26, Amit Kapila wrote:
> > On Tue, May 28, 2019 at 12:29 PM Amit Langote wrote:
> >> Seeing that the crash occurs due to postgres_fdw relying on
> >> es_result_relation_info being set when initializing a "direct
> >> modifica
On Tue, May 28, 2019 at 10:30 AM Alexander Lakhin wrote:
>
> 28.05.2019 2:05, Amit Kapila wrote:
> > On Mon, May 27, 2019 at 3:59 AM Tom Lane wrote:
> >> Amit Kapila writes:
> >>> On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin
> >>> wrote:
> 5. ExecContextForcesOids - not changed, but m
On 2019/05/28 20:26, Amit Kapila wrote:
> On Tue, May 28, 2019 at 12:29 PM Amit Langote wrote:
>> Seeing that the crash occurs due to postgres_fdw relying on
>> es_result_relation_info being set when initializing a "direct
>> modification" plan on foreign tables managed by it, we could change the
>
On Tue, May 28, 2019 at 12:29 PM Amit Langote
wrote:
>
> On 2019/05/28 14:00, Alexander Lakhin wrote:
> > 28.05.2019 2:05, Amit Kapila wrote:
> >> ... If we read the comment atop ExecContextForcesOids
> >> [1] before it was removed, it seems to indicate that the
> >> initialization of es_result_re
On 2019/05/28 14:00, Alexander Lakhin wrote:
> 28.05.2019 2:05, Amit Kapila wrote:
>> ... If we read the comment atop ExecContextForcesOids
>> [1] before it was removed, it seems to indicate that the
>> initialization of es_result_relation_info for each subplan is for its
>> usage in ExecContextFor
28.05.2019 2:05, Amit Kapila wrote:
> On Mon, May 27, 2019 at 3:59 AM Tom Lane wrote:
>> Amit Kapila writes:
>>> On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin
>>> wrote:
5. ExecContextForcesOids - not changed, but may be should be removed
(orphaned after 578b2297)
>>> Yes, we shoul
On Mon, May 27, 2019 at 3:59 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin
> > wrote:
> >> 5. ExecContextForcesOids - not changed, but may be should be removed
> >> (orphaned after 578b2297)
>
> > Yes, we should remove the use of ExecContextForc
Amit Kapila writes:
> On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin wrote:
>> 5. ExecContextForcesOids - not changed, but may be should be removed
>> (orphaned after 578b2297)
> Yes, we should remove the use of ExecContextForcesOids.
Unless grep is failing me, ExecContextForcesOids is in fac
On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin wrote:
>
> Hello hackers,
>
> Please also consider fixing the following inconsistencies found in new
> v12 code:
>
> 1. AT_AddOids - remove (orphaned after 578b2297)
> 2. BeingModified ->TM_BeingModified (for consistency)
>
/*
- * A tuple is locked
Hello hackers,
Please also consider fixing the following inconsistencies found in new
v12 code:
1. AT_AddOids - remove (orphaned after 578b2297)
2. BeingModified ->TM_BeingModified (for consistency)
3. copy_relation_data -> remove (orphaned after d25f5191)
4. endblock -> endblk (an internal incon
22 matches
Mail list logo
