Re: pg_replication_origin_drop API potential race condition
От | Alvaro Herrera |
---|---|
Тема | Re: pg_replication_origin_drop API potential race condition |
Дата | |
Msg-id | 20210209104637.GA29929@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pg_replication_origin_drop API potential race condition (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: pg_replication_origin_drop API potential race condition
|
Список | pgsql-hackers |
On 2021-Feb-09, Amit Kapila wrote: > > IIUC, you are suggesting to use lock for the particular origin instead > > of locking the corresponding catalog table in functions > > pg_replication_origin_advance and replorigin_drop_by_name. Right. > I think it won't be that straightforward as we don't have origin_id. > So what we instead need to do is first to acquire a lock on > ReplicationOriginRelationId, get the origin_id, lock the specific > origin and then re-check if the origin still exists. I feel some > similar changes might be required in pg_replication_origin_advance. Hmm, ok. > Now, we can do this optimization if we want but I am not sure if > origin_drop would be a frequent enough operation that we add such an > optimization. For now, I have added a note in the comments so that if > we find any such use case we can implement such optimization in the > future. What do you think? By all means let's get the bug fixed. Then, in another patch, we can optimize further, if there really is a problem. -- Álvaro Herrera 39°49'30"S 73°17'W "Siempre hay que alimentar a los dioses, aunque la tierra esté seca" (Orual)
В списке pgsql-hackers по дате отправления: