Thank you so much for replying, I'm really struggling here.
I ran out of space and I thought I could re-start it to see if it worked but again it's been more than a day and it isn't showing.
I ran this query and it shows that the table is still copying:
SELECT s.subname AS subscription_name,
c.relnamespace::regnamespace::text as table_schema,
c.relname as table_name,
rel.srsublsn,
case rel.srsubstate
when 'i' then 'initialized'
when 'd' then 'copying'
when 's' then 'synchronized'
when 'r' then 'ready'
end as state
FROM pg_catalog.pg_subscription s
JOIN pg_catalog.pg_subscription_rel rel ON rel.srsubid = s.oid
JOIN pg_catalog.pg_class c on c.oid = rel.srrelid;

If I check the pg_stat_activity on the publication I also see the backend_type = 'walsender'

In the publication the table size is 70G as you can see in the screenshot below 
but in the subscription, it's already 124G and still copying 😭 any suggestions?
Thanks again for your support, Amit
On Tue, Jul 18, 2023 at 11:08 AM PG Bug reporting form
<noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 18027
> Logged by: Andres Martin del Campo Campos
> Email address: andres@invisible.email
> PostgreSQL version: 13.2
> Operating system: PostgreSQL 13.2 on x86_64-pc-linux-gnu, compiled b
> Description:
>
> I'm trying to use logical replication to replicate a table of 69GB it's been
> a week and it hasn't synced but the table says (in the database where I'm
> replicating this table) is now 400GB and I'm running out of space. What's
> wrong, first I thought it was because of all the WAL logs but I'm now
> assuming it's something else.
>
This sounds a bit unusual. Have you verified the size of tables on
both publisher and subscriber? Can you once show the values of
pg_subscription_rel for this table? Are there any operations happening
on this table either on publisher or subscriber?
--
With Regards,
Amit Kapila.