pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedLost replication slots after pg_upgrade.
16+ messages / 5 participants
[nested] [flat]
* Lost replication slots after pg_upgrade.
@ 2022-02-02 10:17 Nikhil Shetty <nikhil.dba04@gmail.com>
0 siblings, 1 reply; 16+ messages in thread
From: Nikhil Shetty @ 2022-02-02 10:17 UTC (permalink / raw)
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
Hi,
I have a Primary and Standby running on Postgres v11.7.
I was following the document to upgrade a PG v11.7 cluster to PG v13.4.
After upgrade using pg_upgrade on primary, I ran rsync to setup standby
PG13 but when I started the primary, the replication slots were not
present. How will standby start streaming in this case?
We are using physical replication slots.
Thanks,
Nikhil
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-03 05:23 Victor Sudakov <vas@sibptus.ru>
parent: Nikhil Shetty <nikhil.dba04@gmail.com>
0 siblings, 2 replies; 16+ messages in thread
From: Victor Sudakov @ 2022-02-03 05:23 UTC (permalink / raw)
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin; +Cc: Nikhil Shetty <nikhil.dba04@gmail.com>
Nikhil Shetty wrote:
> Hi,
> I have a Primary and Standby running on Postgres v11.7.
>
> I was following the document to upgrade a PG v11.7 cluster to PG v13.4.
> After upgrade using pg_upgrade on primary, I ran rsync to setup standby
> PG13 but when I started the primary, the replication slots were not
> present. How will standby start streaming in this case?
>
> We are using physical replication slots.
You can create the replication slots manually with
pg_create_physical_replication_slot() any time.
However, unless you are very brave and know what you are doing, I'd
recommend using pg_basebackup to setup a standby, not rsync. You can
even use the -C and -S options of pg_basebackup to create the slots
for you, and many other pg_basebackup's nice options.
--
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-03 06:24 Vijaykumar Jain <vijaykumarjain.github@gmail.com>
parent: Victor Sudakov <vas@sibptus.ru>
1 sibling, 1 reply; 16+ messages in thread
From: Vijaykumar Jain @ 2022-02-03 06:24 UTC (permalink / raw)
To: Victor Sudakov <vas@sibptus.ru>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin; Nikhil Shetty <nikhil.dba04@gmail.com>
On Thu, Feb 3, 2022, 10:54 AM Victor Sudakov <vas@sibptus.ru> wrote:
> Nikhil Shetty wrote:
> > Hi,
> > I have a Primary and Standby running on Postgres v11.7.
> >
> > I was following the document to upgrade a PG v11.7 cluster to PG v13.4.
> > After upgrade using pg_upgrade on primary, I ran rsync to setup standby
> > PG13 but when I started the primary, the replication slots were not
> > present. How will standby start streaming in this case?
> >
> > We are using physical replication slots.
>
> You can create the replication slots manually with
> pg_create_physical_replication_slot() any time.
>
> However, unless you are very brave and know what you are doing, I'd
> recommend using pg_basebackup to setup a standby, not rsync. You can
> even use the -C and -S options of pg_basebackup to create the slots
> for you, and many other pg_basebackup's nice
>
A small demo of 11 to 13 upgrade using pg_upgrade and rsync.
It might not be all the best practices, but just following the doc on my
laptop.
>
https://gist.github.com/cabecada/4517af13245383b888833cfc69d741be
Just ensure the backed up configs are in back in and also create the
replication slot.
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-03 07:26 Victor Sudakov <vas@sibptus.ru>
parent: Vijaykumar Jain <vijaykumarjain.github@gmail.com>
0 siblings, 0 replies; 16+ messages in thread
From: Victor Sudakov @ 2022-02-03 07:26 UTC (permalink / raw)
To: Vijaykumar Jain <vijaykumarjain.github@gmail.com>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin; Nikhil Shetty <nikhil.dba04@gmail.com>
Vijaykumar Jain wrote:
> On Thu, Feb 3, 2022, 10:54 AM Victor Sudakov <vas@sibptus.ru> wrote:
>
> > Nikhil Shetty wrote:
> > > Hi,
> > > I have a Primary and Standby running on Postgres v11.7.
> > >
> > > I was following the document to upgrade a PG v11.7 cluster to PG v13.4.
> > > After upgrade using pg_upgrade on primary, I ran rsync to setup standby
> > > PG13 but when I started the primary, the replication slots were not
> > > present. How will standby start streaming in this case?
> > >
> > > We are using physical replication slots.
> >
> > You can create the replication slots manually with
> > pg_create_physical_replication_slot() any time.
> >
> > However, unless you are very brave and know what you are doing, I'd
> > recommend using pg_basebackup to setup a standby, not rsync. You can
> > even use the -C and -S options of pg_basebackup to create the slots
> > for you, and many other pg_basebackup's nice
> >
>
> A small demo of 11 to 13 upgrade using pg_upgrade and rsync.
> It might not be all the best practices, but just following the doc on my
> laptop.
>
> >
> https://gist.github.com/cabecada/4517af13245383b888833cfc69d741be
>
> Just ensure the backed up configs are in back in and also create the
> replication slot.
The black magick of using rsync instead of pg_basebackup is even
documented in https://www.postgresql.org/docs/13/pgupgrade.html but
it's much more difficult and error-prone than using pg_basebackup.
--
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-07 12:45 Nikhil Shetty <nikhil.dba04@gmail.com>
parent: Victor Sudakov <vas@sibptus.ru>
1 sibling, 1 reply; 16+ messages in thread
From: Nikhil Shetty @ 2022-02-07 12:45 UTC (permalink / raw)
To: Victor Sudakov <vas@sibptus.ru>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
Hi,
Thank you for the update. Is there a way we can retain the physical slot
during and after upgrade?
Thanks,
Nikhil
On Thu, Feb 3, 2022 at 10:53 AM Victor Sudakov <vas@sibptus.ru> wrote:
> Nikhil Shetty wrote:
> > Hi,
> > I have a Primary and Standby running on Postgres v11.7.
> >
> > I was following the document to upgrade a PG v11.7 cluster to PG v13.4.
> > After upgrade using pg_upgrade on primary, I ran rsync to setup standby
> > PG13 but when I started the primary, the replication slots were not
> > present. How will standby start streaming in this case?
> >
> > We are using physical replication slots.
>
> You can create the replication slots manually with
> pg_create_physical_replication_slot() any time.
>
> However, unless you are very brave and know what you are doing, I'd
> recommend using pg_basebackup to setup a standby, not rsync. You can
> even use the -C and -S options of pg_basebackup to create the slots
> for you, and many other pg_basebackup's nice options.
>
>
> --
> Victor Sudakov VAS4-RIPE
> http://vas.tomsk.ru/
> 2:5005/49@fidonet
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-08 03:34 Victor Sudakov <vas@sibptus.ru>
parent: Nikhil Shetty <nikhil.dba04@gmail.com>
0 siblings, 1 reply; 16+ messages in thread
From: Victor Sudakov @ 2022-02-08 03:34 UTC (permalink / raw)
To: Nikhil Shetty <nikhil.dba04@gmail.com>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
Nikhil Shetty wrote:
>
> Thank you for the update. Is there a way we can retain the physical slot
> during and after upgrade?
What exactly are you trying to achieve?
A minor upgrade does not destroy your slots, actually it does not
modify $PGDATA.
A major upgrade requires creating your replicas from scratch with
pg_basebackup (unless you are adventurous enough to go the rsync way).
pg_basebackup can create the slots for you automagically (-C -S) if
they are gone.
--
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-08 06:54 Nikhil Shetty <nikhil.dba04@gmail.com>
parent: Victor Sudakov <vas@sibptus.ru>
0 siblings, 1 reply; 16+ messages in thread
From: Nikhil Shetty @ 2022-02-08 06:54 UTC (permalink / raw)
To: Victor Sudakov <vas@sibptus.ru>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
Hi Victor,
I am doing a major version upgrade from pg 11 to 13. The point is if I lose
the replication slot after upgrade then how will I sync standby from
primary after rsync.
I can create the slot after upgrading but won't there be dataloss?
pg_basebackup takes time for large databases (> 5TB). I feel rsync should
be faster.
Thanks,
Nikhil
On Tue, Feb 8, 2022 at 9:04 AM Victor Sudakov <vas@sibptus.ru> wrote:
> Nikhil Shetty wrote:
> >
> > Thank you for the update. Is there a way we can retain the physical slot
> > during and after upgrade?
>
> What exactly are you trying to achieve?
>
> A minor upgrade does not destroy your slots, actually it does not
> modify $PGDATA.
>
> A major upgrade requires creating your replicas from scratch with
> pg_basebackup (unless you are adventurous enough to go the rsync way).
> pg_basebackup can create the slots for you automagically (-C -S) if
> they are gone.
>
> --
> Victor Sudakov VAS4-RIPE
> http://vas.tomsk.ru/
> 2:5005/49@fidonet
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-08 07:04 Julien Rouhaud <rjuju123@gmail.com>
parent: Nikhil Shetty <nikhil.dba04@gmail.com>
0 siblings, 2 replies; 16+ messages in thread
From: Julien Rouhaud @ 2022-02-08 07:04 UTC (permalink / raw)
To: Nikhil Shetty <nikhil.dba04@gmail.com>; +Cc: Victor Sudakov <vas@sibptus.ru>; Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
Hi,
On Tue, Feb 08, 2022 at 12:24:56PM +0530, Nikhil Shetty wrote:
>
> I am doing a major version upgrade from pg 11 to 13. The point is if I lose
> the replication slot after upgrade then how will I sync standby from
> primary after rsync.
>
> I can create the slot after upgrading but won't there be dataloss?
The replication slots are only there to make sure that the primary server won't
remove needed WALs before the standby can retrieve them. Unless you start
production activity just after the pg_upgrade and before finishing rebuilding
the secondary there shouldn't be enough activity to lead to removing old WALs.
But if you do, you can create the needed replication slot(s) manually just
after the pg_upgrade. But as already mentioned, I also recommend using
pg_basebackup for rebuilding the standby server(s).
> pg_basebackup takes time for large databases (> 5TB). I feel rsync should
> be faster.
Not necessarily. pg_basebackup will do simple sequential read of all the data,
which is probably the fastest thing to do. rsync will do some extra processing
that isn't required in that scenario, so it's likely to be slower (although
probably only marginally slower).
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-08 07:48 Nikhil Shetty <nikhil.dba04@gmail.com>
parent: Julien Rouhaud <rjuju123@gmail.com>
1 sibling, 2 replies; 16+ messages in thread
From: Nikhil Shetty @ 2022-02-08 07:48 UTC (permalink / raw)
To: Julien Rouhaud <rjuju123@gmail.com>; +Cc: Victor Sudakov <vas@sibptus.ru>; Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
Hi Julien,
Thank you for the information. I wanted to understand why the replication
slot is removed after or during upgrade?
Thanks,
Nikhil
On Tue, Feb 8, 2022 at 12:34 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> Hi,
>
> On Tue, Feb 08, 2022 at 12:24:56PM +0530, Nikhil Shetty wrote:
> >
> > I am doing a major version upgrade from pg 11 to 13. The point is if I
> lose
> > the replication slot after upgrade then how will I sync standby from
> > primary after rsync.
> >
> > I can create the slot after upgrading but won't there be dataloss?
>
> The replication slots are only there to make sure that the primary server
> won't
> remove needed WALs before the standby can retrieve them. Unless you start
> production activity just after the pg_upgrade and before finishing
> rebuilding
> the secondary there shouldn't be enough activity to lead to removing old
> WALs.
> But if you do, you can create the needed replication slot(s) manually just
> after the pg_upgrade. But as already mentioned, I also recommend using
> pg_basebackup for rebuilding the standby server(s).
>
> > pg_basebackup takes time for large databases (> 5TB). I feel rsync should
> > be faster.
>
> Not necessarily. pg_basebackup will do simple sequential read of all the
> data,
> which is probably the fastest thing to do. rsync will do some extra
> processing
> that isn't required in that scenario, so it's likely to be slower (although
> probably only marginally slower).
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-08 08:08 Julien Rouhaud <rjuju123@gmail.com>
parent: Nikhil Shetty <nikhil.dba04@gmail.com>
1 sibling, 1 reply; 16+ messages in thread
From: Julien Rouhaud @ 2022-02-08 08:08 UTC (permalink / raw)
To: Nikhil Shetty <nikhil.dba04@gmail.com>; +Cc: Victor Sudakov <vas@sibptus.ru>; Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
On Tue, Feb 08, 2022 at 01:18:39PM +0530, Nikhil Shetty wrote:
>
> Thank you for the information. I wanted to understand why the replication
> slot is removed after or during upgrade?
Because pg_upgrade modifies your primary instance in such a way that a standby
can't simply keep replicating from it.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-08 08:32 Victor Sudakov <vas@sibptus.ru>
parent: Julien Rouhaud <rjuju123@gmail.com>
1 sibling, 1 reply; 16+ messages in thread
From: Victor Sudakov @ 2022-02-08 08:32 UTC (permalink / raw)
To: Julien Rouhaud <rjuju123@gmail.com>; +Cc: Nikhil Shetty <nikhil.dba04@gmail.com>; Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
Julien Rouhaud wrote:
>
> > pg_basebackup takes time for large databases (> 5TB). I feel rsync should
> > be faster.
>
> Not necessarily. pg_basebackup will do simple sequential read of all the data,
> which is probably the fastest thing to do. rsync will do some extra processing
> that isn't required in that scenario, so it's likely to be slower (although
> probably only marginally slower).
I think Nikhil was going to invoke the rsync black magic as described
in https://www.postgresql.org/docs/current/pgupgrade.html, not for
copying the entire PGDATA from the master to standbys. While the rsync
magic should be hundreds of times faster because only modified files
will be copied and the majority of files will be just hardlinked, I've
never felt I have enough skill and luck to undertake this method.
--
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-08 08:34 Victor Sudakov <vas@sibptus.ru>
parent: Nikhil Shetty <nikhil.dba04@gmail.com>
1 sibling, 0 replies; 16+ messages in thread
From: Victor Sudakov @ 2022-02-08 08:34 UTC (permalink / raw)
To: Nikhil Shetty <nikhil.dba04@gmail.com>; +Cc: Julien Rouhaud <rjuju123@gmail.com>; Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
Nikhil Shetty wrote:
> Hi Julien,
>
> Thank you for the information. I wanted to understand why the replication
> slot is removed after or during upgrade?
Because pg_upgrade basically runs initdb for you. You are dealing with
a new cluster after pg_upgrade, in fact.
--
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-08 08:45 Julien Rouhaud <rjuju123@gmail.com>
parent: Victor Sudakov <vas@sibptus.ru>
0 siblings, 1 reply; 16+ messages in thread
From: Julien Rouhaud @ 2022-02-08 08:45 UTC (permalink / raw)
To: Victor Sudakov <vas@sibptus.ru>; +Cc: Nikhil Shetty <nikhil.dba04@gmail.com>; Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
On Tue, Feb 08, 2022 at 08:32:22AM +0000, Victor Sudakov wrote:
> Julien Rouhaud wrote:
> >
> > > pg_basebackup takes time for large databases (> 5TB). I feel rsync should
> > > be faster.
> >
> > Not necessarily. pg_basebackup will do simple sequential read of all the data,
> > which is probably the fastest thing to do. rsync will do some extra processing
> > that isn't required in that scenario, so it's likely to be slower (although
> > probably only marginally slower).
>
> I think Nikhil was going to invoke the rsync black magic as described
> in https://www.postgresql.org/docs/current/pgupgrade.html, not for
> copying the entire PGDATA from the master to standbys. While the rsync
> magic should be hundreds of times faster because only modified files
> will be copied and the majority of files will be just hardlinked, I've
> never felt I have enough skill and luck to undertake this method.
Ah, if that's the case I don't think there's any doubt to have for rsync being
faster. And this method works just fine if you take care of what you're doing.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-08 09:14 Nikhil Shetty <nikhil.dba04@gmail.com>
parent: Julien Rouhaud <rjuju123@gmail.com>
0 siblings, 0 replies; 16+ messages in thread
From: Nikhil Shetty @ 2022-02-08 09:14 UTC (permalink / raw)
To: Julien Rouhaud <rjuju123@gmail.com>; +Cc: Victor Sudakov <vas@sibptus.ru>; Pgsql-admin <pgsql-admin@lists.postgresql.org>; pgsql-admin
Hi,
I think Nikhil was going to invoke the rsync black magic as described
> in https://www.postgresql.org/docs/current/pgupgrade.html, not for
> copying the entire PGDATA from the master to standbys. While the rsync
> magic should be hundreds of times faster because only modified files
> will be copied and the majority of files will be just hardlinked, I've
> never felt I have enough skill and luck to undertake this method.
Yes, I am using rsync only to copy modified files.
Because pg_upgrade basically runs initdb for you. You are dealing with
> a new cluster after pg_upgrade, in fact.
Thanks for the details Victor and Julien.
Thanks,
Nikhil
On Tue, Feb 8, 2022 at 2:15 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> On Tue, Feb 08, 2022 at 08:32:22AM +0000, Victor Sudakov wrote:
> > Julien Rouhaud wrote:
> > >
> > > > pg_basebackup takes time for large databases (> 5TB). I feel rsync
> should
> > > > be faster.
> > >
> > > Not necessarily. pg_basebackup will do simple sequential read of all
> the data,
> > > which is probably the fastest thing to do. rsync will do some extra
> processing
> > > that isn't required in that scenario, so it's likely to be slower
> (although
> > > probably only marginally slower).
> >
> > I think Nikhil was going to invoke the rsync black magic as described
> > in https://www.postgresql.org/docs/current/pgupgrade.html, not for
> > copying the entire PGDATA from the master to standbys. While the rsync
> > magic should be hundreds of times faster because only modified files
> > will be copied and the majority of files will be just hardlinked, I've
> > never felt I have enough skill and luck to undertake this method.
>
> Ah, if that's the case I don't think there's any doubt to have for rsync
> being
> faster. And this method works just fine if you take care of what you're
> doing.
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-08 21:11 John DeSoi <desoi@pgedit.com>
parent: Julien Rouhaud <rjuju123@gmail.com>
0 siblings, 1 reply; 16+ messages in thread
From: John DeSoi @ 2022-02-08 21:11 UTC (permalink / raw)
To: Julien Rouhaud <rjuju123@gmail.com>; +Cc: Nikhil Shetty <nikhil.dba04@gmail.com>; Victor Sudakov <vas@sibptus.ru>; Pgsql-admin <pgsql-admin@lists.postgresql.org>
> On Feb 8, 2022, at 2:08 AM, Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> Because pg_upgrade modifies your primary instance in such a way that a standby
> can't simply keep replicating from it.
Would it work as expected if before pg_upgrade on the standby:
alter subscription my_subscription disable;
alter subscription my_subscription set (slot_name = NONE);
And then after pg_upgrade:
alter subscription my_subscription enable;
I have not tried it yet, but I thought this would be the simplest option.
John DeSoi, Ph.D.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Lost replication slots after pg_upgrade.
@ 2022-02-09 04:36 Nikhil Shetty <nikhil.dba04@gmail.com>
parent: John DeSoi <desoi@pgedit.com>
0 siblings, 0 replies; 16+ messages in thread
From: Nikhil Shetty @ 2022-02-09 04:36 UTC (permalink / raw)
To: John DeSoi <desoi@pgedit.com>; +Cc: Julien Rouhaud <rjuju123@gmail.com>; Victor Sudakov <vas@sibptus.ru>; Pgsql-admin <pgsql-admin@lists.postgresql.org>
Hi John,
Would it work as expected if before pg_upgrade on the standby:
> alter subscription my_subscription disable;
> alter subscription my_subscription set (slot_name = NONE);
> And then after pg_upgrade:
> alter subscription my_subscription enable;
> I have not tried it yet, but I thought this would be the simplest option.
We are using physical replication slots.
Thanks,
Nikhil
On Wed, Feb 9, 2022 at 2:41 AM John DeSoi <desoi@pgedit.com> wrote:
>
> > On Feb 8, 2022, at 2:08 AM, Julien Rouhaud <rjuju123@gmail.com> wrote:
> >
> > Because pg_upgrade modifies your primary instance in such a way that a
> standby
> > can't simply keep replicating from it.
>
> Would it work as expected if before pg_upgrade on the standby:
>
> alter subscription my_subscription disable;
> alter subscription my_subscription set (slot_name = NONE);
>
> And then after pg_upgrade:
>
> alter subscription my_subscription enable;
>
> I have not tried it yet, but I thought this would be the simplest option.
>
> John DeSoi, Ph.D.
>
>
>
^ permalink raw reply [nested|flat] 16+ messages in thread
end of thread, other threads:[~2022-02-09 04:36 UTC | newest]
Thread overview: 16+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-02-02 10:17 Lost replication slots after pg_upgrade. Nikhil Shetty <nikhil.dba04@gmail.com>
2022-02-03 05:23 ` Victor Sudakov <vas@sibptus.ru>
2022-02-03 06:24 ` Vijaykumar Jain <vijaykumarjain.github@gmail.com>
2022-02-03 07:26 ` Victor Sudakov <vas@sibptus.ru>
2022-02-07 12:45 ` Nikhil Shetty <nikhil.dba04@gmail.com>
2022-02-08 03:34 ` Victor Sudakov <vas@sibptus.ru>
2022-02-08 06:54 ` Nikhil Shetty <nikhil.dba04@gmail.com>
2022-02-08 07:04 ` Julien Rouhaud <rjuju123@gmail.com>
2022-02-08 07:48 ` Nikhil Shetty <nikhil.dba04@gmail.com>
2022-02-08 08:08 ` Julien Rouhaud <rjuju123@gmail.com>
2022-02-08 21:11 ` John DeSoi <desoi@pgedit.com>
2022-02-09 04:36 ` Nikhil Shetty <nikhil.dba04@gmail.com>
2022-02-08 08:34 ` Victor Sudakov <vas@sibptus.ru>
2022-02-08 08:32 ` Victor Sudakov <vas@sibptus.ru>
2022-02-08 08:45 ` Julien Rouhaud <rjuju123@gmail.com>
2022-02-08 09:14 ` Nikhil Shetty <nikhil.dba04@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox