<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#ffffff" text="#000000">
A snippet of the log to start with<br>
<br>
11-Jun-2010 06:35:08.959 Postgres driver unable to find available
connection after searching 30 times<br>
11-Jun-2010 06:35:08.959 Postgres driver unable to return result set
for findzone query<br>
<br>
<blockquote>/*%<br>
* Loops through the list of DB instances, attempting to lock<br>
* on the mutex. If successful, the DBI is reserved for use<br>
* and the thread can perform queries against the database.<br>
* If the lock fails, the next one in the list is tried.<br>
* looping continues until a lock is obtained, or until<br>
* the list has been searched dbc_search_limit times.<br>
* This function is only used when the driver is compiled for<br>
* multithreaded operation.<br>
*/<br>
<br>
static dbinstance_t *<br>
postgres_find_avail_conn(db_list_t *dblist)<br>
{<br>
dbinstance_t *dbi = NULL;<br>
dbinstance_t *head;<br>
int count = 0;<br>
<br>
/* get top of list */<br>
head = dbi = ISC_LIST_HEAD(*dblist);<br>
<br>
/* loop through list */<br>
while (count < dbc_search_limit) {<br>
/* try to lock on the mutex */<br>
if (isc_mutex_trylock(&dbi->instance_lock) ==
ISC_R_SUCCESS)<br>
return dbi; /* success, return the DBI for use.
*/<br>
<br>
/* not successful, keep trying */<br>
dbi = ISC_LIST_NEXT(dbi, link);<br>
<br>
/* check to see if we have gone to the top of the list.
*/<br>
if (dbi == NULL) { <br>
count++; <br>
dbi = head;<br>
}<br>
}<br>
isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE,<br>
DNS_LOGMODULE_DLZ, ISC_LOG_INFO,<br>
"Postgres driver unable to find available
connection "<br>
"after searching %d times",<br>
count);<br>
return NULL;<br>
}<br>
</blockquote>
<br>
<br>
11-Jun-2010 06:35:09.080 name.c:2091: REQUIRE(suffixlabels > 0)
failed<br>
11-Jun-2010 06:35:09.081 exiting (due to assertion failure)<br>
<br>
<blockquote>void<br>
dns_name_split(dns_name_t *name, unsigned int suffixlabels,<br>
dns_name_t *prefix, dns_name_t *suffix)<br>
{<br>
unsigned int splitlabel;<br>
<br>
REQUIRE(VALID_NAME(name));<br>
REQUIRE(suffixlabels > 0);<br>
REQUIRE(suffixlabels < name->labels);<br>
REQUIRE(prefix != NULL || suffix != NULL);<br>
REQUIRE(prefix == NULL ||<br>
(VALID_NAME(prefix) &&<br>
prefix->buffer != NULL &&<br>
BINDABLE(prefix)));<br>
REQUIRE(suffix == NULL ||<br>
(VALID_NAME(suffix) &&<br>
suffix->buffer != NULL &&<br>
BINDABLE(suffix)));<br>
<br>
splitlabel = name->labels - suffixlabels;<br>
<br>
if (prefix != NULL)<br>
dns_name_getlabelsequence(name, 0, splitlabel, prefix);<br>
<br>
if (suffix != NULL)<br>
dns_name_getlabelsequence(name, splitlabel,<br>
suffixlabels, suffix);<br>
<br>
return; <br>
}<br>
</blockquote>
<br>
<br>
<br>
There are two issues here. a) why is bind rapid firing, and i mean
RAPID, the logs are overflowing with these messages. bind attempts to
find a free mutex connection and failing? 14 of these pairs in 3ms
with 80 seconds of silence prior to this and a minute of silence after
this. 420 attempts in 3ms.<br>
<br>
my postgresql logs aren't indicating anything is going on and the
machine is almost a blank slate for activity. it's entirely idle.
there's no hangup on resources for the DB so i have to presume that
bind itself has somehow gotten into a full-up state without good
reason. postgresql is indicating 4 idle connections normally. i have
maybe one or two queries per second averaged out of small 4-12 queries
in an ~8 second interval. maybe a microsleep pause would be
beneficial. better would be a dump showing which threads were doing
what to figure out why a supposedly idle system is all tied up.<br>
<br>
Next, b) named keeps dying with this entirely ambiguous assertion
failure. i'm sure it's a fault of my own but without any indication
where the issue lies, this like asking to find a leaf in a forest
without knowing what type of leaf you're looking for ^_^.<br>
<br>
Why is bind so prone to falling over and dying from typos? don't get
me wrong please, i love bind which is why i've been using it for ~15
years now. i've noted that bind has a strong tendancy to simply flat
out abort if it encounters zone data it doesn't like rather than report
it and drop the bad data. that's not really very reliable. it's ok
for testing in the lab but really bad manners for production. :><br>
<br>
A bit of help on these please :)<br>
<br>
-david<br>
<br>
</body>
</html>