Skip site navigation (1) Skip section navigation (2)

Re: vacuum as flags in PGPROC

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: vacuum as flags in PGPROC
Date: 2007-10-24 14:31:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> I'm wondering if it's safe to do something like
> MyProc->vacuumFlags |= PROC_FOR_XID_WRAPAROUND
> without holding the ProcArrayLock.

This seems a bit itchy.

One thing I'd be worried about is processors that implement that by
fetching the whole word containing the field, setting the bit, and
storing back the whole word.  (I believe some RISC processors are likely
to do it like that.)  This would mean that it'd work OK only as long as
no other process was concurrently changing any field that happened to be
in the same word, which is the kind of requirement that seems horribly
fragile.  You could probably fix that by declaring the field as
sig_atomic_t.  Maybe better, just make it int.

Another problem is that if you don't take a lock then there's no memory
fence instructions executed, which would create issues around how soon
other processors would see the effects of the change.  While that might
not be critical for the vacuum flags, it still seems a bit worrisome.

Given that you're only changing these flags twice per vacuum, it doesn't
seem worth taking any risks by not taking a lock ...

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Alvaro HerreraDate: 2007-10-24 15:13:28
Subject: Re: vacuum as flags in PGPROC
Previous:From: Alvaro HerreraDate: 2007-10-24 14:13:10
Subject: Re: vacuum as flags in PGPROC

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group