Re: BufferAlloc: don't take two simultaneous locks

Поиск
Список
Период
Сортировка
От Michail Nikolaev
Тема Re: BufferAlloc: don't take two simultaneous locks
Дата
Msg-id CANtu0ogqNyceN0WCS186OnBLhw71xzwGDUw+Yk3Qt4J9TcM_mg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BufferAlloc: don't take two simultaneous locks  (Michail Nikolaev <michail.nikolaev@gmail.com>)
Ответы Re: BufferAlloc: don't take two simultaneous locks
Re: BufferAlloc: don't take two simultaneous locks
Список pgsql-hackers
Hello, Yura.

A one additional moment:

> 1332: Assert((oldFlags & (BM_PIN_COUNT_WAITER | BM_IO_IN_PROGRESS)) == 0);
> 1333: CLEAR_BUFFERTAG(buf->tag);
> 1334: buf_state &= ~(BUF_FLAG_MASK | BUF_USAGECOUNT_MASK);
> 1335: UnlockBufHdr(buf, buf_state);

I think there is no sense to unlock buffer here because it will be
locked after a few moments (and no one is able to find it somehow). Of
course, it should be unlocked in case of collision.

BTW, I still think is better to introduce some kind of
hash_update_hash_key and use it.

It may look like this:

// should be called with oldPartitionLock acquired
// newPartitionLock hold on return
// oldPartitionLock and newPartitionLock are not taken at the same time
// if newKeyPtr is present - existingEntry is removed
bool hash_update_hash_key_or_remove(
          HTAB *hashp,
          void *existingEntry,
          const void *newKeyPtr,
          uint32 newHashValue,
          LWLock *oldPartitionLock,
          LWLock *newPartitionLock
);

Thanks,
Michail.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
Следующее
От: Joe Conway
Дата:
Сообщение: Re: [PATCH v2] use has_privs_for_role for predefined roles