Hi Tom,
> I looked at this and am inclined to reject it. [...]
OK, thanks. Then we are done with this thread. I closed the
corresponding CF entry.
--
Best regards,
Aleksander Alekseev
Aleksander Alekseev writes:
> This leaves us one patch to deal with.
> [ v4-0001-Pass-Size-size_t-as-a-2nd-argument-of-snprintf.patch ]
I looked at this and am inclined to reject it. None of these
places realistically need to deal with strings longer than
MAXPATHLEN or so, let alone multiple gig
Hi Amit,
> Pushed.
Thanks!
> I don't have a strong opinion on whether we should be really worried
> by this. But in case we do, here is the patch.
This leaves us one patch to deal with.
--
Best regards,
Aleksander Alekseev
v4-0001-Pass-Size-size_t-as-a-2nd-argument-of-snprintf.patch
Descrip
On Mon, Oct 10, 2022 at 7:09 PM Amit Kapila wrote:
>
> On Tue, Sep 27, 2022 at 5:04 PM Aleksander Alekseev
> wrote:
> >
> > Hi Peter,
> >
> > > PSA patch v3 to combine the different replication origin name
> > > formatting in a single function ReplicationOriginNameForLogicalRep as
> > > suggested
On Tue, Sep 27, 2022 at 5:04 PM Aleksander Alekseev
wrote:
>
> Hi Peter,
>
> > PSA patch v3 to combine the different replication origin name
> > formatting in a single function ReplicationOriginNameForLogicalRep as
> > suggested.
>
> LGTM except for minor issues with the formatting; fixed.
>
LGTM
Hi Peter,
> PSA patch v3 to combine the different replication origin name
> formatting in a single function ReplicationOriginNameForLogicalRep as
> suggested.
LGTM except for minor issues with the formatting; fixed.
> I expect you can find more like just this if you look harder than I did.
Than
On Tue, Sep 20, 2022 at 6:36 PM Aleksander Alekseev
wrote:
>
> Hi Amit,
>
> > I think it is better to use Size. Even though, it may not fail now as
> > the size of names for origin will always be much lesser but it is
> > better if we are consistent. If we agree with this, then as a first
> > patc
On Wed, Sep 21, 2022 at 8:22 PM Peter Smith wrote:
>
...
> > > On Wed, Sep 21, 2022 at 3:23 PM Amit Kapila
> > > wrote:
> > > ...
> > >
> > > > Can't we use the existing function ReplicationOriginNameForTablesync()
> > > > by passing relid as InvalidOid for this purpose? We need a check
> > > >
On Wed, Sep 21, 2022 at 8:08 PM Amit Kapila wrote:
>
> On Wed, Sep 21, 2022 at 3:09 PM Peter Smith wrote:
> >
> > On Wed, Sep 21, 2022 at 3:23 PM Amit Kapila wrote:
> > >
> > ...
> >
> > > Can't we use the existing function ReplicationOriginNameForTablesync()
> > > by passing relid as InvalidOid
On Wed, Sep 21, 2022 at 3:09 PM Peter Smith wrote:
>
> On Wed, Sep 21, 2022 at 3:23 PM Amit Kapila wrote:
> >
> ...
>
> > Can't we use the existing function ReplicationOriginNameForTablesync()
> > by passing relid as InvalidOid for this purpose? We need a check
> > inside to decide which name to
On Wed, Sep 21, 2022 at 3:23 PM Amit Kapila wrote:
>
...
> Can't we use the existing function ReplicationOriginNameForTablesync()
> by passing relid as InvalidOid for this purpose? We need a check
> inside to decide which name to construct, otherwise, it should be
> fine. If we agree with this, t
On Tue, Sep 20, 2022 at 2:06 PM Aleksander Alekseev
wrote:
>
> Hi Amit,
>
> > I think it is better to use Size. Even though, it may not fail now as
> > the size of names for origin will always be much lesser but it is
> > better if we are consistent. If we agree with this, then as a first
> > patc
On Tue, Sep 20, 2022 at 6:36 PM Aleksander Alekseev
wrote:
>
> Hi Amit,
>
> > I think it is better to use Size. Even though, it may not fail now as
> > the size of names for origin will always be much lesser but it is
> > better if we are consistent. If we agree with this, then as a first
> > patc
Hi Amit,
> I think it is better to use Size. Even though, it may not fail now as
> the size of names for origin will always be much lesser but it is
> better if we are consistent. If we agree with this, then as a first
> patch, we can make it to use Size in existing places and then
> introduce thi
On Mon, Sep 19, 2022 at 2:27 PM Aleksander Alekseev
wrote:
>
> Hi Peter,
>
> > PSA a patch to add a common function ReplicationOriginName
>
> The patch looks good to me.
>
> One nitpick I have is that the 2nd argument of snprintf is size_t
> while we are passing int's. Your patch is consistent wit
Hi Peter,
> PSA a patch to add a common function ReplicationOriginName
The patch looks good to me.
One nitpick I have is that the 2nd argument of snprintf is size_t
while we are passing int's. Your patch is consistent with the current
implementation of ReplicationOriginNameForTablesync() and sim
Hi.
There are already multiple places that are building the subscription
origin name, and there are more coming with some new patches [1] doing
the same:
e.g.
snprintf(originname, sizeof(originname), "pg_%u", subid);
~~
IMO it is better to encapsulate this name formatting in common code
instead
17 matches
Mail list logo
