| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Cc: | Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>, Shubham Barai <shubhambaraiss(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Borodin <amborodin86(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com> |
| Subject: | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
| Date: | 2018-03-29 12:06:26 |
| Message-ID: | 20180329120626.jjpap6cr7x5h23ds@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-www |
I don't quite understand the new call in gininsert -- I mean I see that
it wants to check for conflicts even when fastupdate is set, but why?
Maybe, just maybe, it would be better to add a new flag to the
GinCheckForSerializableConflictIn function, that's passed differently
for this one callsite, and then a comment next to it that indicates why
do we test for fastupdates in one case and not the other case.
If you don't like this idea, then I think more commentary on why
fastupdate is not considered in gininsert is warranted.
In startScanEntry, if you "goto restartScanEntry" in the fastupdate
case, are you trying to acquire the same lock again? Maybe the lock
acquire should occur before the goto target? (If this doesn't matter for
some reason, maybe add a comment about it)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2018-03-29 12:07:56 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
| Previous Message | Daniel Verite | 2018-03-29 11:53:55 | Re: csv format for psql |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2018-03-29 13:10:24 | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
| Previous Message | Teodor Sigaev | 2018-03-29 10:38:13 | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |