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
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 |