Re: Hot Standby, release candidate?

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby, release candidate?
Date: 2009-12-14 18:58:35
Message-ID: 1260817115.1955.1523.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2009-12-14 at 20:32 +0200, Heikki Linnakangas wrote:

> >> * You removed this comment from KnownAssignedXidsInit:
> >>
> >> - /*
> >> - * XXX: We should check that we don't exceed maxKnownAssignedXids.
> >> - * Even though the hash table might hold a few more entries than that,
> >> - * we use fixed-size arrays of that size elsewhere and expected all
> >> - * entries in the hash table to fit.
> >> - */
> >>
> >> but AFAICS you didn't address the issue. It's referring to the 'xids'
> >> array in TransactionIdIsInProgress(), which KnownAssignedXidsGet() fills
> >> in without checking that it fits.
> >
> > I have ensured that they are always the same size, by definition, so no
> > need to check.
>
> How did you ensure that? The hash table has no hard size limit.

The hash table is in shared memory and the entry size is fixed. My
understanding was that this meant the hash table was fixed in size and
could not grow beyond the allocation. If that assumption was wrong, then
yes we could get an error. Is it? Do you know from experience, or from
code comments?

Incidentally just picked up two much easier issues in that stretch of
code. Thanks for making me look again!

--
Simon Riggs www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-14 19:01:17 Re: Streaming replication and non-blocking I/O
Previous Message Scott Bailey 2009-12-14 18:54:06 Re: Range types