On 05/20/2014 09:42 AM, Tom Lane wrote:
Regarding clock skew, I think we can do better then what you suggest.
The web transaction code in the client adds its own timestamp just
before running the web transaction. It would be quite reasonable to
reject reports from machines with skewed clocks ba
On 05/20/2014 03:59 PM, Gavin Flower wrote:
On 21/05/14 01:42, Tom Lane wrote:
Andrew Dunstan writes:
On 05/20/2014 07:09 AM, Tom Lane wrote:
Robert's got a point here. In my usage, the annoying thing is not animals
that take a long time to report in; it's the ones that lie about the
snapsh
On 21/05/14 01:42, Tom Lane wrote:
Andrew Dunstan writes:
On 05/20/2014 07:09 AM, Tom Lane wrote:
Robert's got a point here. In my usage, the annoying thing is not animals
that take a long time to report in; it's the ones that lie about the
snapshot time (which is how you get "512abc4 in the
Andrew Dunstan writes:
> On 05/20/2014 07:09 AM, Tom Lane wrote:
>> Robert's got a point here. In my usage, the annoying thing is not animals
>> that take a long time to report in; it's the ones that lie about the
>> snapshot time (which is how you get "512abc4 in the middle of a bunch of
>> ef9a
On 05/20/2014 07:09 AM, Tom Lane wrote:
Robert Haas writes:
On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan wrote:
Well, the original code was put in for a reason, presumably that we were
getting some stale data and wanted to exclude it. So I'm unwilling to throw
it out altogether. If someon
Robert Haas writes:
> On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan wrote:
>> Well, the original code was put in for a reason, presumably that we were
>> getting some stale data and wanted to exclude it. So I'm unwilling to throw
>> it out altogether. If someone can propose a reasonable sanity
On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan wrote:
> Well, the original code was put in for a reason, presumably that we were
> getting some stale data and wanted to exclude it. So I'm unwilling to throw
> it out altogether. If someone can propose a reasonable sanity check then I'm
> prepared
Andrew Dunstan writes:
> Well, the original code was put in for a reason, presumably that we were
> getting some stale data and wanted to exclude it. So I'm unwilling to
> throw it out altogether. If someone can propose a reasonable sanity
> check then I'm prepared to implement it.
Would it be
On 05/19/2014 05:37 PM, Tomas Vondra wrote:
IMHO the problem is that d6a97674 was the last revision in the
REL9_3_STABLE branch when the test started (00:14), but at 06:06
777d07d7 got committed. So the check at the end failed, because the
tested revision was suddenly ~2 days over the limit.
T
On 19.5.2014 23:04, Andrew Dunstan wrote:
>
> On 05/19/2014 03:40 PM, Tomas Vondra wrote:
>> On 17.5.2014 22:35, Tomas Vondra wrote:
>>> On 17.5.2014 19:58, Andrew Dunstan wrote:
On 05/15/2014 07:47 PM, Tomas Vondra wrote:
> On 15.5.2014 22:07, Andrew Dunstan wrote:
>> Yes, I've seen
On 05/19/2014 03:40 PM, Tomas Vondra wrote:
On 17.5.2014 22:35, Tomas Vondra wrote:
On 17.5.2014 19:58, Andrew Dunstan wrote:
On 05/15/2014 07:47 PM, Tomas Vondra wrote:
On 15.5.2014 22:07, Andrew Dunstan wrote:
Yes, I've seen that. Frankly, a test that takes something like 500
hours is a bi
On 17.5.2014 22:35, Tomas Vondra wrote:
> On 17.5.2014 19:58, Andrew Dunstan wrote:
>>
>> On 05/15/2014 07:47 PM, Tomas Vondra wrote:
>>> On 15.5.2014 22:07, Andrew Dunstan wrote:
Yes, I've seen that. Frankly, a test that takes something like 500
hours is a bit crazy.
>>> Maybe. It certai
On 17.5.2014 19:58, Andrew Dunstan wrote:
>
> On 05/15/2014 07:47 PM, Tomas Vondra wrote:
>> On 15.5.2014 22:07, Andrew Dunstan wrote:
>>> Yes, I've seen that. Frankly, a test that takes something like 500
>>> hours is a bit crazy.
>> Maybe. It certainly is not a test people will use during develo
On 05/15/2014 07:47 PM, Tomas Vondra wrote:
On 15.5.2014 22:07, Andrew Dunstan wrote:
Yes, I've seen that. Frankly, a test that takes something like 500
hours is a bit crazy.
Maybe. It certainly is not a test people will use during development.
But if it can detect some hard-to-find errors in
On 15.5.2014 22:07, Andrew Dunstan wrote:
>
> Yes, I've seen that. Frankly, a test that takes something like 500
> hours is a bit crazy.
Maybe. It certainly is not a test people will use during development.
But if it can detect some hard-to-find errors in the code, that might
possibly lead to se
On 15.5.2014 22:56, Andrew Dunstan wrote:
>
> On 05/15/2014 04:30 PM, Stefan Kaltenbrunner wrote:
>
>> well I'm not sure about about "misconfigured" but both my personal
>> buildfarm members and pginfra run ones (like gaibasaurus) got errors
>> complaining about "snapshot too old" in the past for
On 05/15/2014 04:30 PM, Stefan Kaltenbrunner wrote:
On 05/15/2014 07:46 PM, Andrew Dunstan wrote:
On 05/15/2014 12:43 PM, Tomas Vondra wrote:
Hi all,
today I got a few of errors like these (this one is from last week,
though):
Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014
On 05/15/2014 07:46 PM, Andrew Dunstan wrote:
>
> On 05/15/2014 12:43 PM, Tomas Vondra wrote:
>> Hi all,
>>
>> today I got a few of errors like these (this one is from last week,
>> though):
>>
>> Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014 GMT
>> Content:
>> snapshot t
Andrew Dunstan writes:
> Incidentally, should the CLOBBER_CACHE_ALWAYS machines also be defining
> CLOBBER_FREED_MEMORY?
The former does need the latter or it's not very thorough. However,
CLOBBER_FREED_MEMORY is defined automatically by --enable-cassert,
so you shouldn't need to use a -D switc
On 05/15/2014 03:57 PM, Tomas Vondra wrote:
How long does a CLOBBER_CACHE_RECURSIVELY run take? days or weeks seems
kinda nuts.
I don't know. According to this comment from cache/inval.c, it's expected
to be way slower (~100x) compared to CLOBBER_CACHE_ALWAYS.
/*
* Test code to force cache f
On 15 Květen 2014, 19:46, Andrew Dunstan wrote:
>
> On 05/15/2014 12:43 PM, Tomas Vondra wrote:
>> Hi all,
>>
>> today I got a few of errors like these (this one is from last week,
>> though):
>>
>> Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014 GMT
>> Content:
>> snapshot
On 05/15/2014 12:43 PM, Tomas Vondra wrote:
Hi all,
today I got a few of errors like these (this one is from last week, though):
Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014 GMT
Content:
snapshot to old: Wed May 7 04:36:57 2014 GMT
on the new buildfarm animals. I b
Hi all,
today I got a few of errors like these (this one is from last week, though):
Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014 GMT
Content:
snapshot to old: Wed May 7 04:36:57 2014 GMT
on the new buildfarm animals. I believe it was my mistake (incorrectly
configured l
23 matches
Mail list logo
