From: "Vitaly Davydov" <v.davydov@postgrespro.ru>
Content-Type: multipart/mixed; boundary="----=_=-_OpenGroupware_org_NGMime-2622134-1730986239.853793-15------"
In-Reply-To: <1d2043-67235d00-5-2e3223c0@131762497>
References: <1d12d2-67235980-35-19a406a0@63439497> <1d2043-67235d00-5-2e3223c0@131762497>
Date: Thu, 07 Nov 2024 16:30:39 +0300
To: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Message-ID: <2802b6-672cc100-29-48025b80@131204041>
Subject: =?utf-8?q?Re=3A?= Slot's =?utf-8?q?restart=5Flsn?= may point to removed WAL 
 segment after hard restart unexpectedly
User-Agent: SOGoMail 5.11.2
Archived-At: <https://www.postgresql.org/message-id/2802b6-672cc100-29-48025b80%40131204041>
Precedence: bulk

------=_=-_OpenGroupware_org_NGMime-2622134-1730986239.853793-15------
Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_org_NGMime-2622134-1730986239.853712-14------"

------=_=-_OpenGroupware_org_NGMime-2622134-1730986239.853712-14------
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Length: 3775


Dear Hackers,
=C2=A0
I'd like to introduce an improved version of my patch (see the attached=
 file). My original idea was to take into account saved on disk restart=
=5Flsn (slot=E2=86=92restart=5Flsn=5Fflushed) for persistent slots when=
 removing WAL segment files. It helps tackle errors like: ERROR: reques=
ted WAL segment 000...0AA has already been removed.
=C2=A0
Improvements:
 * flushed=5Frestart=5Flsn is used only for RS=5FPERSISTENT slots. * Sa=
ve physical slot on disk when advancing only once - if restart=5Flsn=5F=
flushed is invalid. It is needed because slots with invalid restart LSN=
 are not used when calculating oldest LSN for WAL truncation. Once rest=
art=5Flsn becomes valid, it should be saved to disk immediately to upda=
te restart=5Flsn=5Fflushed.
Regression tests seems to be ok except:
 * recovery/t/001=5Fstream=5Frep.pl (checkpoint is needed) * recovery/t=
/019=5Freplslot=5Flimit.pl (it seems, slot was invalidated, some adjust=
ments are needed) * pg=5Fbasebackup/t/020=5Fpg=5Freceivewal.pl (not sur=
e about it)
=C2=A0
There are some problems:
 * More WAL segments may be kept. It may lead to invalidations of slots=
 in some tests (recovery/t/019=5Freplslot=5Flimit.pl). A couple of test=
s should be adjusted.
=C2=A0
With best regards,
Vitaly Davydov


On Thursday, October 31, 2024 13:32 MSK, "Vitaly Davydov" <v.davydov@po=
stgrespro.ru> wrote:

=C2=A0
Sorry, attached the missed patch.

On Thursday, October 31, 2024 13:18 MSK, "Vitaly Davydov" <v.davydov@po=
stgrespro.ru> wrote:

Dear Hackers,
=C2=A0
I'd like to discuss a problem with replication slots's restart LSN. Phy=
sical slots are saved to disk at the beginning of checkpoint. At the en=
d of checkpoint, old WAL segments are recycled or removed from disk, if=
 they are not kept by slot's restart=5Flsn values.
=C2=A0
If an existing physical slot is advanced in the middle of checkpoint ex=
ecution, WAL segments, which are related to saved on disk restart LSN m=
ay be removed. It is because the calculation of the replication slot mi=
minal LSN is occured at the end of checkpoint, prior to old WAL segment=
s removal. If to hard stop (pg=5Fstl -m immediate) the postgres instanc=
e right after checkpoint and to restart it, the slot's restart=5Flsn ma=
y point to the removed WAL segment. I believe, such behaviour is not go=
od.
=C2=A0
The doc [0] describes that restart=5Flsn may be set to the some past va=
lue after reload. There is a discussion [1] on pghackers where such beh=
aviour is discussed. The main reason of not flushing physical slots on =
advancing is a performance reason. I'm ok with such behaviour, except o=
f that the corresponding WAL segments should not be removed.
=C2=A0
I propose to keep WAL segments by saved on disk (flushed) restart=5Flsn=
 of slots. Add a new field restart=5Flsn=5Fflushed into ReplicationSlot=
 structure. Copy restart=5Flsn to restart=5Flsn=5Fflushed in SaveSlotTo=
Path. It doesn't change the format of storing the slot contents on disk=
. I attached a patch. It is not yet complete, but demonstate a way to s=
olve the problem.
=C2=A0
I reproduced the problem by the following way:
 * Add some delay in CheckPointBuffers (pg=5Fusleep) to emulate long ch=
eckpoint execution. * Execute checkpoint and pg=5Freplication=5Fslot=5F=
advance right after starting of the checkpoint from another connection.=
 * Hard restart the server right after checkpoint completion. * After r=
estart slot's restart=5Flsn may point to removed WAL segment.
The proposed patch fixes it.
=C2=A0
[0] https://www.postgresql.org/docs/current/logicaldecoding-explanation=
.html
[1] https://www.postgresql.org/message-id/flat/059cc53a-8b14-653a-a24d-=
5f867503b0ee%40postgrespro.ru


=C2=A0


=C2=A0

------=_=-_OpenGroupware_org_NGMime-2622134-1730986239.853712-14------
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Length: 4928

<html><p>Dear Hackers,</p><p>&nbsp;</p><p>I'd like to introduce an impr=
oved version of my patch (see the attached file). My original idea was =
to take into account saved on disk restart=5Flsn (slot=E2=86=92restart=5F=
lsn=5Fflushed) for persistent slots when removing WAL segment files. It=
 helps tackle errors like: <span style=3D"background-color:rgb(255,255,=
255);color:rgba(0,0,0,0.87);"><span style=3D"-webkit-text-stroke-width:=
0px;display:inline !important;float:none;font-family:&quot;Fira sans&qu=
ot;, &quot;Helvetica Neue&quot;, sans-serif;font-size:medium;font-style=
:normal;font-variant-caps:normal;font-variant-ligatures:normal;font-wei=
ght:400;letter-spacing:normal;orphans:2;text-align:start;text-decoratio=
n-color:initial;text-decoration-style:initial;text-decoration-thickness=
:initial;text-indent:0px;text-transform:none;white-space:pre-wrap;widow=
s:2;word-spacing:0px;">ERROR: requested WAL segment 000...0AA has alrea=
dy been removed.</span></span></p><p>&nbsp;</p><p>Improvements:</p><ul>=
<li>flushed=5Frestart=5Flsn is used only for RS=5FPERSISTENT slots.</li=
><li>Save physical slot on disk when advancing only once - if restart=5F=
lsn=5Fflushed is invalid. It is needed because slots with invalid resta=
rt LSN are not used when calculating oldest LSN for WAL truncation. Onc=
e restart=5Flsn becomes valid, it should be saved to disk immediately t=
o update restart=5Flsn=5Fflushed.</li></ul><p>Regression tests seems to=
 be ok except:</p><ul><li>recovery/t/001=5Fstream=5Frep.pl (checkpoint =
is needed)</li><li>recovery/t/019=5Freplslot=5Flimit.pl (it seems, slot=
 was invalidated, some adjustments are needed)</li><li>pg=5Fbasebackup/=
t/020=5Fpg=5Freceivewal.pl (not sure about it)</li></ul><p>&nbsp;</p><p=
>There are some problems:</p><ul><li>More WAL segments may be kept. It =
may lead to invalidations of slots in some tests (recovery/t/019=5Frepl=
slot=5Flimit.pl). A couple of tests should be adjusted.</li></ul><p>&nb=
sp;</p><p>With best regards,</p><p>Vitaly Davydov</p><p><br><br>On Thur=
sday, October 31, 2024 13:32 MSK, "Vitaly Davydov" &lt;v.davydov@postgr=
espro.ru&gt; wrote:<br><br>&nbsp;</p><blockquote type=3D"cite" cite=3D"=
1d2043-67235d00-5-2e3223c0@131762497"><p>Sorry, attached the missed pat=
ch.<br><br>On Thursday, October 31, 2024 13:18 MSK, "Vitaly Davydov" &l=
t;v.davydov@postgrespro.ru&gt; wrote:<br><br>Dear Hackers,</p><blockquo=
te type=3D"cite" cite=3D"1d12d2-67235980-35-19a406a0@63439497"><p>&nbsp=
;</p><p>I'd like to discuss a problem with replication slots's restart =
LSN. Physical slots are saved to disk at the beginning of checkpoint. A=
t the end of checkpoint, old WAL segments are recycled or removed from =
disk, if they are not kept by slot's restart=5Flsn values.</p><p>&nbsp;=
</p><p>If an existing physical slot is advanced in the middle of checkp=
oint execution, WAL segments, which are related to saved on disk restar=
t LSN may be removed. It is because the calculation of the replication =
slot miminal LSN is occured at the end of checkpoint, prior to old WAL =
segments removal. If to hard stop (pg=5Fstl -m immediate) the postgres =
instance right after checkpoint and to restart it, the slot's restart=5F=
lsn may point to the removed WAL segment. I believe, such behaviour is =
not good.</p><p>&nbsp;</p><p>The doc [0] describes that restart=5Flsn m=
ay be set to the some past value after reload. There is a discussion [1=
] on pghackers where such behaviour is discussed. The main reason of no=
t flushing physical slots on advancing is a performance reason. I'm ok =
with such behaviour, except of that the corresponding WAL segments shou=
ld not be removed.</p><p>&nbsp;</p><p>I propose to keep WAL segments by=
 saved on disk (flushed) restart=5Flsn of slots. Add a new field restar=
t=5Flsn=5Fflushed into ReplicationSlot structure. Copy restart=5Flsn to=
 restart=5Flsn=5Fflushed in SaveSlotToPath. It doesn't change the forma=
t of storing the slot contents on disk. I attached a patch. It is not y=
et complete, but demonstate a way to solve the problem.</p><p>&nbsp;</p=
><p>I reproduced the problem by the following way:</p><ul><li>Add some =
delay in CheckPointBuffers (pg=5Fusleep) to emulate long checkpoint exe=
cution.</li><li>Execute checkpoint and pg=5Freplication=5Fslot=5Fadvanc=
e right after starting of the checkpoint from another connection.</li><=
li>Hard restart the server right after checkpoint completion.</li><li>A=
fter restart slot's restart=5Flsn may point to removed WAL segment.</li=
></ul><p>The proposed patch fixes it.</p><p>&nbsp;</p><p>[0] https://ww=
w.postgresql.org/docs/current/logicaldecoding-explanation.html<br>[1] h=
ttps://www.postgresql.org/message-id/flat/059cc53a-8b14-653a-a24d-5f867=
503b0ee%40postgrespro.ru</p></blockquote><p><br><br><br>&nbsp;</p></blo=
ckquote><p><br><br><br>&nbsp;</p></html>

------=_=-_OpenGroupware_org_NGMime-2622134-1730986239.853712-14--------

------=_=-_OpenGroupware_org_NGMime-2622134-1730986239.853793-15------
Content-Type: text/x-patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="0001-Keep-WAL-segments-by-slot-s-flushed-restart-LSN.patch"
Content-Length: 8553

RnJvbSBkNTJlMjU0YzU1OGU2NjViYzQxMzg5ZTAyZTAyNmMxMDY5YjI5ODYxIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBWaXRhbHkgRGF2eWRvdiA8di5kYXZ5ZG92QHBvc3Rn
cmVzcHJvLnJ1PgpEYXRlOiBUaHUsIDMxIE9jdCAyMDI0IDEyOjI5OjEyICswMzAwClN1Ympl
Y3Q6IFtQQVRDSF0gS2VlcCBXQUwgc2VnbWVudHMgYnkgc2xvdCdzIGZsdXNoZWQgcmVzdGFy
dCBMU04KCi0tLQogc3JjL2JhY2tlbmQvcmVwbGljYXRpb24vc2xvdC5jICAgICAgfCAyNyAr
KysrKysrKysrKysrKysrKysrKysrKysrKy0KIHNyYy9iYWNrZW5kL3JlcGxpY2F0aW9uL3dh
bHNlbmRlci5jIHwgMTMgKysrKysrKysrKysrKwogc3JjL2luY2x1ZGUvcmVwbGljYXRpb24v
c2xvdC5oICAgICAgfCAgNCArKysrCiAzIGZpbGVzIGNoYW5nZWQsIDQzIGluc2VydGlvbnMo
KyksIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9zcmMvYmFja2VuZC9yZXBsaWNhdGlv
bi9zbG90LmMgYi9zcmMvYmFja2VuZC9yZXBsaWNhdGlvbi9zbG90LmMKaW5kZXggNjgyODEw
MGNmMS4uZTZhZWYxZjlhMyAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvcmVwbGljYXRpb24v
c2xvdC5jCisrKyBiL3NyYy9iYWNrZW5kL3JlcGxpY2F0aW9uL3Nsb3QuYwpAQCAtNDA5LDYg
KzQwOSw3IEBAIFJlcGxpY2F0aW9uU2xvdENyZWF0ZShjb25zdCBjaGFyICpuYW1lLCBib29s
IGRiX3NwZWNpZmljLAogCXNsb3QtPmNhbmRpZGF0ZV9yZXN0YXJ0X3ZhbGlkID0gSW52YWxp
ZFhMb2dSZWNQdHI7CiAJc2xvdC0+Y2FuZGlkYXRlX3Jlc3RhcnRfbHNuID0gSW52YWxpZFhM
b2dSZWNQdHI7CiAJc2xvdC0+bGFzdF9zYXZlZF9jb25maXJtZWRfZmx1c2ggPSBJbnZhbGlk
WExvZ1JlY1B0cjsKKwlzbG90LT5yZXN0YXJ0X2xzbl9mbHVzaGVkID0gSW52YWxpZFhMb2dS
ZWNQdHI7CiAJc2xvdC0+aW5hY3RpdmVfc2luY2UgPSAwOwogCiAJLyoKQEAgLTExNDIsMjAg
KzExNDMsMjggQEAgUmVwbGljYXRpb25TbG90c0NvbXB1dGVSZXF1aXJlZExTTih2b2lkKQog
CXsKIAkJUmVwbGljYXRpb25TbG90ICpzID0gJlJlcGxpY2F0aW9uU2xvdEN0bC0+cmVwbGlj
YXRpb25fc2xvdHNbaV07CiAJCVhMb2dSZWNQdHIJcmVzdGFydF9sc247CisJCVhMb2dSZWNQ
dHIJcmVzdGFydF9sc25fZmx1c2hlZDsKIAkJYm9vbAkJaW52YWxpZGF0ZWQ7CisJCVJlcGxp
Y2F0aW9uU2xvdFBlcnNpc3RlbmN5IHBlcnNpc3RlbmN5OwogCiAJCWlmICghcy0+aW5fdXNl
KQogCQkJY29udGludWU7CiAKIAkJU3BpbkxvY2tBY3F1aXJlKCZzLT5tdXRleCk7CisJCXBl
cnNpc3RlbmN5ID0gcy0+ZGF0YS5wZXJzaXN0ZW5jeTsKIAkJcmVzdGFydF9sc24gPSBzLT5k
YXRhLnJlc3RhcnRfbHNuOwogCQlpbnZhbGlkYXRlZCA9IHMtPmRhdGEuaW52YWxpZGF0ZWQg
IT0gUlNfSU5WQUxfTk9ORTsKKwkJcmVzdGFydF9sc25fZmx1c2hlZCA9IHMtPnJlc3RhcnRf
bHNuX2ZsdXNoZWQ7CiAJCVNwaW5Mb2NrUmVsZWFzZSgmcy0+bXV0ZXgpOwogCiAJCS8qIGlu
dmFsaWRhdGVkIHNsb3RzIG5lZWQgbm90IGFwcGx5ICovCiAJCWlmIChpbnZhbGlkYXRlZCkK
IAkJCWNvbnRpbnVlOwogCisJCS8qIHRydW5jYXRlIFdBTCBmb3IgcGVyc2lzdGVudCBzbG90
cyBieSBmbHVzaGVkIHJlc3RhcnRfbHNuICovCisJCWlmIChwZXJzaXN0ZW5jeSA9PSBSU19Q
RVJTSVNURU5UKQorCQkJcmVzdGFydF9sc24gPSByZXN0YXJ0X2xzbl9mbHVzaGVkOworCiAJ
CWlmIChyZXN0YXJ0X2xzbiAhPSBJbnZhbGlkWExvZ1JlY1B0ciAmJgogCQkJKG1pbl9yZXF1
aXJlZCA9PSBJbnZhbGlkWExvZ1JlY1B0ciB8fAogCQkJIHJlc3RhcnRfbHNuIDwgbWluX3Jl
cXVpcmVkKSkKQEAgLTExOTMsNyArMTIwMiw5IEBAIFJlcGxpY2F0aW9uU2xvdHNDb21wdXRl
TG9naWNhbFJlc3RhcnRMU04odm9pZCkKIAl7CiAJCVJlcGxpY2F0aW9uU2xvdCAqczsKIAkJ
WExvZ1JlY1B0cglyZXN0YXJ0X2xzbjsKKwkJWExvZ1JlY1B0cglyZXN0YXJ0X2xzbl9mbHVz
aGVkOwogCQlib29sCQlpbnZhbGlkYXRlZDsKKwkJUmVwbGljYXRpb25TbG90UGVyc2lzdGVu
Y3kgcGVyc2lzdGVuY3k7CiAKIAkJcyA9ICZSZXBsaWNhdGlvblNsb3RDdGwtPnJlcGxpY2F0
aW9uX3Nsb3RzW2ldOwogCkBAIC0xMjA3LDE0ICsxMjE4LDIwIEBAIFJlcGxpY2F0aW9uU2xv
dHNDb21wdXRlTG9naWNhbFJlc3RhcnRMU04odm9pZCkKIAogCQkvKiByZWFkIG9uY2UsIGl0
J3Mgb2sgaWYgaXQgaW5jcmVhc2VzIHdoaWxlIHdlJ3JlIGNoZWNraW5nICovCiAJCVNwaW5M
b2NrQWNxdWlyZSgmcy0+bXV0ZXgpOwotCQlyZXN0YXJ0X2xzbiA9IHMtPmRhdGEucmVzdGFy
dF9sc247CisJCXBlcnNpc3RlbmN5ID0gcy0+ZGF0YS5wZXJzaXN0ZW5jeTsKKwkJcmVzdGFy
dF9sc24gPSBzLT5yZXN0YXJ0X2xzbl9mbHVzaGVkOwogCQlpbnZhbGlkYXRlZCA9IHMtPmRh
dGEuaW52YWxpZGF0ZWQgIT0gUlNfSU5WQUxfTk9ORTsKKwkJcmVzdGFydF9sc25fZmx1c2hl
ZCA9IHMtPnJlc3RhcnRfbHNuX2ZsdXNoZWQ7CiAJCVNwaW5Mb2NrUmVsZWFzZSgmcy0+bXV0
ZXgpOwogCiAJCS8qIGludmFsaWRhdGVkIHNsb3RzIG5lZWQgbm90IGFwcGx5ICovCiAJCWlm
IChpbnZhbGlkYXRlZCkKIAkJCWNvbnRpbnVlOwogCisJCS8qIHRydW5jYXRlIFdBTCBmb3Ig
cGVyc2lzdGVudCBzbG90cyBieSBmbHVzaGVkIHJlc3RhcnRfbHNuICovCisJCWlmIChwZXJz
aXN0ZW5jeSA9PSBSU19QRVJTSVNURU5UKQorCQkJcmVzdGFydF9sc24gPSByZXN0YXJ0X2xz
bl9mbHVzaGVkOworCiAJCWlmIChyZXN0YXJ0X2xzbiA9PSBJbnZhbGlkWExvZ1JlY1B0cikK
IAkJCWNvbnRpbnVlOwogCkBAIC0xNDMyLDYgKzE0NDksNyBAQCBSZXBsaWNhdGlvblNsb3RS
ZXNlcnZlV2FsKHZvaWQpCiAKIAlBc3NlcnQoc2xvdCAhPSBOVUxMKTsKIAlBc3NlcnQoc2xv
dC0+ZGF0YS5yZXN0YXJ0X2xzbiA9PSBJbnZhbGlkWExvZ1JlY1B0cik7CisJQXNzZXJ0KHNs
b3QtPnJlc3RhcnRfbHNuX2ZsdXNoZWQgPT0gSW52YWxpZFhMb2dSZWNQdHIpOwogCiAJLyoK
IAkgKiBUaGUgcmVwbGljYXRpb24gc2xvdCBtZWNoYW5pc20gaXMgdXNlZCB0byBwcmV2ZW50
IHJlbW92YWwgb2YgcmVxdWlyZWQKQEAgLTE2MDcsNiArMTYyNSw4IEBAIEludmFsaWRhdGVQ
b3NzaWJseU9ic29sZXRlU2xvdChSZXBsaWNhdGlvblNsb3RJbnZhbGlkYXRpb25DYXVzZSBj
YXVzZSwKIAkJICovCiAJCVNwaW5Mb2NrQWNxdWlyZSgmcy0+bXV0ZXgpOwogCisJCUFzc2Vy
dChzLT5kYXRhLnJlc3RhcnRfbHNuID49IHMtPnJlc3RhcnRfbHNuX2ZsdXNoZWQpOworCiAJ
CXJlc3RhcnRfbHNuID0gcy0+ZGF0YS5yZXN0YXJ0X2xzbjsKIAogCQkvKiB3ZSBkbyBub3Ro
aW5nIGlmIHRoZSBzbG90IGlzIGFscmVhZHkgaW52YWxpZCAqLwpAQCAtMTY5MSw3ICsxNzEx
LDEwIEBAIEludmFsaWRhdGVQb3NzaWJseU9ic29sZXRlU2xvdChSZXBsaWNhdGlvblNsb3RJ
bnZhbGlkYXRpb25DYXVzZSBjYXVzZSwKIAkJCSAqIGp1c3QgcmVseSBvbiAuaW52YWxpZGF0
ZWQuCiAJCQkgKi8KIAkJCWlmIChpbnZhbGlkYXRpb25fY2F1c2UgPT0gUlNfSU5WQUxfV0FM
X1JFTU9WRUQpCisJCQl7CiAJCQkJcy0+ZGF0YS5yZXN0YXJ0X2xzbiA9IEludmFsaWRYTG9n
UmVjUHRyOworCQkJCXMtPnJlc3RhcnRfbHNuX2ZsdXNoZWQgPSBJbnZhbGlkWExvZ1JlY1B0
cjsKKwkJCX0KIAogCQkJLyogTGV0IGNhbGxlciBrbm93ICovCiAJCQkqaW52YWxpZGF0ZWQg
PSB0cnVlOwpAQCAtMjE4OSw2ICsyMjEyLDcgQEAgU2F2ZVNsb3RUb1BhdGgoUmVwbGljYXRp
b25TbG90ICpzbG90LCBjb25zdCBjaGFyICpkaXIsIGludCBlbGV2ZWwpCiAJaWYgKCFzbG90
LT5qdXN0X2RpcnRpZWQpCiAJCXNsb3QtPmRpcnR5ID0gZmFsc2U7CiAJc2xvdC0+bGFzdF9z
YXZlZF9jb25maXJtZWRfZmx1c2ggPSBjcC5zbG90ZGF0YS5jb25maXJtZWRfZmx1c2g7CisJ
c2xvdC0+cmVzdGFydF9sc25fZmx1c2hlZCA9IGNwLnNsb3RkYXRhLnJlc3RhcnRfbHNuOwog
CVNwaW5Mb2NrUmVsZWFzZSgmc2xvdC0+bXV0ZXgpOwogCiAJTFdMb2NrUmVsZWFzZSgmc2xv
dC0+aW9faW5fcHJvZ3Jlc3NfbG9jayk7CkBAIC0yMzg2LDYgKzI0MTAsNyBAQCBSZXN0b3Jl
U2xvdEZyb21EaXNrKGNvbnN0IGNoYXIgKm5hbWUpCiAJCXNsb3QtPmVmZmVjdGl2ZV94bWlu
ID0gY3Auc2xvdGRhdGEueG1pbjsKIAkJc2xvdC0+ZWZmZWN0aXZlX2NhdGFsb2dfeG1pbiA9
IGNwLnNsb3RkYXRhLmNhdGFsb2dfeG1pbjsKIAkJc2xvdC0+bGFzdF9zYXZlZF9jb25maXJt
ZWRfZmx1c2ggPSBjcC5zbG90ZGF0YS5jb25maXJtZWRfZmx1c2g7CisJCXNsb3QtPnJlc3Rh
cnRfbHNuX2ZsdXNoZWQgPSBjcC5zbG90ZGF0YS5yZXN0YXJ0X2xzbjsKIAogCQlzbG90LT5j
YW5kaWRhdGVfY2F0YWxvZ194bWluID0gSW52YWxpZFRyYW5zYWN0aW9uSWQ7CiAJCXNsb3Qt
PmNhbmRpZGF0ZV94bWluX2xzbiA9IEludmFsaWRYTG9nUmVjUHRyOwpkaWZmIC0tZ2l0IGEv
c3JjL2JhY2tlbmQvcmVwbGljYXRpb24vd2Fsc2VuZGVyLmMgYi9zcmMvYmFja2VuZC9yZXBs
aWNhdGlvbi93YWxzZW5kZXIuYwppbmRleCAzNzFlZWYzZGRkLi4wM2NkY2UyM2YwIDEwMDY0
NAotLS0gYS9zcmMvYmFja2VuZC9yZXBsaWNhdGlvbi93YWxzZW5kZXIuYworKysgYi9zcmMv
YmFja2VuZC9yZXBsaWNhdGlvbi93YWxzZW5kZXIuYwpAQCAtMjMyOSw2ICsyMzI5LDcgQEAg
c3RhdGljIHZvaWQKIFBoeXNpY2FsQ29uZmlybVJlY2VpdmVkTG9jYXRpb24oWExvZ1JlY1B0
ciBsc24pCiB7CiAJYm9vbAkJY2hhbmdlZCA9IGZhbHNlOworCVhMb2dSZWNQdHIJcmVzdGFy
dF9sc25fZmx1c2hlZDsKIAlSZXBsaWNhdGlvblNsb3QgKnNsb3QgPSBNeVJlcGxpY2F0aW9u
U2xvdDsKIAogCUFzc2VydChsc24gIT0gSW52YWxpZFhMb2dSZWNQdHIpOwpAQCAtMjMzNiw2
ICsyMzM3LDcgQEAgUGh5c2ljYWxDb25maXJtUmVjZWl2ZWRMb2NhdGlvbihYTG9nUmVjUHRy
IGxzbikKIAlpZiAoc2xvdC0+ZGF0YS5yZXN0YXJ0X2xzbiAhPSBsc24pCiAJewogCQljaGFu
Z2VkID0gdHJ1ZTsKKwkJcmVzdGFydF9sc25fZmx1c2hlZCA9IHNsb3QtPnJlc3RhcnRfbHNu
X2ZsdXNoZWQ7CiAJCXNsb3QtPmRhdGEucmVzdGFydF9sc24gPSBsc247CiAJfQogCVNwaW5M
b2NrUmVsZWFzZSgmc2xvdC0+bXV0ZXgpOwpAQCAtMjM0Myw2ICsyMzQ1LDE3IEBAIFBoeXNp
Y2FsQ29uZmlybVJlY2VpdmVkTG9jYXRpb24oWExvZ1JlY1B0ciBsc24pCiAJaWYgKGNoYW5n
ZWQpCiAJewogCQlSZXBsaWNhdGlvblNsb3RNYXJrRGlydHkoKTsKKworCQkvKiBTYXZlIHRo
ZSByZXBsaWNhdGlvbiBzbG90IG9uIGRpc2sgaW4gY2FzZSBvZiBpdHMgZmx1c2hlZCByZXN0
YXJ0X2xzbgorCQkgKiBpcyBpbnZhbGlkLiBTbG90cyB3aXRoIGludmFsaWQgcmVzdGFydCBs
c24gYXJlIGlnbm9yZWQgd2hlbgorCQkgKiBjYWxjdWxhdGluZyByZXF1aXJlZCBMU04uIE9u
Y2Ugd2Ugc3RhcnRlZCB0byBrZWVwIHRoZSBXQUwgYnkgZmx1c2hlZAorCQkgKiByZXN0YXJ0
IExTTiwgd2Ugc2hvdWxkIHNhdmUgdG8gZGlzayBhbiBpbml0aWFsIHZhbGlkIHZhbHVlLgor
CQkgKi8KKwkJaWYgKHNsb3QtPmRhdGEucGVyc2lzdGVuY3kgPT0gUlNfUEVSU0lTVEVOVCkg
eworCQkJaWYgKHJlc3RhcnRfbHNuX2ZsdXNoZWQgPT0gSW52YWxpZFhMb2dSZWNQdHIgJiYg
bHNuICE9IEludmFsaWRYTG9nUmVjUHRyKQorCQkJCVJlcGxpY2F0aW9uU2xvdFNhdmUoKTsK
KwkJfQorCiAJCVJlcGxpY2F0aW9uU2xvdHNDb21wdXRlUmVxdWlyZWRMU04oKTsKIAkJUGh5
c2ljYWxXYWtldXBMb2dpY2FsV2FsU25kKCk7CiAJfQpkaWZmIC0tZ2l0IGEvc3JjL2luY2x1
ZGUvcmVwbGljYXRpb24vc2xvdC5oIGIvc3JjL2luY2x1ZGUvcmVwbGljYXRpb24vc2xvdC5o
CmluZGV4IDQ1NTgyY2Y5ZDguLmNhNGMzYWFiM2IgMTAwNjQ0Ci0tLSBhL3NyYy9pbmNsdWRl
L3JlcGxpY2F0aW9uL3Nsb3QuaAorKysgYi9zcmMvaW5jbHVkZS9yZXBsaWNhdGlvbi9zbG90
LmgKQEAgLTIwNyw2ICsyMDcsMTAgQEAgdHlwZWRlZiBzdHJ1Y3QgUmVwbGljYXRpb25TbG90
CiAKIAkvKiBUaGUgdGltZSBzaW5jZSB0aGUgc2xvdCBoYXMgYmVjb21lIGluYWN0aXZlICov
CiAJVGltZXN0YW1wVHogaW5hY3RpdmVfc2luY2U7CisKKwkvKiBMYXRlc3QgcmVzdGFydCBM
U04gdGhhdCB3YXMgZmx1c2hlZCB0byBkaXNrICovCisJWExvZ1JlY1B0ciByZXN0YXJ0X2xz
bl9mbHVzaGVkOworCiB9IFJlcGxpY2F0aW9uU2xvdDsKIAogI2RlZmluZSBTbG90SXNQaHlz
aWNhbChzbG90KSAoKHNsb3QpLT5kYXRhLmRhdGFiYXNlID09IEludmFsaWRPaWQpCi0tIAoy
LjM0LjEKCg==

------=_=-_OpenGroupware_org_NGMime-2622134-1730986239.853793-15--------