Re: pgsql: Prevent invalidation of newly synced replication slots.
| От | Thomas Munro |
|---|---|
| Тема | Re: pgsql: Prevent invalidation of newly synced replication slots. |
| Дата | |
| Msg-id | CA+hUKGJotCdMdhrwVST4xbsPzr-csDgzveNhKu4UAXEmCDJ4iA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pgsql: Prevent invalidation of newly synced replication slots. (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: pgsql: Prevent invalidation of newly synced replication slots.
|
| Список | pgsql-hackers |
On Wed, Jan 28, 2026 at 3:59 AM Robert Haas <robertmhaas@gmail.com> wrote: > I imagine this is going to break CI for everybody else too, as well as cfbot. Just by the way, on that last point, we trained cfbot to watch out for CI pass/fail in this account: https://github.com/postgres/postgres/commits/master/ and then use the most recent pass as the base commit when applying patches to make test branches. So if master is broken for a while, it no longer takes all the cfbot runs with it. Mentioning just in case anyone is confused by that... As for what's happening... hmm, there are a few holes in the "shared locking" stuff you get with the flags we use. For example you can't unlink a directory that contains a file that has been unlinked but someone still holds open. Doesn't seem to be the case here. But I wonder if you can't rename("old", "new") where "new" is a file that has already been unlinked (or renamed over) that someone still holds open, or something like that...
В списке pgsql-hackers по дате отправления: