►
From YouTube: Database Office Hours 2020-08-12
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
welcome
for
the
database
office,
hours
of
the
12th
of
august
2020.
I
see
patrick,
is
also
dropping
in
welcome
yeah
first
point
of
the
agenda
was
that
adam
deweys
made
sure
that
the
title
of
this
meeting
includes
the
wreck,
which
should
make
the
recording
start
automatically,
which
it
seems
it
does.
I
joined
this
first
one
and
the
recording
just
began,
let's
check
after
the
meeting,
if
the
recording
is
like
in
the
location
where
we
expected,
but
other
than
that,
I
think
this
is
working.
So
that's
that's
really,
nice.
A
I
guess
we
still
have
to
make
sure
that
it's
manually
uploaded
to
youtube,
but
yeah,
that's
something
we
cannot
get
around
with.
I
guess:
okay.
A
Next
item
was
yeah:
the
fact
that
the
schema
migration
versions
are
no
longer
in
structured
sql,
which
I
think
is
like
a
really
really
really
nice
improvement.
We
have
so
thanks,
patrick
for
that
personally,
I
not
have
been
like
involved
with
merge
requests
yet
who
had
to
change
something
about
that,
so
so
I'm
not
having
like
any
experience
with
it.
Yet
I
don't
know
if
any
users
are
having
trouble
with
regenerating
this.
This,
the
the
migration
or
stuff,
like
that,
any
any
thoughts
from
your
site.
B
I
think
people
you
know
mostly,
I
figured
it
out
now
there
is.
We
did
merge
yesterday
or
emerged
an
update,
which
is
that
it'll
only
create
create
now
a
schema
migration
file
if
the
migration
file
actually
exists
in
the
migrate
or
the
post
migrate
directory,
so
that
was
helping
people
when
they
were
switching
branches
and
things,
and
they
would
run
the
migrations
that
would
create
a
file
and
a
branch
from
the
migration
from
the
other
branch.
So
now
we
it
checks
to
see
if
the
migration
file
actually
exists.
A
Yeah,
that
seems
that
makes
sense.
That's
cool,
okay,
well,
yeah!
Let's
just
keep
an
eye
on
it
that
we
make
sure
that
every
like
every
merge
requests.
Does
it
the
right
way
now
and
other
than
that
I
guess
we'll
post
in
the
issue.
If
there
are
any
other
other
problems
with
that.
B
A
Cool.
The
last
item
is
from
adam.
Do
you
want
to
explain
our
shell
eyes
because
I've
been
reading
a
little.
C
Bit
sure
it's,
it
came
up
during
during
a
review,
and
I
was
also
thinking
about
this
earlier.
So
when
we
schedule
background
migrations,
we
always
set.
This
interval
like
two
minutes.
It's
coming
from
active
super
duration,
and
this
will
create
a
scheduled
sidekick
job
and
at
some
point
this
job
will
be
scheduled
and
the
default
interval
is
two
and
behind
the
scenes.
C
There
is
a
piece
of
code
that
ensures
that
we
cannot
schedule
the
same
background
migration
within
two
minutes,
and
the
concern
here
was
that
there
are
some
it's
not
precise,
what
the
sidekick
scheduler
does.
So
it
can
often
happen
when
you're
about
to
start
a
migration
about
to
schedule
another
job,
but
it's
actually
the
the
code
that
checks.
If
the
two
minutes
interval
is
is
okay,
it's
actually
returning
false.
C
So
it's
not
okay,
and
then
we
basically
skip
a
two
minute
slot,
which
makes
the
whole
migration
background
migration
run
longer
because
we
sometimes
might
skip
a
two.
B
C
Window-
and
I
haven't
really
spent
time
actually
verifying
this,
but
we
we
should
definitely
take
a
closer
look
and
see
if,
if
we
can
actually
if
this
is
actually
a
problem,
because
then
our
estimation
about
the
background.
A
Yeah,
I
guess
this
is
a
valid
point,
but
yeah
I
see
in
the
merge
request
that
mike
created
he.
He
set
the
interval
at
two
minutes
and
five
seconds,
which
is
probably
still
not
like
enough,
but
I'm
not
sure
how
how
precise
that
that
sidekick
actually
isn't
like
scheduling
if
there
was
a
lot
of
work
in
on
the
queue
anyway.
C
A
10
seconds,
even
or
or
whatever
I
don't
know,
another
thing,
I'm
just
wondering:
maybe
if
we
are
scheduling
job
in
batches,
should
we
maybe
because
it's
using
exclusive
leases
for
this?
Maybe
we
can
like
propose
if
you're
doing
things
in
bad
batches,
that,
like
the
batch
number
or
something
like
that,
it's
in
the
least
key,
so
that
multiplexes
can
like
be
out
of
sync,
but
it
can't
run
in
power
or
is
that.
C
A
C
How
to
verify
this
problem,
maybe
somewhere
below
the
the
background
jobs
with
the
execution
type,
so
we
can
actually
see
that
hey.
I
have
this
background.
C
Okay,
so
maybe
in
in
kibana
we
will
lock
the
executions
of
the
of
the
background
jobs
and
we
can
actually
see
the
timestamp
when
they
are
enqueued
and
and
from
there
we
can
see
if
you
notice
any
any
gaps
in
the
execution
times.
Normally,
we
should
see
for
a
particular
background
job
two
minutes
intervals
and
if
we
don't
see
them,
that
means
we
have
a
problem.
A
C
This
is
about
the
delay
between
two
background
job.
Sorry,
maybe
not
was
not
clear,
so
every
background
job
should
so,
if
you
have
a
background
job
that
that
you
you
create
sidekick
or
already,
the
scheduler
should
wait
two
minutes
between
each
each
slice
of
the
of
the
job.
So
that's
the
that's.
C
No,
I
don't
think
so.
It's
it's
when
we
when
we
schedule
the
the
jobs.
So
let's
say
you,
you
run
a
a
complex.
C
I
don't
know
have
to
insert
a
new
need
to
update
a
column
in
in
the
issues
table
and
then
you
do
this.
Each
batch
thing
to
have
patched
data
with
the
max
id
and
the
min
id,
and
then
we
create-
and
I
don't
know
a
few
hundred
few
thousand
of
background
jobs
scheduled
two
minutes
times.
Two
minutes
apart
and
and
and
the
problem
might
be
with
the
scheduling
because
we
say
say
from
now
in
two
minutes
process:
the
first
slice
and
after
basically
four
minutes
process.
The
second
slice.
C
C
I
don't
know
if
I,
if
I
understand
it,
if
I,
if
I
explain
it
clearly,
I
I
forget
to
link
the
there
is
a.
There
is
a
piece
of
a.
A
B
So
there
is
an
issue
tracking
that
right
now
it
hasn't
really
been
looked
at
recently,
but
it's
something
that
we
have
been
talking
about.
Maybe
looking
at.
We
did
a
little
bit
of
work
with
background
migrations
when
we
did
the
partitioning
it's
something
we
would
like
to
build
on.
So
I
can
link
to
issue.
B
If
you
have
comments,
that'd
be
great
to
add
them,
because
we
that
proposal
suggested
by
nick
was
to
have
you
know
each
job
and
cue
the
next
job
as
it's
running,
but
we
need
more
tracking
in
order
for
that
to
work
properly,
which
is
something
we
have
to
think
about
how
we
want
to
do
that,
because,
if
the
chain
breaks,
obviously,
then
you
know
that
one
job
fails
and
the
next.
We
need
some
way
to
restart
that
process.
So.
B
Right
yeah,
we
did
as
part
of
the
partitioning
work
we
added
a
table
in
the
database
to
track
the
background
migration
jobs-
we'll
probably
maybe
in
future
milestones-
be
adding
more
around
that.
B
A
Okay,
cool,
I'm
gonna,
wrap
it
up.
Then
thanks
everyone
for
joining
and
enjoy
your
day
bye.