On Wed, 20 Mar 2024 at 17:09, Amit Kapila wrote:
>
> On Tue, Mar 19, 2024 at 5:18 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Thanks for giving comments!
> >
> > > This behavior makes sense to me. But do we want to handle the case of
> > > using environment variables too?
> >
> > Yeah, v5 does
On Wed, Mar 20, 2024 at 2:24 PM vignesh C wrote:
>
> On Tue, 19 Mar 2024 at 17:18, Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear Sawada-san,
> >
> > Thanks for giving comments!
> >
> > > This behavior makes sense to me. But do we want to handle the case of
> > > using environment variables too?
On Tue, Mar 19, 2024 at 8:48 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Sawada-san,
>
> Thanks for giving comments!
>
> > This behavior makes sense to me. But do we want to handle the case of
> > using environment variables too?
>
> Yeah, v5 does not consider which libpq parameters are specified
On Tue, Mar 19, 2024 at 5:18 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Thanks for giving comments!
>
> > This behavior makes sense to me. But do we want to handle the case of
> > using environment variables too?
>
> Yeah, v5 does not consider which libpq parameters are specified by environment
>
On Tue, 19 Mar 2024 at 17:18, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Sawada-san,
>
> Thanks for giving comments!
>
> > This behavior makes sense to me. But do we want to handle the case of
> > using environment variables too?
>
> Yeah, v5 does not consider which libpq parameters are specified by
Dear Sawada-san,
Thanks for giving comments!
> This behavior makes sense to me. But do we want to handle the case of
> using environment variables too?
Yeah, v5 does not consider which libpq parameters are specified by environment
variables. Such a variable should be used when the dbname is
On Thu, Mar 14, 2024 at 11:46 PM vignesh C wrote:
>
> On Thu, 14 Mar 2024 at 15:49, Amit Kapila wrote:
> >
> > On Thu, Mar 14, 2024 at 1:45 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Mar 14, 2024 at 2:27 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Thu, Mar 14, 2024 at 5:57 AM
On Thu, 14 Mar 2024 at 15:49, Amit Kapila wrote:
>
> On Thu, Mar 14, 2024 at 1:45 PM Masahiko Sawada wrote:
> >
> > On Thu, Mar 14, 2024 at 2:27 PM Amit Kapila wrote:
> > >
> > > On Thu, Mar 14, 2024 at 5:57 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > This fact makes me think that the
On Thu, Mar 14, 2024 at 1:45 PM Masahiko Sawada wrote:
>
> On Thu, Mar 14, 2024 at 2:27 PM Amit Kapila wrote:
> >
> > On Thu, Mar 14, 2024 at 5:57 AM Masahiko Sawada
> > wrote:
> > >
> > > This fact makes me think that the slotsync worker might be able to
> > > accept the primary_conninfo
On Thu, Mar 14, 2024 at 2:27 PM Amit Kapila wrote:
>
> On Thu, Mar 14, 2024 at 5:57 AM Masahiko Sawada wrote:
> >
> > This fact makes me think that the slotsync worker might be able to
> > accept the primary_conninfo value even if there is no dbname in the
> > value. That is, if there is no
On Thu, Mar 14, 2024 at 10:57 AM Amit Kapila wrote:
>
> On Thu, Mar 14, 2024 at 5:57 AM Masahiko Sawada wrote:
> >
> > This fact makes me think that the slotsync worker might be able to
> > accept the primary_conninfo value even if there is no dbname in the
> > value. That is, if there is no
On Thu, Mar 14, 2024 at 5:57 AM Masahiko Sawada wrote:
>
> This fact makes me think that the slotsync worker might be able to
> accept the primary_conninfo value even if there is no dbname in the
> value. That is, if there is no dbname in the primary_conninfo, it uses
> the username in accordance
On Fri, Feb 23, 2024 at 3:05 PM Amit Kapila wrote:
>
> On Wed, Feb 21, 2024 at 7:46 AM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > > > Just FYI - here is an extreme case. And note that I have applied
> > > > proposed patch.
> > > >
> > > > When `pg_basebackup -D data_N2 -R` is used:
> > > > ```
>
On Wed, 13 Mar 2024 at 16:58, Amit Kapila wrote:
>
> On Tue, Mar 12, 2024 at 5:13 PM vignesh C wrote:
> >
> > On Mon, 11 Mar 2024 at 17:16, Amit Kapila wrote:
> > >
> > > On Tue, Feb 27, 2024 at 2:07 PM Hayato Kuroda (Fujitsu)
> > > wrote:
> > > >
> > > > > PSA the patch for implementing it.
On Tue, Mar 12, 2024 at 5:13 PM vignesh C wrote:
>
> On Mon, 11 Mar 2024 at 17:16, Amit Kapila wrote:
> >
> > On Tue, Feb 27, 2024 at 2:07 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > > PSA the patch for implementing it. It is basically same as Ian's one.
> > > > However, this patch still
On Mon, 11 Mar 2024 at 17:16, Amit Kapila wrote:
>
> On Tue, Feb 27, 2024 at 2:07 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > > PSA the patch for implementing it. It is basically same as Ian's one.
> > > However, this patch still cannot satisfy the condition 3).
> > >
> > > `pg_basebackup -D
On Tue, Feb 27, 2024 at 2:07 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > PSA the patch for implementing it. It is basically same as Ian's one.
> > However, this patch still cannot satisfy the condition 3).
> >
> > `pg_basebackup -D data_N2 -d "user=postgres" -R`
> > -> dbname would not be appeared in
On Tue, Feb 27, 2024 at 2:00 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > We do append dbname=replication even in libpqrcv_connect for .pgpass
> > lookup as mentioned in comments. See below:
> > libpqrcv_connect()
> > {
> >
> > else
> > {
> > /*
> > * The database name is ignored by the server in
> PSA the patch for implementing it. It is basically same as Ian's one.
> However, this patch still cannot satisfy the condition 3).
>
> `pg_basebackup -D data_N2 -d "user=postgres" -R`
> -> dbname would not be appeared in primary_conninfo.
>
> This is because `if (connection_string)` case in
Dear Amit,
> We do append dbname=replication even in libpqrcv_connect for .pgpass
> lookup as mentioned in comments. See below:
> libpqrcv_connect()
> {
>
> else
> {
> /*
> * The database name is ignored by the server in replication mode,
> * but specify "replication" for .pgpass lookup.
>
Dear Amit,
> When dbname is NULL or not given, it defaults to username. This
> follows the specs of the connection string. See (dbname #
> The database name. Defaults to be the same as the user name...) [1].
> Your patch breaks that specs, so I don't think it is correct.
I have proposed the
On Wed, Feb 21, 2024 at 8:34 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 20 Feb 2024 19:56:10 +0530, Robert Haas wrote
> in
> > It seems like maybe somebody should look into why this is happening,
> > and perhaps fix it.
>
> GetConnection()@streamutil.c wants to ensure conninfo has a fallback
>
On Wed, Feb 21, 2024 at 7:46 AM Hayato Kuroda (Fujitsu)
wrote:
>
> > > Just FYI - here is an extreme case. And note that I have applied proposed
> > > patch.
> > >
> > > When `pg_basebackup -D data_N2 -R` is used:
> > > ```
> > > primary_conninfo = 'user=hayato ... dbname=hayato ...
> > > ```
>
On Wed, Feb 21, 2024 at 4:09 PM Hayato Kuroda (Fujitsu) <
kuroda.hay...@fujitsu.com> wrote:
> Dear Horiguchi-san,
>
> > GetConnection()@streamutil.c wants to ensure conninfo has a fallback
> > database name ("replication"). However, the function seems to be
> > ignoring the case where neither
Dear Horiguchi-san,
> GetConnection()@streamutil.c wants to ensure conninfo has a fallback
> database name ("replication"). However, the function seems to be
> ignoring the case where neither dbname nor connection string is given,
> which is the first case Kuroda-san raised. The second case is
On Wed, Feb 21, 2024 at 2:04 PM Kyotaro Horiguchi
wrote:
>
> Although I haven't looked the original thread, it seems that the
> dbname is used only by pg_sync_replication_slots(). If it is true,
> couldn't we make the SQL function require a database name to make a
> connection, instead of
On Wed, Feb 21, 2024 at 2:04 PM Kyotaro Horiguchi
wrote:
>
> About the proposed patch, pg_basebackup cannot verify the validity of
> the dbname. It could be problematic.
>
> Although I haven't looked the original thread, it seems that the
> dbname is used only by pg_sync_replication_slots(). If
At Tue, 20 Feb 2024 19:56:10 +0530, Robert Haas wrote
in
> It seems like maybe somebody should look into why this is happening,
> and perhaps fix it.
GetConnection()@streamutil.c wants to ensure conninfo has a fallback
database name ("replication"). However, the function seems to be
ignoring
Dear Robert,
> > Just FYI - here is an extreme case. And note that I have applied proposed
> > patch.
> >
> > When `pg_basebackup -D data_N2 -R` is used:
> > ```
> > primary_conninfo = 'user=hayato ... dbname=hayato ...
> > ```
> >
> > But when `pg_basebackup -d "" -D data_N2 -R` is used:
> >
On Tue, Feb 20, 2024 at 5:58 PM Hayato Kuroda (Fujitsu)
wrote:
> > Seems weird to me. You don't use dbname=replication to ask for a
> > replication connection, so why would we ever end up with that
> > anywhere? And especially in only one of two such closely related
> > cases?
>
> Just FYI - here
Dear Robert,
> Seems weird to me. You don't use dbname=replication to ask for a
> replication connection, so why would we ever end up with that
> anywhere? And especially in only one of two such closely related
> cases?
Just FYI - here is an extreme case. And note that I have applied proposed
On Tue, Feb 20, 2024 at 4:18 PM Hayato Kuroda (Fujitsu)
wrote:
> I found an inconsistency. When I ran ` pg_basebackup -D data_N2 -U postgres
> -R`,
> dbname would be set as username.
>
> ```
> primary_conninfo = 'user=postgres ... dbname=postgres
> ```
>
> However, when I ran `pg_basebackup -D
Dear Ian,
Thanks for making the patch.
> With the addition of "pg_sync_replication_slots()", there is now a use-case
> for
> including "dbname" in "primary_conninfo" and the docs have changed from
> stating [1]:
>
> Do not specify a database name in the primary_conninfo string.
>
> to [2]:
On Tue, Feb 20, 2024 at 5:04 AM Ian Lawrence Barwick wrote:
>
>
> With the addition of "pg_sync_replication_slots()", there is now a use-case
> for
> including "dbname" in "primary_conninfo" and the docs have changed from
> stating [1]:
>
> Do not specify a database name in the
On Tue, 20 Feb 2024 at 00:34, Ian Lawrence Barwick wrote:
> With the addition of "pg_sync_replication_slots()", there is now a use-case
> for
> including "dbname" in "primary_conninfo" and the docs have changed from
> stating [1]:
>
> Do not specify a database name in the primary_conninfo
Hi
Hi
With the addition of "pg_sync_replication_slots()", there is now a use-case for
including "dbname" in "primary_conninfo" and the docs have changed from
stating [1]:
Do not specify a database name in the primary_conninfo string.
to [2]:
For replication slot synchronization (see
36 matches
Mail list logo
