Tom Lane <[EMAIL PROTECTED]> wrote:
> I've applied the attached modified version of your patch. In this
> coding, absorbs are done after every 1000 buffer writes in BufferSync
> and after every 10 fsyncs in mdsync. We may need to twiddle these
> numbers but it seems at least in the right ballpa
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> I suspect it'd probably be sufficient to absorb requests every few times
>> through the fsync loop, too, if you want to experiment with that.
> In the above test, smgrsync took 50 sec for syncing 32 files. This m
Tom Lane <[EMAIL PROTECTED]> wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > Attached is a revised patch. It became very simple, but I worry that
> > one magic number (BUFFERS_PER_ABSORB) is still left.
>
> Have you checked that this version of the patch fixes the problem you
> saw orig
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Attached is a revised patch. It became very simple, but I worry that
> one magic number (BUFFERS_PER_ABSORB) is still left.
Have you checked that this version of the patch fixes the problem you
saw originally? Does the problem come back if you change
Tom Lane <[EMAIL PROTECTED]> wrote:
> > "ITAGAKI Takahiro" <[EMAIL PROTECTED]> wrote
> >> AbsorbFsyncRequests will be called during the fsync loop in my patch,
> >> so new files might be added to pendingOpsTable and they will be removed
> >> from the table *before* writing the pages belonging to t
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Maybe the take a copied list is safer. I got a little afraid of doing
> seqscan hash while doing HASH_ENTER at the same time. Do we have this kind
> of hash usage somewhere?
Sure, it's perfectly safe. It's unspecified whether the scan will visit
suc
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> Yes, the patch is wrong as-is because it may lose uncompleted fsyncs.
> But I think that we could just add the AbsorbFsyncRequests call in the
> fsync loop and not worry about trying to avoid doing extra fsyncs.
>
> Another possibility is to make the copied
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> "ITAGAKI Takahiro" <[EMAIL PROTECTED]> wrote
>> AbsorbFsyncRequests will be called during the fsync loop in my patch,
>> so new files might be added to pendingOpsTable and they will be removed
>> from the table *before* writing the pages belonging to th
"ITAGAKI Takahiro" <[EMAIL PROTECTED]> wrote
>
> AbsorbFsyncRequests will be called during the fsync loop in my patch,
> so new files might be added to pendingOpsTable and they will be removed
> from the table *before* writing the pages belonging to them.
> So I changed it to copy the contents of
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote:
>while ((entry = (PendingOperationEntry *) hash_seq_search(&hstat)) != NULL)
>{
> + if (i >= count)
> +elog(ERROR, "pendingOpsTable corrupted");
> +
> + memcpy(&entries[i++], entry, sizeof(PendingOperationEntry));
> +
> + if (hash_search
"ITAGAKI Takahiro" <[EMAIL PROTECTED]> wrote
>
> Attached is a patch that fixes overflow of bgwriter's file-fsync request
> queue.
>
while ((entry = (PendingOperationEntry *) hash_seq_search(&hstat)) !=
NULL)
{
+ if (i >= count)
+elog(ERROR, "pendingOpsTable corrupted");
+
+ memcp
Attached is a patch that fixes overflow of bgwriter's file-fsync request queue.
It happened on heavy update workloads and the performance decreased.
I have sent HACKERS the detail.
---
ITAGAKI Takahiro
NTT Cyber Space Laboratories
bgwriter-requests-queue-overflow-2.patch
Description: Binary dat
12 matches
Mail list logo
