On Sat, Sep 26, 2009 at 9:57 AM, Gerhard Wiesinger <lists@wiesinger.com> wrote:
> On Sat, 26 Sep 2009, Greg Smith wrote:
>
>> On Fri, 25 Sep 2009, Jeff Janes wrote:
>>
>>> Does it do this even if the block was already in shared_buffers?
>>
>> Usually not. The buffer ring algorithm is used to manage pages that are
>> read in specifically to satisfy a sequential scan (there's a slightly
>> different ring method used for VACUUM too). If the buffer you need is
>> already available and not "pinned" (locked by someone else), it's not read
>> from disk again. Instead, its usage count is incremently only if it's at
>> zero (this doesn't count as a use unless it's about to be evicted as
>> unused), and it's returned without being added to the ring.
>>
>
> Hello Greg,
>
> What happens when a postmaster dies (e.g. core dump, kill -9, etc.). How is
> reference counting cleaned up and the lock removed?
If a backend dies in disgrace, the master detects this and the whole
cluster is taken down and brought back up.
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process
exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
(The DETAIL is technically accurate, but somewhat misleading. If the
crash to another backend happens while your backend is waiting on the
commit record WAL fsync to return, then while the postmaster may have
commanded your session to rollback, it is too late to actually do so
and when the server comes back up and finishes recovery, you will
probably find that your transaction has indeed committed, assuming you
have some way to accurately deduce this)
Jeff