From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_dump test instability
Date: Wed, 12 Sep 2018 12:06:35 -0400
Message-ID: <6771.1536768395@sss.pgh.pa.us> (raw)
In-Reply-To: <406b7f39-039d-6cfc-6d36-ee797d214af7@2ndquadrant.com>
References: <5137fe12-d0a2-4971-61b6-eb4e7e8875f8@2ndquadrant.com>
<32399.1535379095@sss.pgh.pa.us>
<20180827144138.GO3326@tamriel.snowman.net>
<1665.1535381158@sss.pgh.pa.us>
<20180827155943.GP3326@tamriel.snowman.net>
<1765.1535482037@sss.pgh.pa.us>
<406b7f39-039d-6cfc-6d36-ee797d214af7@2ndquadrant.com>
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> Some small comments on the code:
> Maybe add a ready_list_free() to go with ready_list_init(), instead of
> calling pg_free(ready_list.tes) directly.
> get_next_work_item() has been changed to remove the work item from the
> ready_list. Maybe rename to something like pop_next_work_item()?
Both seem reasonable, will do.
> I'm confused by what ready_list_remove() is doing when it's not removing
> the first item. It looks like it's removing all leading items up to the
> i'th one. Is that what we want? In some cases, we are skipping over
> things that we are not interested at all, so this would work, but if
> we're just skipping over an item because of a lock conflict, then it's
> not right.
No. In both code paths, the array slot at index first_te is being
physically dropped from the set of valid entries (by incrementing
first_te). In the first path, that slot holds the item we want to
remove logically from the set, so that incrementing first_te is
all we have to do: the remaining entries are still in the range
first_te..last_te, and they're still sorted. In the second code
path, the item that was in that slot is still wanted as part of
the set, so we copy it into the valid range (overwriting the item
in slot i, which is no longer wanted). Now the valid range is
probably not sorted, so we have to flag that a re-sort is needed.
I expect that most of the time the first code path will be taken,
because usually we'll be able to dispatch the highest-priority
ready entry. We'll only take the second path when we have to postpone
the highest-priority entry because of a potential lock conflict
against some already-running task. Any items between first_te and i
are other tasks that also have lock conflicts and can't be dispatched
yet; we certainly don't want to lose them, and this code doesn't.
If you can suggest comments that would clarify this more,
I'm all ears.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, peter.eisentraut@2ndquadrant.com, sfrost@snowman.net
Subject: Re: pg_dump test instability
In-Reply-To: <6771.1536768395@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox