Re: Re: BUG #15929: logical decoding can not write down the analyse result when the output file is touched.

From: "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>
To: "Andres Freund" <andres(at)anarazel(dot)de>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Re: BUG #15929: logical decoding can not write down the analyse result when the output file is touched.
Date: 2019-10-16 06:57:33
Message-ID: 2019101614573142796519@highgo.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs



>I don't see a bug here. It's completely normal for a tool that writes to
>a file to continue writing into the file it started to write to. The
>reason that vi breaks that is presumably just that it renames the
>"edited" version into the place of the file that pg_recvlogical is still
>writing to.

It is the issue that the target file is changed but the 'pg_recvlogical'
process doesn't know it at all. So it streams all wal changes but writes
down nothing at last.

So I think we can recreate or reopen the changed file when there be
something wrong with the target file. And we can choose to kill the
'pg_recvlogical' process because it's no use at all now, or we should
give a warning to users at lease.

---
Highgo Software (Canada/China/Pakistan)
URL : www.highgo.ca
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2019-10-16 07:16:56 Re: Duplicate Workers entries in some EXPLAIN plans
Previous Message Thomas Munro 2019-10-16 06:10:48 Re: ERROR: multixact X from before cutoff Y found to be still running