public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v52 1/7] sequential scan for dshash
10+ messages / 7 participants
[nested] [flat]
* [PATCH v52 1/7] sequential scan for dshash
@ 2020-03-13 07:58 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Kyotaro Horiguchi @ 2020-03-13 07:58 UTC (permalink / raw)
Dshash did not allow scan the all entries sequentially. This adds the
functionality. The interface is similar but a bit different both from
that of dynahash and simple dshash search functions. One of the most
significant differences is the sequential scan interface of dshash
always needs a call to dshash_seq_term when scan ends. Another is
locking. Dshash holds partition lock when returning an entry,
dshash_seq_next() also holds lock when returning an entry but callers
shouldn't release it, since the lock is essential to continue a
scan. The seqscan interface allows entry deletion while a scan. The
in-scan deletion should be performed by dshash_delete_current().
---
src/backend/lib/dshash.c | 160 ++++++++++++++++++++++++++++++-
src/include/lib/dshash.h | 22 +++++
src/tools/pgindent/typedefs.list | 1 +
3 files changed, 182 insertions(+), 1 deletion(-)
diff --git a/src/backend/lib/dshash.c b/src/backend/lib/dshash.c
index e0c763be32..520bfa0979 100644
--- a/src/backend/lib/dshash.c
+++ b/src/backend/lib/dshash.c
@@ -127,6 +127,10 @@ struct dshash_table
#define NUM_SPLITS(size_log2) \
(size_log2 - DSHASH_NUM_PARTITIONS_LOG2)
+/* How many buckets are there in a given size? */
+#define NUM_BUCKETS(size_log2) \
+ (((size_t) 1) << (size_log2))
+
/* How many buckets are there in each partition at a given size? */
#define BUCKETS_PER_PARTITION(size_log2) \
(((size_t) 1) << NUM_SPLITS(size_log2))
@@ -153,6 +157,10 @@ struct dshash_table
#define BUCKET_INDEX_FOR_PARTITION(partition, size_log2) \
((partition) << NUM_SPLITS(size_log2))
+/* Choose partition based on bucket index. */
+#define PARTITION_FOR_BUCKET_INDEX(bucket_idx, size_log2) \
+ ((bucket_idx) >> NUM_SPLITS(size_log2))
+
/* The head of the active bucket for a given hash value (lvalue). */
#define BUCKET_FOR_HASH(hash_table, hash) \
(hash_table->buckets[ \
@@ -324,7 +332,7 @@ dshash_destroy(dshash_table *hash_table)
ensure_valid_bucket_pointers(hash_table);
/* Free all the entries. */
- size = ((size_t) 1) << hash_table->size_log2;
+ size = NUM_BUCKETS(hash_table->size_log2);
for (i = 0; i < size; ++i)
{
dsa_pointer item_pointer = hash_table->buckets[i];
@@ -592,6 +600,156 @@ dshash_memhash(const void *v, size_t size, void *arg)
return tag_hash(v, size);
}
+/*
+ * dshash_seq_init/_next/_term
+ * Sequentially scan through dshash table and return all the
+ * elements one by one, return NULL when no more.
+ *
+ * dshash_seq_term should always be called when a scan finished.
+ * The caller may delete returned elements midst of a scan by using
+ * dshash_delete_current(). exclusive must be true to delete elements.
+ */
+void
+dshash_seq_init(dshash_seq_status *status, dshash_table *hash_table,
+ bool exclusive)
+{
+ status->hash_table = hash_table;
+ status->curbucket = 0;
+ status->nbuckets = 0;
+ status->curitem = NULL;
+ status->pnextitem = InvalidDsaPointer;
+ status->curpartition = -1;
+ status->exclusive = exclusive;
+}
+
+/*
+ * Returns the next element.
+ *
+ * Returned elements are locked and the caller must not explicitly release
+ * it. It is released at the next call to dshash_next().
+ */
+void *
+dshash_seq_next(dshash_seq_status *status)
+{
+ dsa_pointer next_item_pointer;
+
+ if (status->curitem == NULL)
+ {
+ int partition;
+
+ Assert(status->curbucket == 0);
+ Assert(!status->hash_table->find_locked);
+
+ /* first shot. grab the first item. */
+ partition =
+ PARTITION_FOR_BUCKET_INDEX(status->curbucket,
+ status->hash_table->size_log2);
+ LWLockAcquire(PARTITION_LOCK(status->hash_table, partition),
+ status->exclusive ? LW_EXCLUSIVE : LW_SHARED);
+ status->curpartition = partition;
+
+ /* resize doesn't happen from now until seq scan ends */
+ status->nbuckets =
+ NUM_BUCKETS(status->hash_table->control->size_log2);
+ ensure_valid_bucket_pointers(status->hash_table);
+
+ next_item_pointer = status->hash_table->buckets[status->curbucket];
+ }
+ else
+ next_item_pointer = status->pnextitem;
+
+ Assert(LWLockHeldByMeInMode(PARTITION_LOCK(status->hash_table,
+ status->curpartition),
+ status->exclusive ? LW_EXCLUSIVE : LW_SHARED));
+
+ /* Move to the next bucket if we finished the current bucket */
+ while (!DsaPointerIsValid(next_item_pointer))
+ {
+ int next_partition;
+
+ if (++status->curbucket >= status->nbuckets)
+ {
+ /* all buckets have been scanned. finish. */
+ return NULL;
+ }
+
+ /* Check if move to the next partition */
+ next_partition =
+ PARTITION_FOR_BUCKET_INDEX(status->curbucket,
+ status->hash_table->size_log2);
+
+ if (status->curpartition != next_partition)
+ {
+ /*
+ * Move to the next partition. Lock the next partition then release
+ * the current, not in the reverse order to avoid concurrent
+ * resizing. Avoid dead lock by taking lock in the same order
+ * with resize().
+ */
+ LWLockAcquire(PARTITION_LOCK(status->hash_table,
+ next_partition),
+ status->exclusive ? LW_EXCLUSIVE : LW_SHARED);
+ LWLockRelease(PARTITION_LOCK(status->hash_table,
+ status->curpartition));
+ status->curpartition = next_partition;
+ }
+
+ next_item_pointer = status->hash_table->buckets[status->curbucket];
+ }
+
+ status->curitem =
+ dsa_get_address(status->hash_table->area, next_item_pointer);
+ status->hash_table->find_locked = true;
+ status->hash_table->find_exclusively_locked = status->exclusive;
+
+ /*
+ * The caller may delete the item. Store the next item in case of deletion.
+ */
+ status->pnextitem = status->curitem->next;
+
+ return ENTRY_FROM_ITEM(status->curitem);
+}
+
+/*
+ * Terminates the seqscan and release all locks.
+ *
+ * Should be always called when finishing or exiting a seqscan.
+ */
+void
+dshash_seq_term(dshash_seq_status *status)
+{
+ status->hash_table->find_locked = false;
+ status->hash_table->find_exclusively_locked = false;
+
+ if (status->curpartition >= 0)
+ LWLockRelease(PARTITION_LOCK(status->hash_table, status->curpartition));
+}
+
+/* Remove the current entry while a seq scan. */
+void
+dshash_delete_current(dshash_seq_status *status)
+{
+ dshash_table *hash_table = status->hash_table;
+ dshash_table_item *item = status->curitem;
+ size_t partition = PARTITION_FOR_HASH(item->hash);
+
+ Assert(status->exclusive);
+ Assert(hash_table->control->magic == DSHASH_MAGIC);
+ Assert(hash_table->find_locked);
+ Assert(hash_table->find_exclusively_locked);
+ Assert(LWLockHeldByMeInMode(PARTITION_LOCK(hash_table, partition),
+ LW_EXCLUSIVE));
+
+ delete_item(hash_table, item);
+}
+
+/* Get the current entry while a seq scan. */
+void *
+dshash_get_current(dshash_seq_status *status)
+{
+ return ENTRY_FROM_ITEM(status->curitem);
+}
+
/*
* Print debugging information about the internal state of the hash table to
* stderr. The caller must hold no partition locks.
diff --git a/src/include/lib/dshash.h b/src/include/lib/dshash.h
index c069ec9de7..a6ea377173 100644
--- a/src/include/lib/dshash.h
+++ b/src/include/lib/dshash.h
@@ -59,6 +59,21 @@ typedef struct dshash_parameters
struct dshash_table_item;
typedef struct dshash_table_item dshash_table_item;
+/*
+ * Sequential scan state. The detail is exposed to let users know the storage
+ * size but it should be considered as an opaque type by callers.
+ */
+typedef struct dshash_seq_status
+{
+ dshash_table *hash_table; /* dshash table working on */
+ int curbucket; /* bucket number we are at */
+ int nbuckets; /* total number of buckets in the dshash */
+ dshash_table_item *curitem; /* item we are currently at */
+ dsa_pointer pnextitem; /* dsa-pointer to the next item */
+ int curpartition; /* partition number we are at */
+ bool exclusive; /* locking mode */
+} dshash_seq_status;
+
/* Creating, sharing and destroying from hash tables. */
extern dshash_table *dshash_create(dsa_area *area,
const dshash_parameters *params,
@@ -80,6 +95,13 @@ extern bool dshash_delete_key(dshash_table *hash_table, const void *key);
extern void dshash_delete_entry(dshash_table *hash_table, void *entry);
extern void dshash_release_lock(dshash_table *hash_table, void *entry);
+/* seq scan support */
+extern void dshash_seq_init(dshash_seq_status *status, dshash_table *hash_table,
+ bool exclusive);
+extern void *dshash_seq_next(dshash_seq_status *status);
+extern void dshash_seq_term(dshash_seq_status *status);
+extern void dshash_delete_current(dshash_seq_status *status);
+extern void *dshash_get_current(dshash_seq_status *status);
/* Convenience hash and compare functions wrapping memcmp and tag_hash. */
extern int dshash_memcmp(const void *a, const void *b, size_t size, void *arg);
extern dshash_hash dshash_memhash(const void *v, size_t size, void *arg);
diff --git a/src/tools/pgindent/typedefs.list b/src/tools/pgindent/typedefs.list
index e4d2debb3c..21fd98af66 100644
--- a/src/tools/pgindent/typedefs.list
+++ b/src/tools/pgindent/typedefs.list
@@ -2954,6 +2954,7 @@ dshash_hash
dshash_hash_function
dshash_parameters
dshash_partition
+dshash_seq_status
dshash_table
dshash_table_control
dshash_table_handle
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v52-0002-Add-conditional-lock-feature-to-dshash.patch"
^ permalink raw reply [nested|flat] 10+ messages in thread
* open items
@ 2024-05-09 19:28 Robert Haas <[email protected]>
2024-05-09 19:38 ` Re: open items Dagfinn Ilmari Mannsåker <[email protected]>
2024-05-09 23:10 ` Re: open items Michael Paquier <[email protected]>
2024-05-10 11:14 ` Re: open items Alvaro Herrera <[email protected]>
2024-05-10 12:48 ` Re: open items Melanie Plageman <[email protected]>
0 siblings, 4 replies; 10+ messages in thread
From: Robert Haas @ 2024-05-09 19:28 UTC (permalink / raw)
To: pgsql-hackers
Hi,
Just a few reminders about the open items list at
https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items --
- Please don't add issues to this list unless they are the result of
development done during this release cycle. This is not a
general-purpose bug tracker.
- The owner of an item is the person who committed the patch that
caused the problem, because that committer is responsible for cleaning
up the mess. Of course, the patch author is warmly invited to help,
especially if they have aspirations of being a committer some day
themselves. Other help is welcome, too.
- Fixing the stuff on this list is a time-boxed activity. We want to
put out a release on time. If the stuff listed here doesn't get fixed,
the release management team will have to do something about it, like
start yelling at people, or forcing patches to be reverted, which will
be no fun for anyone involved, including but not limited to the
release management team.
A great number of things that were added as open items have already
been resolved, but some of the remaining items have been there for a
while. Here's a quick review of what's on the list as of this moment:
* Incorrect Assert in heap_end/rescan for BHS. Either the description
of this item is inaccurate, or we've been unable to fix an incorrect
assert after more than a month. I interpret
https://www.postgresql.org/message-id/54858BA1-084E-4F7D-B2D1-D15505E512FF%40yesql.se
as a vote in favor of committing some patch by Melanie to fix this.
Either Tomas should commit that patch, or Melanie should commit that
patch, or somebody should say why that patch shouldn't be committed,
or someone should request more help determining whether that patch is
indeed the correct fix, or something. But let's not just sit on this.
* Register ALPN protocol id with IANA. From the mailing list thread,
it is abundantly clear that IANA is in no hurry to finish dealing with
what seems to be a completely pro forma request from our end. I think
we just have to be patient.
* not null constraints break dump/restore. I asked whether all of the
issues had been addressed here and Justin Pryzby opined that the only
thing that was still relevant for this release was a possible test
case change, which I would personally consider a good enough reason to
at least consider calling this done. But it's not clear to me whether
Justin's opinion is the consensus position, or perhaps more
relevantly, whether it's Álvaro's position.
* Temporal PKs allow duplicates with empty ranges. Peter Eisentraut
has started working with Paul Jungwirth on this. Looks good so far.
* Rename sslnegotiation "requiredirect." option to "directonly". I
still think Heikki has implemented the wrong behavior here, and I
don't think this renaming is going to make any difference one way or
the other in how understandable it is. But if we're going to leave the
behavior as-is and do the renaming, then let's get that done.
* Race condition with local injection point detach. Discussion is ongoing.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: open items
2024-05-09 19:28 open items Robert Haas <[email protected]>
@ 2024-05-09 19:38 ` Dagfinn Ilmari Mannsåker <[email protected]>
2024-05-09 19:39 ` Re: open items Robert Haas <[email protected]>
3 siblings, 1 reply; 10+ messages in thread
From: Dagfinn Ilmari Mannsåker @ 2024-05-09 19:38 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
Robert Haas <[email protected]> writes:
> * Register ALPN protocol id with IANA. From the mailing list thread,
> it is abundantly clear that IANA is in no hurry to finish dealing with
> what seems to be a completely pro forma request from our end. I think
> we just have to be patient.
This appears to have been approved without anyone mentioning it on the
list, and the registry now lists "postgresql" at the bottom:
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protoc...
- ilmari
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: open items
2024-05-09 19:28 open items Robert Haas <[email protected]>
2024-05-09 19:38 ` Re: open items Dagfinn Ilmari Mannsåker <[email protected]>
@ 2024-05-09 19:39 ` Robert Haas <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Robert Haas @ 2024-05-09 19:39 UTC (permalink / raw)
To: Dagfinn Ilmari Mannsåker <[email protected]>; +Cc: pgsql-hackers
On Thu, May 9, 2024 at 3:38 PM Dagfinn Ilmari Mannsåker
<[email protected]> wrote:
> Robert Haas <[email protected]> writes:
> > * Register ALPN protocol id with IANA. From the mailing list thread,
> > it is abundantly clear that IANA is in no hurry to finish dealing with
> > what seems to be a completely pro forma request from our end. I think
> > we just have to be patient.
>
> This appears to have been approved without anyone mentioning it on the
> list, and the registry now lists "postgresql" at the bottom:
>
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protoc...
Nice, thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: open items
2024-05-09 19:28 open items Robert Haas <[email protected]>
@ 2024-05-09 23:10 ` Michael Paquier <[email protected]>
3 siblings, 0 replies; 10+ messages in thread
From: Michael Paquier @ 2024-05-09 23:10 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
On Thu, May 09, 2024 at 03:28:13PM -0400, Robert Haas wrote:
> Just a few reminders about the open items list at
> https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items --
Thanks for summarizing the situation.
> * Race condition with local injection point detach. Discussion is ongoing.
I have sent a patch for that yesterday, which I assume is going in the
right direction to close entirely the loop:
https://www.postgresql.org/message-id/Zjx9-2swyNg6E1y1%40paquier.xyz
There is still one point of detail related to the amount of
flexibility we'd want for detachs (concurrent detach happening in
parallel of an automated one in the shmem callback) that I'm not
entirely sure about yet but I've proposed an idea to solve that as
well. I'm hopeful in getting that wrapped at the beginning of next
week.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: open items
2024-05-09 19:28 open items Robert Haas <[email protected]>
@ 2024-05-10 11:14 ` Alvaro Herrera <[email protected]>
2024-05-10 19:43 ` Re: open items Robert Haas <[email protected]>
3 siblings, 1 reply; 10+ messages in thread
From: Alvaro Herrera @ 2024-05-10 11:14 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
On 2024-May-09, Robert Haas wrote:
> * not null constraints break dump/restore. I asked whether all of the
> issues had been addressed here and Justin Pryzby opined that the only
> thing that was still relevant for this release was a possible test
> case change, which I would personally consider a good enough reason to
> at least consider calling this done. But it's not clear to me whether
> Justin's opinion is the consensus position, or perhaps more
> relevantly, whether it's Álvaro's position.
I have fixed the reported issues, so as far as these specific items go,
we could close the reported open item.
However, in doing so I realized that some code is more complex than it
needs to be, and exposes users to ugliness that they don't need to see,
so I posted additional patches. I intend to get these committed today.
A possible complaint is that the upgrade mechanics which are mostly in
pg_dump with some pieces in pg_upgrade are not very explicitly
documented. There are already comments in all relevant places, but
perhaps an overall picture is necessary. I'll see about this, probably
as a long comment somewhere.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La virtud es el justo medio entre dos defectos" (Aristóteles)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: open items
2024-05-09 19:28 open items Robert Haas <[email protected]>
2024-05-10 11:14 ` Re: open items Alvaro Herrera <[email protected]>
@ 2024-05-10 19:43 ` Robert Haas <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Robert Haas @ 2024-05-10 19:43 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: pgsql-hackers
On Fri, May 10, 2024 at 7:14 AM Alvaro Herrera <[email protected]> wrote:
> A possible complaint is that the upgrade mechanics which are mostly in
> pg_dump with some pieces in pg_upgrade are not very explicitly
> documented. There are already comments in all relevant places, but
> perhaps an overall picture is necessary. I'll see about this, probably
> as a long comment somewhere.
I think that would be really helpful.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: open items
2024-05-09 19:28 open items Robert Haas <[email protected]>
@ 2024-05-10 12:48 ` Melanie Plageman <[email protected]>
2024-05-10 13:28 ` Re: open items Daniel Gustafsson <[email protected]>
2024-05-10 19:43 ` Re: open items Robert Haas <[email protected]>
3 siblings, 2 replies; 10+ messages in thread
From: Melanie Plageman @ 2024-05-10 12:48 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
On Thu, May 9, 2024 at 3:28 PM Robert Haas <[email protected]> wrote:
>
> Just a few reminders about the open items list at
> https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items --
>
> * Incorrect Assert in heap_end/rescan for BHS. Either the description
> of this item is inaccurate, or we've been unable to fix an incorrect
> assert after more than a month. I interpret
> https://www.postgresql.org/message-id/54858BA1-084E-4F7D-B2D1-D15505E512FF%40yesql.se
> as a vote in favor of committing some patch by Melanie to fix this.
> Either Tomas should commit that patch, or Melanie should commit that
> patch, or somebody should say why that patch shouldn't be committed,
> or someone should request more help determining whether that patch is
> indeed the correct fix, or something. But let's not just sit on this.
Sorry, yes, the trivial fix has been done for a while. There is one
outstanding feedback on the patch: an update to one of the comments
suggested by Tomas. I got distracted by trying to repro and fix a bug
from the section "live issues affecting stable branches". I will
update this BHS patch by tonight and commit it once Tomas has a chance
to +1.
Thanks,
Melanie
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: open items
2024-05-09 19:28 open items Robert Haas <[email protected]>
2024-05-10 12:48 ` Re: open items Melanie Plageman <[email protected]>
@ 2024-05-10 13:28 ` Daniel Gustafsson <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Daniel Gustafsson @ 2024-05-10 13:28 UTC (permalink / raw)
To: Melanie Plageman <[email protected]>; +Cc: Robert Haas <[email protected]>; pgsql-hackers
> On 10 May 2024, at 14:48, Melanie Plageman <[email protected]> wrote:
>
> On Thu, May 9, 2024 at 3:28 PM Robert Haas <[email protected]> wrote:
>>
>> Just a few reminders about the open items list at
>> https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items --
>>
>> * Incorrect Assert in heap_end/rescan for BHS. Either the description
>> of this item is inaccurate, or we've been unable to fix an incorrect
>> assert after more than a month. I interpret
>> https://www.postgresql.org/message-id/54858BA1-084E-4F7D-B2D1-D15505E512FF%40yesql.se
>> as a vote in favor of committing some patch by Melanie to fix this.
It's indeed a vote for that.
>> Either Tomas should commit that patch, or Melanie should commit that
>> patch, or somebody should say why that patch shouldn't be committed,
>> or someone should request more help determining whether that patch is
>> indeed the correct fix, or something. But let's not just sit on this.
>
> Sorry, yes, the trivial fix has been done for a while. There is one
> outstanding feedback on the patch: an update to one of the comments
> suggested by Tomas. I got distracted by trying to repro and fix a bug
> from the section "live issues affecting stable branches". I will
> update this BHS patch by tonight and commit it once Tomas has a chance
> to +1.
+1
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: open items
2024-05-09 19:28 open items Robert Haas <[email protected]>
2024-05-10 12:48 ` Re: open items Melanie Plageman <[email protected]>
@ 2024-05-10 19:43 ` Robert Haas <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Robert Haas @ 2024-05-10 19:43 UTC (permalink / raw)
To: Melanie Plageman <[email protected]>; +Cc: pgsql-hackers
On Fri, May 10, 2024 at 8:48 AM Melanie Plageman
<[email protected]> wrote:
> Sorry, yes, the trivial fix has been done for a while. There is one
> outstanding feedback on the patch: an update to one of the comments
> suggested by Tomas. I got distracted by trying to repro and fix a bug
> from the section "live issues affecting stable branches". I will
> update this BHS patch by tonight and commit it once Tomas has a chance
> to +1.
Great, thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2024-05-10 19:43 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-03-13 07:58 [PATCH v52 1/7] sequential scan for dshash Kyotaro Horiguchi <[email protected]>
2024-05-09 19:28 open items Robert Haas <[email protected]>
2024-05-09 19:38 ` Re: open items Dagfinn Ilmari Mannsåker <[email protected]>
2024-05-09 19:39 ` Re: open items Robert Haas <[email protected]>
2024-05-09 23:10 ` Re: open items Michael Paquier <[email protected]>
2024-05-10 11:14 ` Re: open items Alvaro Herrera <[email protected]>
2024-05-10 19:43 ` Re: open items Robert Haas <[email protected]>
2024-05-10 12:48 ` Re: open items Melanie Plageman <[email protected]>
2024-05-10 13:28 ` Re: open items Daniel Gustafsson <[email protected]>
2024-05-10 19:43 ` Re: open items Robert Haas <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox