On 11.10.2014 21:37, Stephen Frost wrote:
> * Peter van Dijk (peter.van.d...@netherlabs.nl) wrote:
>> On 03 Jul 2014, at 16:04 , Klaus Darilion
>> wrote:
>>> I also think that performing multiple transfers for the same zone should
>>> be avoided in the application.
>>
>> Please file a ticket at
Hello Stephen,
On 11 Oct 2014, at 21:37 , Stephen Frost wrote:
> This doesn't appear to have been addressed in 3.4.0- was the bug ever
> submitted and is there a plan to fix it..?
We are tracking it as https://github.com/PowerDNS/pdns/issues/1502. There is no
fix yet.
Kind regards,
--
Peter
* Peter van Dijk (peter.van.d...@netherlabs.nl) wrote:
> On 03 Jul 2014, at 16:04 , Klaus Darilion
> wrote:
> > I also think that performing multiple transfers for the same zone should
> > be avoided in the application.
>
> Please file a ticket at https://github.com/PowerDNS/pdns/issues/new so w
Hello Klaus,
On 03 Jul 2014, at 16:04 , Klaus Darilion wrote:
> I also think that performing multiple transfers for the same zone should
> be avoided in the application.
Please file a ticket at https://github.com/PowerDNS/pdns/issues/new so we don’t
forget!
Kind regards,
--
Peter van Dijk
Ne
On 03.07.2014 17:41, k...@rice.edu wrote:
> On Thu, Jul 03, 2014 at 05:30:52PM +0200, Klaus Darilion wrote:
>>> Hi Klaus,
>>>
>>> We use gpgsql as well. We only have problems on the initial transfer of
>>> the zone because there are no existing records in the domain. Then if
>>> multiple AXFRs ar
On Thu, Jul 03, 2014 at 05:30:52PM +0200, Klaus Darilion wrote:
> > Hi Klaus,
> >
> > We use gpgsql as well. We only have problems on the initial transfer of
> > the zone because there are no existing records in the domain. Then if
> > multiple AXFRs are started, records can be duplicated. Once th
On 03.07.2014 16:47, k...@rice.edu wrote:
> On Thu, Jul 03, 2014 at 04:04:43PM +0200, Klaus Darilion wrote:
>>> Hi Klaus,
>>>
>>> We have observed the same behavior here. When it takes longer to perform
>>> a zone transfer than the periodic check interval (60s), a second will be
>>> initiated wit
On Thu, Jul 03, 2014 at 04:04:43PM +0200, Klaus Darilion wrote:
> > Hi Klaus,
> >
> > We have observed the same behavior here. When it takes longer to perform
> > a zone transfer than the periodic check interval (60s), a second will be
> > initiated with the results that you have reported. We curr
On 03.07.2014 14:56, k...@rice.edu wrote:
> On Thu, Jul 03, 2014 at 02:01:49PM +0200, Klaus Darilion wrote:
>> Another workaround (untested) would be to put an explicit lock at the
>> beginning of the "delete-zone-query":
>> delete-zone-query="LOCK;delete from records where domain_id=%d"
>>
>> Bu
On Thu, Jul 03, 2014 at 02:01:49PM +0200, Klaus Darilion wrote:
> Another workaround (untested) would be to put an explicit lock at the
> beginning of the "delete-zone-query":
> delete-zone-query="LOCK;delete from records where domain_id=%d"
>
> But (if it is allowed to have multiple statements in
Another workaround (untested) would be to put an explicit lock at the
beginning of the "delete-zone-query":
delete-zone-query="LOCK;delete from records where domain_id=%d"
But (if it is allowed to have multiple statements in the
delete-zone-query command) it would lock the whole table also for all
Hi.
I think we found the cause for the problem (but no solution yet). It
seems the problem happens only during the first zone transfer, when
there are no RRs in the records table yet. See the following log messages:
1. The zone is inserted into the domains table as type=SLAVE
2. We execute "pdn
Hi! We use PowerDNS 3.3.1 as slave with Postgresql DB as backend. Today
I found out that for some zones the whole zone is duplicated in the
records table (2 SOA records, ... every record is twice there). For one
zone we had all the records 6 times - thus a zone with 6 SOA records,
There is no
13 matches
Mail list logo
