On Thu, 19 Sep 2019 at 10:04, Michael Paquier wrote:
> On Wed, Sep 18, 2019 at 10:37:27AM +0900, Michael Paquier wrote:
> > I am attaching an updated patch for now that I would like to commit.
> > Are there more comments about the shape of the patch, the name of the
> > columns for the function,
On Thu, Sep 19, 2019 at 08:22:04AM +0530, Amit Kapila wrote:
> Thanks. I was about to have a look today, but anyway I checked the
> committed patch and it looks fine.
Thanks Amit for double-checking.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 19, 2019 at 7:34 AM Michael Paquier wrote:
>
> On Wed, Sep 18, 2019 at 10:37:27AM +0900, Michael Paquier wrote:
> > I am attaching an updated patch for now that I would like to commit.
> > Are there more comments about the shape of the patch, the name of the
> > columns for the
On Wed, Sep 18, 2019 at 10:37:27AM +0900, Michael Paquier wrote:
> I am attaching an updated patch for now that I would like to commit.
> Are there more comments about the shape of the patch, the name of the
> columns for the function, etc.?
Okay, I have done an extra round of review, and
On Tue, Sep 17, 2019 at 01:06:18PM +0900, Michael Paquier wrote:
> On Tue, Sep 17, 2019 at 09:23:45AM +0530, Amit Kapila wrote:
>> If you want to use the same size array, then you might want to just
>> memset the previous array rather than first freeing it and then again
>> allocating it. This is
On Tue, Sep 17, 2019 at 09:23:45AM +0530, Amit Kapila wrote:
> We always return a single tuple/record from this function, so do we
> really need to return SETOF record or just returning record is
> sufficient?
Right (with the doc update).
> If you want to use the same size array, then you might
On Tue, Sep 17, 2019 at 6:14 AM Michael Paquier wrote:
>
> On Mon, Sep 16, 2019 at 11:11:06AM -0300, Alvaro Herrera wrote:
> > On 2019-Sep-16, Michael Paquier wrote:
>
> Thanks, fixed.
>
> Amit, what do you think? Does the patch match with what you have in
> mind?
>
*
CREATE FUNCTION
On Mon, Sep 16, 2019 at 11:11:06AM -0300, Alvaro Herrera wrote:
> On 2019-Sep-16, Michael Paquier wrote:
>> On Mon, Sep 16, 2019 at 11:46:16AM +0530, Amit Kapila wrote:
>> Okay, using two separate columns leads to the attached. Any thoughts?
>> This also includes a fix for cases with
On 2019-Sep-16, Michael Paquier wrote:
> On Mon, Sep 16, 2019 at 11:46:16AM +0530, Amit Kapila wrote:
> > I don't see much use of separating information for infomask and infomask2.
>
> Okay, using two separate columns leads to the attached. Any thoughts?
> This also includes a fix for cases
On Mon, Sep 16, 2019 at 11:46:16AM +0530, Amit Kapila wrote:
> I don't see much use of separating information for infomask and infomask2.
Okay, using two separate columns leads to the attached. Any thoughts?
This also includes a fix for cases with IS_LOCKED_ONLY and UPGRADED.
--
Michael
diff
On Sat, Sep 14, 2019 at 03:03:57PM +0900, Michael Paquier wrote:
> On Sat, Sep 14, 2019 at 11:18:37AM +0530, Amit Kapila wrote:
>> Won't 'Lateral' clause be helpful here as the patch contains it in one
>> of its tests?
>
> Ah true, I forgot that.
If we are redesigning the interface, here are two
On Sat, Sep 14, 2019 at 11:18:37AM +0530, Amit Kapila wrote:
> Won't 'Lateral' clause be helpful here as the patch contains it in one
> of its tests?
Ah true, I forgot that.
--
Michael
signature.asc
Description: PGP signature
On Sat, Sep 14, 2019 at 10:10 AM Michael Paquier wrote:
>
> On Sat, Sep 14, 2019 at 09:25:31AM +0530, Amit Kapila wrote:
> > On Fri, Sep 13, 2019 at 5:31 PM Alvaro Herrera
> > wrote:
> >> A thought I had as I fell asleep last night is to include the derivate
> >> flags in a separate output
On Sat, Sep 14, 2019 at 09:25:31AM +0530, Amit Kapila wrote:
> On Fri, Sep 13, 2019 at 5:31 PM Alvaro Herrera
> wrote:
>> A thought I had as I fell asleep last night is to include the derivate
>> flags in a separate output column altogether. So
>> heap_tuple_infomask_flags() could be made to
On Sat, Sep 14, 2019 at 09:51:33AM +0530, Amit Kapila wrote:
> Yeah, but I think we should also try to see what we want to do about
> 'decode_combined' flag-related point, maybe we can adapt to what
> Alvaro has purposed?
Thanks, I'll keep note of this patch. I was just going to comment on
the
On Fri, Sep 13, 2019 at 10:42 AM Michael Paquier wrote:
>
> On Fri, Sep 13, 2019 at 09:59:40AM +0530, Amit Kapila wrote:
> > I think that is what we have not done in one of the cases pointed by me.
>
> Thinking more about it, I see your point now. HEAP_LOCKED_UPGRADED is
> not a direct
On Fri, Sep 13, 2019 at 5:31 PM Alvaro Herrera wrote:
>
> On 2019-Sep-13, Michael Paquier wrote:
>
> > Attached is a patch to fix your suggestions. This also removes the
> > use of HEAP_XMAX_IS_LOCKED_ONLY which did not make completely sense
> > either as a "raw" flag. While on it, the order of
On 2019-Sep-13, Michael Paquier wrote:
> Attached is a patch to fix your suggestions. This also removes the
> use of HEAP_XMAX_IS_LOCKED_ONLY which did not make completely sense
> either as a "raw" flag. While on it, the order of the flags can be
> improved to match more the order of
On Fri, Sep 13, 2019 at 09:59:40AM +0530, Amit Kapila wrote:
> I think that is what we have not done in one of the cases pointed by me.
Thinking more about it, I see your point now. HEAP_LOCKED_UPGRADED is
not a direct combination of the other flags and depends on other
conditions, so we cannot
On Fri, Sep 13, 2019 at 9:00 AM Michael Paquier wrote:
>
> On Thu, Sep 12, 2019 at 05:24:17PM +0530, Amit Kapila wrote:
> > On Thu, Sep 12, 2019 at 4:48 PM Michael Paquier wrote:
> > Hmm, I thought when decode_combined flag is set to false means we will
> > display the raw flags set on the tuple
On Thu, Sep 12, 2019 at 05:24:17PM +0530, Amit Kapila wrote:
> On Thu, Sep 12, 2019 at 4:48 PM Michael Paquier wrote:
> Hmm, I thought when decode_combined flag is set to false means we will
> display the raw flags set on the tuple without any further
> interpretation. I think that is what is
On Thu, Sep 12, 2019 at 4:48 PM Michael Paquier wrote:
>
> On Thu, Sep 12, 2019 at 05:34:08PM +0800, Masahiko Sawada wrote:
> > On Thu, Sep 12, 2019 at 1:56 PM Amit Kapila wrote:
> >> I think it is better to use a message like "must be superuser to use
> >> pageinspect functions" as this
On Thu, Sep 12, 2019 at 05:34:08PM +0800, Masahiko Sawada wrote:
> On Thu, Sep 12, 2019 at 1:56 PM Amit Kapila wrote:
>> I think it is better to use a message like "must be superuser to use
>> pageinspect functions" as this function doesn't take raw page as
>> input. If you see other functions
On Thu, Sep 12, 2019 at 1:56 PM Amit Kapila wrote:
>
> On Wed, Sep 11, 2019 at 8:53 PM Masahiko Sawada wrote:
> >
> > I've attached the updated patch that incorporated all comments. I kept
> > the function as superuser-restricted.
> >
>
> Thanks for the updated patch.
>
> Few more comments:
On Thu, Sep 12, 2019 at 11:43 AM Michael Paquier wrote:
>
> On Wed, Sep 11, 2019 at 11:22:45PM +0800, Masahiko Sawada wrote:
> > Hmm it will be more consistent with other functions but I think we
> > would need to increase the pageinspect version to 1.8 and need the new
> > sql file to rename the
On Wed, Sep 11, 2019 at 11:22:45PM +0800, Masahiko Sawada wrote:
> Hmm it will be more consistent with other functions but I think we
> would need to increase the pageinspect version to 1.8 and need the new
> sql file to rename the function name. And it will be for PG12, not
> PG13. If we have to
On Wed, Sep 11, 2019 at 8:53 PM Masahiko Sawada wrote:
>
> I've attached the updated patch that incorporated all comments. I kept
> the function as superuser-restricted.
>
Thanks for the updated patch.
Few more comments:
*
+ if (!superuser())
+ ereport(ERROR,
+ (errcode
On Wed, Sep 11, 2019 at 1:46 PM Michael Paquier wrote:
>
> On Tue, Sep 10, 2019 at 08:29:43AM +0530, Amit Kapila wrote:
> > Good thought, but I think even if we want to change the name of
> > tuple_data_split, it might be better done separately.
>
> Yes, that's not the problem of this patch. Not
On Wed, Sep 11, 2019 at 11:30 PM Alvaro Herrera from 2ndQuadrant
wrote:
>
> On 2019-Sep-11, Masahiko Sawada wrote:
>
> > On Wed, Sep 11, 2019 at 1:46 PM Michael Paquier wrote:
> > >
> > > On Tue, Sep 10, 2019 at 08:29:43AM +0530, Amit Kapila wrote:
> > > > Good thought, but I think even if we
On 2019-Sep-11, Masahiko Sawada wrote:
> On Wed, Sep 11, 2019 at 1:46 PM Michael Paquier wrote:
> >
> > On Tue, Sep 10, 2019 at 08:29:43AM +0530, Amit Kapila wrote:
> > > Good thought, but I think even if we want to change the name of
> > > tuple_data_split, it might be better done separately.
>
On Tue, Sep 10, 2019 at 08:29:43AM +0530, Amit Kapila wrote:
> Good thought, but I think even if we want to change the name of
> tuple_data_split, it might be better done separately.
Yes, that's not the problem of this patch. Not sure if it actually
makes sense either to change it.
The
On Tue, Sep 10, 2019 at 10:21 AM Amit Kapila wrote:
>
> On Mon, Sep 9, 2019 at 6:22 PM Alvaro Herrera from 2ndQuadrant
> wrote:
> >
> > On 2019-Sep-08, Amit Kapila wrote:
> >
> > > On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > Thanks. I hope the attached new patch
On Tue, Sep 10, 2019 at 8:03 AM Masahiko Sawada wrote:
>
> On Tue, Sep 10, 2019 at 10:21 AM Amit Kapila wrote:
> >
> > On Mon, Sep 9, 2019 at 6:22 PM Alvaro Herrera from 2ndQuadrant
> > wrote:
> > > I think that other table AMs are not necessarily going to use the same
> > > infomask flags, so
On Tue, Sep 10, 2019 at 07:51:08AM +0530, Amit Kapila wrote:
> It will look bit strange to use heapam as a prefix for this function
> when all others use heap. I guess if we want to keep it AM specific,
> then the proposed name (heap_infomask_flags) is better or
> alternatively we can consider
On Mon, Sep 9, 2019 at 6:22 PM Alvaro Herrera from 2ndQuadrant
wrote:
>
> On 2019-Sep-08, Amit Kapila wrote:
>
> > On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada
> > wrote:
> > >
> > > Thanks. I hope the attached new patch fixes this issue.
> > *
> > +-- decode infomask flags as human readable
On 2019-Sep-08, Amit Kapila wrote:
> On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada wrote:
> >
> > Thanks. I hope the attached new patch fixes this issue.
> *
> +-- decode infomask flags as human readable flag names
> +CREATE FUNCTION heap_infomask_flags(
> + infomask integer,
> +
On Sun, Sep 8, 2019 at 1:06 PM Amit Kapila wrote:
>
> On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada wrote:
> >
> > Thanks. I hope the attached new patch fixes this issue.
> >
>
Some more comments:
*
+SELECT t_infomask, t_infomask2, flags
+FROM heap_page_items
(get_raw_page('test1', 0)),
+
On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada wrote:
>
> Thanks. I hope the attached new patch fixes this issue.
>
*
+-- decode infomask flags as human readable flag names
+CREATE FUNCTION heap_infomask_flags(
+ infomask integer,
+ infomask2 integer,
+ decode_combined boolean
On Thu, Sep 5, 2019 at 10:41 AM Michael Paquier wrote:
>
> On Wed, Sep 04, 2019 at 04:50:45PM -0400, Alvaro Herrera wrote:
> > According to CFbot, the Windows build fails with this patch. Please
> > fix.
>
> To save a couple of clicks:
> "C:\projects\postgresql\pageinspect.vcxproj" (default
On Wed, Sep 04, 2019 at 04:50:45PM -0400, Alvaro Herrera wrote:
> According to CFbot, the Windows build fails with this patch. Please
> fix.
To save a couple of clicks:
"C:\projects\postgresql\pageinspect.vcxproj" (default target) (56) ->
(Link target) ->
heapfuncs.obj : error LNK2001:
On 2019-Sep-04, Alvaro Herrera wrote:
> Attached v3 again, for CFbot's benefit. No changes from last time.
According to CFbot, the Windows build fails with this patch. Please
fix.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
Attached v3 again, for CFbot's benefit. No changes from last time.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 018077d786f874cb314b5f61b5ef85f42c62bbe5 Mon Sep 17 00:00:00 2001
From: Masahiko Sawada
On Fri, Aug 23, 2019 at 8:44 PM Michael Paquier wrote:
>
> On Fri, Aug 23, 2019 at 03:35:01PM +0900, Masahiko Sawada wrote:
> > Good idea. I've updated the doc update patch.
>
> Thanks. I have removed the output part as I am not sure that it is
> that helpful for the reader, and applied it down
On Fri, Aug 23, 2019 at 03:35:01PM +0900, Masahiko Sawada wrote:
> Good idea. I've updated the doc update patch.
Thanks. I have removed the output part as I am not sure that it is
that helpful for the reader, and applied it down to v10 where the
sections for function types have been introduced
On Fri, Aug 23, 2019 at 12:27 PM Michael Paquier wrote:
>
> On Fri, Aug 23, 2019 at 11:09:44AM +0900, Masahiko Sawada wrote:
> > While updating the doc I realized that
> > perhaps we should have the new section for heap and put the
> > descriptions of heap functions into it rather than having
On Fri, Aug 23, 2019 at 11:09:44AM +0900, Masahiko Sawada wrote:
> While updating the doc I realized that
> perhaps we should have the new section for heap and put the
> descriptions of heap functions into it rather than having them as
> general functions. If we need this change it is for PG12. I
On Thu, Aug 22, 2019 at 12:36 AM Masahiko Sawada wrote:
>
> On Thu, Aug 22, 2019 at 12:19 AM Alvaro Herrera
> wrote:
> >
> > Can I interest someone into updating this patch? We now have (I think)
> > an agreed design, and I think the development work needed should be
> > straightforward. We
On Thu, Aug 22, 2019 at 12:36:10AM +0900, Masahiko Sawada wrote:
> I will update the patch and register to the next Commit Fest tomorrow
> if nobody is interested in.
Thanks, Sawada-san.
--
Michael
signature.asc
Description: PGP signature
On Thu, Aug 22, 2019 at 12:19 AM Alvaro Herrera
wrote:
>
> Can I interest someone into updating this patch? We now have (I think)
> an agreed design, and I think the development work needed should be
> straightforward. We also already have the popcount stuff, so that's a
> few lines to be
Can I interest someone into updating this patch? We now have (I think)
an agreed design, and I think the development work needed should be
straightforward. We also already have the popcount stuff, so that's a
few lines to be removed from the patch ...
--
Álvaro Herrera
50 matches
Mail list logo
