| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: logical replication: could not create file "state.tmp": File exists |
| Date: | 2019-12-11 17:40:11 |
| Message-ID: | 20191211174011.qm7jfbtbli2gjibc@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2019-12-11 14:27:45 +0900, Michael Paquier wrote:
> On Mon, Dec 02, 2019 at 08:12:22AM -0800, Andres Freund wrote:
> > I'm very doubtful about this. I think it's a good safety measure to
> > ensure that there's no previous state file that we're somehow
> > overwriting.
>
> During the checkpoint of replication slots, SaveSlotToPath() would
> just *LOG* any failure while leaving around the state.tmp of a slot,
> and then any follow-up attempt to create state.tmp would just fail
> because of that, preventing the slot state file from being flushed
> continuously. I think that's wrong. Concurrency is not a concern
> either here as the slot's LWLock to track an I/O in progress is taken
> in exclusive lock.
I'm not clear on what you're saying? I don't see how I'm arguing for the
type of behaviour you seem to be describing?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2019-12-11 20:00:02 | BUG #16161: pg_ctl stop fails sometimes (on Windows) |
| Previous Message | Roman Cervenak | 2019-12-11 17:23:39 | Re: Memory leak (possibly connected to postgis) leading to server crash |