public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v9 10/17] table_scan_bitmap_next_block counts lossy and exact pages
27+ messages / 8 participants
[nested] [flat]
* [PATCH v9 10/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 2ad785e511..266b34fe6b 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2114,7 +2114,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2267,7 +2268,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index 7e73583fe5..96b55507a3 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -69,7 +69,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -267,14 +266,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index a820cc8c99..1d4b79a73f 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -797,8 +797,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -815,8 +815,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -2013,15 +2015,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2032,7 +2036,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--7mdtsjmrzitrgzgx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v9-0011-Hard-code-TBMIterateResult-offsets-array-size.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH v10 11/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index c76849a98e..d85fee1e50 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2114,7 +2114,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2264,7 +2265,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index fe471a8a0c..076e1ff674 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -119,7 +119,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -298,14 +297,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index 29387166c1..edc54ecffe 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -797,8 +797,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -815,8 +815,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -1994,15 +1996,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2013,7 +2017,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--3o7pc6dfau5a5hry
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v10-0012-Hard-code-TBMIterateResult-offsets-array-size.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH v10 11/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index c76849a98e..d85fee1e50 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2114,7 +2114,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2264,7 +2265,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index fe471a8a0c..076e1ff674 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -119,7 +119,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -298,14 +297,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index 29387166c1..edc54ecffe 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -797,8 +797,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -815,8 +815,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -1994,15 +1996,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2013,7 +2017,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--3o7pc6dfau5a5hry
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v10-0012-Hard-code-TBMIterateResult-offsets-array-size.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH v12 11/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 38c4fd5011c..46f1a374252 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2199,7 +2199,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2349,7 +2350,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index 8b6f22bc3b6..fb79f57d7a6 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -119,7 +119,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -298,14 +297,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index 592a8421bdf..a06ed271eb6 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -804,8 +804,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -822,8 +822,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -2019,15 +2021,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2038,7 +2042,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--6jpz2j246qmht4bt
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v12-0012-Hard-code-TBMIterateResult-offsets-array-size.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH v8 11/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 2ad785e511..266b34fe6b 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2114,7 +2114,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2267,7 +2268,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index 7e73583fe5..96b55507a3 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -69,7 +69,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -267,14 +266,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index a820cc8c99..1d4b79a73f 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -797,8 +797,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -815,8 +815,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -2013,15 +2015,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2032,7 +2036,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--xqq4defy3uncu6k6
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v8-0012-Separate-TBM-Shared-Iterator-and-TBMIterateResult.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH v9 10/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 2ad785e511..266b34fe6b 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2114,7 +2114,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2267,7 +2268,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index 7e73583fe5..96b55507a3 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -69,7 +69,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -267,14 +266,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index a820cc8c99..1d4b79a73f 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -797,8 +797,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -815,8 +815,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -2013,15 +2015,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2032,7 +2036,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--7mdtsjmrzitrgzgx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v9-0011-Hard-code-TBMIterateResult-offsets-array-size.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH v8 11/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 2ad785e511..266b34fe6b 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2114,7 +2114,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2267,7 +2268,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index 7e73583fe5..96b55507a3 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -69,7 +69,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -267,14 +266,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index a820cc8c99..1d4b79a73f 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -797,8 +797,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -815,8 +815,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -2013,15 +2015,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2032,7 +2036,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--xqq4defy3uncu6k6
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v8-0012-Separate-TBM-Shared-Iterator-and-TBMIterateResult.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH v11 11/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 2d9e0e1a9f..81a7488007 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2172,7 +2172,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2322,7 +2323,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index fe471a8a0c..076e1ff674 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -119,7 +119,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -298,14 +297,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index 459e123e92..bb2b79717c 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -808,8 +808,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -826,8 +826,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -2029,15 +2031,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2048,7 +2052,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--owzzsiozz6hgpp7e
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v11-0012-Hard-code-TBMIterateResult-offsets-array-size.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH v9 10/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 2ad785e511..266b34fe6b 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2114,7 +2114,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2267,7 +2268,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index 7e73583fe5..96b55507a3 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -69,7 +69,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -267,14 +266,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index a820cc8c99..1d4b79a73f 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -797,8 +797,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -815,8 +815,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -2013,15 +2015,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2032,7 +2036,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--7mdtsjmrzitrgzgx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v9-0011-Hard-code-TBMIterateResult-offsets-array-size.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH v8 11/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 2ad785e511..266b34fe6b 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2114,7 +2114,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2267,7 +2268,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index 7e73583fe5..96b55507a3 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -69,7 +69,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -267,14 +266,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index a820cc8c99..1d4b79a73f 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -797,8 +797,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -815,8 +815,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -2013,15 +2015,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2032,7 +2036,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--xqq4defy3uncu6k6
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v8-0012-Separate-TBM-Shared-Iterator-and-TBMIterateResult.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH v11 11/17] table_scan_bitmap_next_block counts lossy and exact pages
@ 2024-03-22 21:09 Melanie Plageman <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Melanie Plageman @ 2024-03-22 21:09 UTC (permalink / raw)
Now that the table_scan_bitmap_next_block() callback only returns false
when the bitmap is exhausted, it is simpler to move the management of
the lossy and exact page counters into it. We will eventually remove
this callback and table_scan_bitmap_next_tuple() will update those
counters when a new block is read in.
---
src/backend/access/heap/heapam_handler.c | 8 ++++++--
src/backend/executor/nodeBitmapHeapscan.c | 9 ++-------
src/include/access/tableam.h | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 2d9e0e1a9f..81a7488007 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2172,7 +2172,8 @@ heapam_estimate_rel_size(Relation rel, int32 *attr_widths,
static bool
heapam_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
HeapScanDesc hscan = (HeapScanDesc) scan;
BlockNumber block;
@@ -2322,7 +2323,10 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
Assert(ntup <= MaxHeapTuplesPerPage);
hscan->rs_ntuples = ntup;
- *lossy = tbmres->ntuples < 0;
+ if (tbmres->ntuples < 0)
+ (*lossy_pages)++;
+ else
+ (*exact_pages)++;
/*
* Return true to indicate that a valid block was found and the bitmap is
diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c
index fe471a8a0c..076e1ff674 100644
--- a/src/backend/executor/nodeBitmapHeapscan.c
+++ b/src/backend/executor/nodeBitmapHeapscan.c
@@ -119,7 +119,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
{
ExprContext *econtext;
TableScanDesc scan;
- bool lossy;
TIDBitmap *tbm;
TupleTableSlot *slot;
ParallelBitmapHeapState *pstate = node->pstate;
@@ -298,14 +297,10 @@ new_page:
BitmapAdjustPrefetchIterator(node);
- if (!table_scan_bitmap_next_block(scan, &node->recheck, &lossy, &node->blockno))
+ if (!table_scan_bitmap_next_block(scan, &node->recheck, &node->blockno,
+ &node->lossy_pages, &node->exact_pages))
break;
- if (lossy)
- node->lossy_pages++;
- else
- node->exact_pages++;
-
/*
* If serial, we can error out if the the prefetch block doesn't stay
* ahead of the current block.
diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h
index 459e123e92..bb2b79717c 100644
--- a/src/include/access/tableam.h
+++ b/src/include/access/tableam.h
@@ -808,8 +808,8 @@ typedef struct TableAmRoutine
* work to allow scan_bitmap_next_tuple() to return tuples (e.g. it might
* make sense to perform tuple visibility checks at this time).
*
- * lossy indicates whether or not the block's representation in the bitmap
- * is lossy or exact.
+ * lossy_pages is incremented if the block's representation in the bitmap
+ * is lossy, otherwise, exact_pages is incremented.
*
* XXX: Currently this may only be implemented if the AM uses md.c as its
* storage manager, and uses ItemPointer->ip_blkid in a manner that maps
@@ -826,8 +826,10 @@ typedef struct TableAmRoutine
* scan_bitmap_next_tuple need to exist, or neither.
*/
bool (*scan_bitmap_next_block) (TableScanDesc scan,
- bool *recheck, bool *lossy,
- BlockNumber *blockno);
+ bool *recheck,
+ BlockNumber *blockno,
+ long *lossy_pages,
+ long *exact_pages);
/*
* Fetch the next tuple of a bitmap table scan into `slot` and return true
@@ -2029,15 +2031,17 @@ table_relation_estimate_size(Relation rel, int32 *attr_widths,
/*
* Prepare to fetch / check / return tuples as part of a bitmap table scan.
* `scan` needs to have been started via table_beginscan_bm(). Returns false if
- * there are no more blocks in the bitmap, true otherwise. lossy is set to true
- * if bitmap is lossy for the selected block and false otherwise.
+ * there are no more blocks in the bitmap, true otherwise. lossy_pages is
+ * incremented if bitmap is lossy for the selected block and exact_pages is
+ * incremented otherwise.
*
* Note, this is an optionally implemented function, therefore should only be
* used after verifying the presence (at plan time or such).
*/
static inline bool
table_scan_bitmap_next_block(TableScanDesc scan,
- bool *recheck, bool *lossy, BlockNumber *blockno)
+ bool *recheck, BlockNumber *blockno,
+ long *lossy_pages, long *exact_pages)
{
/*
* We don't expect direct calls to table_scan_bitmap_next_block with valid
@@ -2048,7 +2052,8 @@ table_scan_bitmap_next_block(TableScanDesc scan,
elog(ERROR, "unexpected table_scan_bitmap_next_block call during logical decoding");
return scan->rs_rd->rd_tableam->scan_bitmap_next_block(scan, recheck,
- lossy, blockno);
+ blockno, lossy_pages,
+ exact_pages);
}
/*
--
2.40.1
--owzzsiozz6hgpp7e
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v11-0012-Hard-code-TBMIterateResult-offsets-array-size.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* doc: pgevent.dll location
@ 2024-11-05 03:02 Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
0 siblings, 1 reply; 27+ messages in thread
From: Ryohei Takahashi (Fujitsu) @ 2024-11-05 03:02 UTC (permalink / raw)
To: [email protected] <[email protected]>
Hi,
PostgreSQL 17.0 Documentation teach us to run the following command.
regsvr32 pgsql_library_directory/pgevent.dll
On the other hand, pgevent.dll is moved from lib/ directory to bin/directory on PG 17.0
(It seems that it is moved because of meson)
So, I think the documentation need to be updated like attached.
How do you think about this?
Regards,
Ryohei Takahashi
Attachments:
[application/octet-stream] 001-doc-pgevent.patch (1.7K, ../../TY3PR01MB118912125614599641CA881B782522@TY3PR01MB11891.jpnprd01.prod.outlook.com/3-001-doc-pgevent.patch)
download | inline diff:
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index bcd81e24158..6ead53b6dbb 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -2723,7 +2723,7 @@ ssh -L 63333:db.foo.com:5432 [email protected]
<application>event log</application> library with the operating system,
issue this command:
<screen>
-<userinput>regsvr32 <replaceable>pgsql_library_directory</replaceable>/pgevent.dll</userinput>
+<userinput>regsvr32 <replaceable>pgsql_bin_directory</replaceable>/pgevent.dll</userinput>
</screen>
This creates registry entries used by the event viewer, under the default
event source named <literal>PostgreSQL</literal>.
@@ -2734,7 +2734,7 @@ ssh -L 63333:db.foo.com:5432 [email protected]
<xref linkend="guc-event-source"/>), use the <literal>/n</literal>
and <literal>/i</literal> options:
<screen>
-<userinput>regsvr32 /n /i:<replaceable>event_source_name</replaceable> <replaceable>pgsql_library_directory</replaceable>/pgevent.dll</userinput>
+<userinput>regsvr32 /n /i:<replaceable>event_source_name</replaceable> <replaceable>pgsql_bin_directory</replaceable>/pgevent.dll</userinput>
</screen>
</para>
@@ -2742,7 +2742,7 @@ ssh -L 63333:db.foo.com:5432 [email protected]
To unregister the <application>event log</application> library from
the operating system, issue this command:
<screen>
-<userinput>regsvr32 /u [/i:<replaceable>event_source_name</replaceable>] <replaceable>pgsql_library_directory</replaceable>/pgevent.dll</userinput>
+<userinput>regsvr32 /u [/i:<replaceable>event_source_name</replaceable>] <replaceable>pgsql_bin_directory</replaceable>/pgevent.dll</userinput>
</screen>
</para>
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
@ 2024-11-05 06:00 ` Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
0 siblings, 1 reply; 27+ messages in thread
From: Gurjeet Singh @ 2024-11-05 06:00 UTC (permalink / raw)
To: Ryohei Takahashi (Fujitsu) <[email protected]>; +Cc: [email protected] <[email protected]>
On Mon, Nov 4, 2024 at 7:02 PM Ryohei Takahashi (Fujitsu)
<[email protected]> wrote:
>
> On the other hand, pgevent.dll is moved from lib/ directory to bin/directory on PG 17.0
>
> (It seems that it is moved because of meson)
>
> So, I think the documentation need to be updated like attached.
I'm unable to confirm the veracity of the claim that the pgevent.dll
file on Windows is now placed in a different directory, and that this
is a result of meson builds. But the patch looks good to me; it
applies cleanly to REL_17_STABLE and main branches.
Best regards,
Gurjeet
http://Gurje.et
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
@ 2024-11-05 15:09 ` Robert Haas <[email protected]>
2024-11-05 15:15 ` Re: doc: pgevent.dll location Tom Lane <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
0 siblings, 2 replies; 27+ messages in thread
From: Robert Haas @ 2024-11-05 15:09 UTC (permalink / raw)
To: Gurjeet Singh <[email protected]>; +Cc: Ryohei Takahashi (Fujitsu) <[email protected]>; [email protected] <[email protected]>
On Tue, Nov 5, 2024 at 1:00 AM Gurjeet Singh <[email protected]> wrote:
> I'm unable to confirm the veracity of the claim that the pgevent.dll
> file on Windows is now placed in a different directory, and that this
> is a result of meson builds. But the patch looks good to me; it
> applies cleanly to REL_17_STABLE and main branches.
I think we will need to find someone who can confirm whether or not
the claim is correct.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
@ 2024-11-05 15:15 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 27+ messages in thread
From: Tom Lane @ 2024-11-05 15:15 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Gurjeet Singh <[email protected]>; Ryohei Takahashi (Fujitsu) <[email protected]>; [email protected] <[email protected]>
Robert Haas <[email protected]> writes:
> On Tue, Nov 5, 2024 at 1:00 AM Gurjeet Singh <[email protected]> wrote:
>> I'm unable to confirm the veracity of the claim that the pgevent.dll
>> file on Windows is now placed in a different directory, and that this
>> is a result of meson builds. But the patch looks good to me; it
>> applies cleanly to REL_17_STABLE and main branches.
> I think we will need to find someone who can confirm whether or not
> the claim is correct.
More to the point: if that does happen, isn't it a bug to be fixed
rather than documented?
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
@ 2024-11-05 15:27 ` Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
1 sibling, 1 reply; 27+ messages in thread
From: Dave Page @ 2024-11-05 15:27 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Gurjeet Singh <[email protected]>; Ryohei Takahashi (Fujitsu) <[email protected]>; [email protected] <[email protected]>
On Tue, 5 Nov 2024 at 15:10, Robert Haas <[email protected]> wrote:
> On Tue, Nov 5, 2024 at 1:00 AM Gurjeet Singh <[email protected]> wrote:
> > I'm unable to confirm the veracity of the claim that the pgevent.dll
> > file on Windows is now placed in a different directory, and that this
> > is a result of meson builds. But the patch looks good to me; it
> > applies cleanly to REL_17_STABLE and main branches.
>
> I think we will need to find someone who can confirm whether or not
> the claim is correct.
>
It is correct. In v16, it was in lib/, in v17, bin/.
However, on Windows I think it probably makes (marginally) more sense to
include it in bin/ - we already have other libraries in there that are
linked at compile time. pgevent is something of a special case, but it's
probably more similar to those libraries than the extensions etc. that are
in lib/.
Related sidenote: I got a complaint today that pg_regress.exe is no longer
part of the Windows installation footprint - and indeed, it's not installed
at all with Meson builds, which is problematic for those doing CI/CD
testing of extensions.
--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
^ permalink raw reply [nested|flat] 27+ messages in thread
* RE: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
@ 2024-11-06 12:57 ` Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 27+ messages in thread
From: Ryohei Takahashi (Fujitsu) @ 2024-11-06 12:57 UTC (permalink / raw)
To: 'Dave Page' <[email protected]>; Robert Haas <[email protected]>; +Cc: Gurjeet Singh <[email protected]>; [email protected] <[email protected]>
Hi,
Thank you for your reply.
The dll install paths are changed as follows on Windows.
(1) pgevent.dll
PG16: lib/
PG17: bin/
(2) dll for user (like libpq.dll, libecpg.dll)
PG16: Both in lib/ and bin/
PG17: bin/
(3) contrib dll (like amcheck.dll)
PG16: lib/
PG17: lib/
I understand that Dave says (1) and (2) should exist on bin/ directory
and the paths in PG17 are correct.
So, I think it is correct to update documentation.
Regards,
Ryohei Takahashi
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
@ 2024-11-06 16:11 ` Peter Eisentraut <[email protected]>
2024-11-07 08:16 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-12 16:02 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
0 siblings, 2 replies; 27+ messages in thread
From: Peter Eisentraut @ 2024-11-06 16:11 UTC (permalink / raw)
To: Ryohei Takahashi (Fujitsu) <[email protected]>; 'Dave Page' <[email protected]>; Robert Haas <[email protected]>; +Cc: Gurjeet Singh <[email protected]>; [email protected] <[email protected]>
On 06.11.24 13:57, Ryohei Takahashi (Fujitsu) wrote:
> The dll install paths are changed as follows on Windows.
>
> (1) pgevent.dll
> PG16: lib/
> PG17: bin/
>
> (2) dll for user (like libpq.dll, libecpg.dll)
> PG16: Both in lib/ and bin/
> PG17: bin/
>
> (3) contrib dll (like amcheck.dll)
> PG16: lib/
> PG17: lib/
>
>
> I understand that Dave says (1) and (2) should exist on bin/ directory
> and the paths in PG17 are correct.
>
> So, I think it is correct to update documentation.
I don't have Windows handy to test it out, but looking at the respective
build system source files, in master, pgevent is built and installed
like a normal shared library in both meson.build and Makefile, so it
should end up somewhere in lib.
In src/tools/msvc in REL_16_STABLE, I see some code that appears to
suggest that it installs in bin.
Again, this is just reading the code, but it seems to be backwards from
what is claimed earlier.
The statements like "in PGxxx it did this" are not precise enough
because there are three possible build systems. We need to know what
each build system is doing. Also, the consideration of consistency
should go in two dimensions: Consistency between versions and
consistency between build systems.
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
@ 2024-11-07 08:16 ` Dave Page <[email protected]>
2024-11-11 11:11 ` Re: doc: pgevent.dll location Amit Kapila <[email protected]>
1 sibling, 1 reply; 27+ messages in thread
From: Dave Page @ 2024-11-07 08:16 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Ryohei Takahashi (Fujitsu) <[email protected]>; Robert Haas <[email protected]>; Gurjeet Singh <[email protected]>; [email protected] <[email protected]>
Hi
On Wed, 6 Nov 2024 at 16:11, Peter Eisentraut <[email protected]> wrote:
> On 06.11.24 13:57, Ryohei Takahashi (Fujitsu) wrote:
> > The dll install paths are changed as follows on Windows.
> >
> > (1) pgevent.dll
> > PG16: lib/
> > PG17: bin/
> >
> > (2) dll for user (like libpq.dll, libecpg.dll)
> > PG16: Both in lib/ and bin/
> > PG17: bin/
> >
> > (3) contrib dll (like amcheck.dll)
> > PG16: lib/
> > PG17: lib/
> >
> >
> > I understand that Dave says (1) and (2) should exist on bin/ directory
> > and the paths in PG17 are correct.
> >
> > So, I think it is correct to update documentation.
>
> I don't have Windows handy to test it out, but looking at the respective
> build system source files, in master, pgevent is built and installed
> like a normal shared library in both meson.build and Makefile, so it
> should end up somewhere in lib.
>
> In src/tools/msvc in REL_16_STABLE, I see some code that appears to
> suggest that it installs in bin.
>
> Again, this is just reading the code, but it seems to be backwards from
> what is claimed earlier.
I downloaded the builds of v16 and v17 from
https://github.com/dpage/winpgbuild/actions/runs/11639786998, a project
worked on by Andres, Dave Cramer, and myself.
I've just double-checked I didn't get mixed up, and can confirm that in
v17, pgevent.dll is installed into bin/ and in v16.4, it's in lib/
>
> The statements like "in PGxxx it did this" are not precise enough
> because there are three possible build systems. We need to know what
> each build system is doing. Also, the consideration of consistency
> should go in two dimensions: Consistency between versions and
> consistency between build systems.
>
Yeah, sorry - I tend not to even think about Cygwin or Msys builds as they
haven't been used for "official" builds on Windows in many, many years.
The builds I'm testing are MSVC++ using the old perl based build system for
v16, and MSVC++ using Meson for v17. You can see exactly how they're done
in the Github Action script for the action run above.
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-07 08:16 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
@ 2024-11-11 11:11 ` Amit Kapila <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Amit Kapila @ 2024-11-11 11:11 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Ryohei Takahashi (Fujitsu) <[email protected]>; Robert Haas <[email protected]>; Gurjeet Singh <[email protected]>; [email protected] <[email protected]>
On Thu, Nov 7, 2024 at 1:46 PM Dave Page <[email protected]> wrote:
>
> Hi
>
> On Wed, 6 Nov 2024 at 16:11, Peter Eisentraut <[email protected]> wrote:
>>
>> On 06.11.24 13:57, Ryohei Takahashi (Fujitsu) wrote:
>> > The dll install paths are changed as follows on Windows.
>> >
>> > (1) pgevent.dll
>> > PG16: lib/
>> > PG17: bin/
>> >
>> > (2) dll for user (like libpq.dll, libecpg.dll)
>> > PG16: Both in lib/ and bin/
>> > PG17: bin/
>> >
>> > (3) contrib dll (like amcheck.dll)
>> > PG16: lib/
>> > PG17: lib/
>> >
>> >
>> > I understand that Dave says (1) and (2) should exist on bin/ directory
>> > and the paths in PG17 are correct.
>> >
>> > So, I think it is correct to update documentation.
>>
>> I don't have Windows handy to test it out, but looking at the respective
>> build system source files, in master, pgevent is built and installed
>> like a normal shared library in both meson.build and Makefile, so it
>> should end up somewhere in lib.
>>
>> In src/tools/msvc in REL_16_STABLE, I see some code that appears to
>> suggest that it installs in bin.
>>
>> Again, this is just reading the code, but it seems to be backwards from
>> what is claimed earlier.
>
>
> I downloaded the builds of v16 and v17 from
> https://github.com/dpage/winpgbuild/actions/runs/11639786998, a project worked on by Andres, Dave Cramer, and myself.
>
> I've just double-checked I didn't get mixed up, and can confirm that in v17, pgevent.dll is installed into bin/ and in v16.4, it's in lib/
>
I can re-confirm that on my Windows setup, pgevent.dll is present in
bin/ for PG17 and HEAD and in lib/ for PG16.
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
@ 2024-11-12 16:02 ` Robert Haas <[email protected]>
2024-11-12 16:52 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
1 sibling, 1 reply; 27+ messages in thread
From: Robert Haas @ 2024-11-12 16:02 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Ryohei Takahashi (Fujitsu) <[email protected]>; Dave Page <[email protected]>; Gurjeet Singh <[email protected]>; [email protected] <[email protected]>
On Wed, Nov 6, 2024 at 11:11 AM Peter Eisentraut <[email protected]> wrote:
> I don't have Windows handy to test it out, but looking at the respective
> build system source files, in master, pgevent is built and installed
> like a normal shared library in both meson.build and Makefile, so it
> should end up somewhere in lib.
>
> In src/tools/msvc in REL_16_STABLE, I see some code that appears to
> suggest that it installs in bin.
>
> Again, this is just reading the code, but it seems to be backwards from
> what is claimed earlier.
>
> The statements like "in PGxxx it did this" are not precise enough
> because there are three possible build systems. We need to know what
> each build system is doing. Also, the consideration of consistency
> should go in two dimensions: Consistency between versions and
> consistency between build systems.
To what three systems are you referring? I thought we now only
supported building with meson on Windows, and this is a
Windows-specific file. Everyone seems to be saying the file has moved
in v17, so it seems like we should either move it back or update the
documentation as proposed. The question of why it has moved is perhaps
worth some investigation, but seems like a secondary issue.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-12 16:02 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
@ 2024-11-12 16:52 ` Peter Eisentraut <[email protected]>
2024-11-12 17:27 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-13 08:53 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
0 siblings, 2 replies; 27+ messages in thread
From: Peter Eisentraut @ 2024-11-12 16:52 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Ryohei Takahashi (Fujitsu) <[email protected]>; Dave Page <[email protected]>; Gurjeet Singh <[email protected]>; [email protected] <[email protected]>
On 12.11.24 17:02, Robert Haas wrote:
> On Wed, Nov 6, 2024 at 11:11 AM Peter Eisentraut <[email protected]> wrote:
>> I don't have Windows handy to test it out, but looking at the respective
>> build system source files, in master, pgevent is built and installed
>> like a normal shared library in both meson.build and Makefile, so it
>> should end up somewhere in lib.
>>
>> In src/tools/msvc in REL_16_STABLE, I see some code that appears to
>> suggest that it installs in bin.
>>
>> Again, this is just reading the code, but it seems to be backwards from
>> what is claimed earlier.
>>
>> The statements like "in PGxxx it did this" are not precise enough
>> because there are three possible build systems. We need to know what
>> each build system is doing. Also, the consideration of consistency
>> should go in two dimensions: Consistency between versions and
>> consistency between build systems.
>
> To what three systems are you referring? I thought we now only
> supported building with meson on Windows, and this is a
> Windows-specific file. Everyone seems to be saying the file has moved
> in v17, so it seems like we should either move it back or update the
> documentation as proposed. The question of why it has moved is perhaps
> worth some investigation, but seems like a secondary issue.
The three possible build systems are:
1. src/tools/msvc/
2. meson
3. make
The first one was removed, but the second and the third one still exist.
I can tell from the build farm logs (fairywren) that on master with
meson the installation layout is
Installing src\\bin\\pgevent\\pgevent.dll to
C:/tools/xmsys64/home/pgrunner/bf/root/HEAD/inst\\bin
Installing src\\bin\\pgevent\\pgevent.dll.a to
C:/tools/xmsys64/home/pgrunner/bf/root/HEAD/inst\\lib
This appears to be the meson default for shared libraries, because we
also have
Installing src/interfaces/libpq\\libpq.dll to
C:/tools/xmsys64/home/pgrunner/bf/root/HEAD/inst\\bin
Installing src/interfaces/libpq\\libpq.dll.a to
C:/tools/xmsys64/home/pgrunner/bf/root/HEAD/inst\\lib
We don't have any coverage on master for make on Windows, but I can see
on REL_15_STABLE (fairywren)
/usr/bin/install -c -m 755 pgevent.dll
'/home/pgrunner/bf/root/REL_15_STABLE/inst/lib/postgresql/pgevent.dll'
and I strongly suspect that this is unchanged in master.
Note here that meson installs this file as a shared library (like libpq)
but make installs this file as a shared module (like plpgsql).
Also, looking at the source code of the old msvc build system
(Install.pm, sub CopySolutionOutput), it will install this file into lib
in the logic that is is a "dll" file that is *not* a shared library (has
no SO_MAJOR_VERSION set). So the msvc system appears to be consistent
with the make system in that respect.
So the most straightforward way to "make it work like it used to" would
be to change src/bin/pgevent/meson.build to use shared_module() instead
of shared_library().
Based on the explanation in the documentation, this file is really more
of a plugin and less a shared library, so I think that approach would be
more correct than not.
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-12 16:02 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-12 16:52 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
@ 2024-11-12 17:27 ` Robert Haas <[email protected]>
1 sibling, 0 replies; 27+ messages in thread
From: Robert Haas @ 2024-11-12 17:27 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Ryohei Takahashi (Fujitsu) <[email protected]>; Dave Page <[email protected]>; Gurjeet Singh <[email protected]>; [email protected] <[email protected]>
On Tue, Nov 12, 2024 at 11:52 AM Peter Eisentraut <[email protected]> wrote:
> So the most straightforward way to "make it work like it used to" would
> be to change src/bin/pgevent/meson.build to use shared_module() instead
> of shared_library().
>
> Based on the explanation in the documentation, this file is really more
> of a plugin and less a shared library, so I think that approach would be
> more correct than not.
I don't understand what the difference is between a shared module and
a shared library, so I find it odd that meson treats them differently.
However, if the consensus is that moving it back to lib is better than
updating the documentation, that's fine with me.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-12 16:02 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-12 16:52 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
@ 2024-11-13 08:53 ` Peter Eisentraut <[email protected]>
2024-11-15 13:53 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
1 sibling, 1 reply; 27+ messages in thread
From: Peter Eisentraut @ 2024-11-13 08:53 UTC (permalink / raw)
To: [email protected] <[email protected]>; +Cc: Robert Haas <[email protected]>; Ryohei Takahashi (Fujitsu) <[email protected]>; Dave Page <[email protected]>; Gurjeet Singh <[email protected]>
On 12.11.24 17:52, Peter Eisentraut wrote:
> So the most straightforward way to "make it work like it used to" would
> be to change src/bin/pgevent/meson.build to use shared_module() instead
> of shared_library().
I developed the attached patch for this.
I haven't tested it locally, but I checked in the CI logs that the build
commands for pgevent don't change with this. CI doesn't test meson
install, it seems, so can't actually tell whether this changes the
installation directory successfully, but I think it should work.
Someone with Windows handy please give this a test.
From 064013af8020112b5ee96538e9bf928c623b74e0 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <[email protected]>
Date: Wed, 13 Nov 2024 09:49:25 +0100
Subject: [PATCH] meson: Build pgevent as shared_module rather than
shared_library
This matches the behavior of the makefiles and the old MSVC build
system. The main effect is that the build result gets installed into
pkglibdir rather than bindir. The documentation says to locate the
library in pkglibdir, so this makes the code match the documentation
again.
Reported-by: Ryohei Takahashi (Fujitsu) <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/TY3PR01MB118912125614599641CA881B782522%40TY3PR01MB11891....
ci-os-only: windows
---
src/bin/pgevent/meson.build | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/bin/pgevent/meson.build b/src/bin/pgevent/meson.build
index 5c2d296fef9..f7422438664 100644
--- a/src/bin/pgevent/meson.build
+++ b/src/bin/pgevent/meson.build
@@ -21,13 +21,11 @@ if cc.get_id() == 'msvc'
pgevent_link_args += '/ignore:4104'
endif
-pgevent = shared_library('pgevent',
+pgevent = shared_module('pgevent',
pgevent_sources,
dependencies: [frontend_code],
link_args: pgevent_link_args,
vs_module_defs: 'pgevent.def',
- kwargs: default_lib_args + {
- 'name_prefix': '',
- },
+ kwargs: default_mod_args,
)
bin_targets += pgevent
--
2.47.0
Attachments:
[text/plain] 0001-meson-Build-pgevent-as-shared_module-rather-than-sha.patch (1.4K, ../../[email protected]/2-0001-meson-Build-pgevent-as-shared_module-rather-than-sha.patch)
download | inline diff:
From 064013af8020112b5ee96538e9bf928c623b74e0 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <[email protected]>
Date: Wed, 13 Nov 2024 09:49:25 +0100
Subject: [PATCH] meson: Build pgevent as shared_module rather than
shared_library
This matches the behavior of the makefiles and the old MSVC build
system. The main effect is that the build result gets installed into
pkglibdir rather than bindir. The documentation says to locate the
library in pkglibdir, so this makes the code match the documentation
again.
Reported-by: Ryohei Takahashi (Fujitsu) <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/TY3PR01MB118912125614599641CA881B782522%40TY3PR01MB11891.jpnprd01.prod.outlook.com
ci-os-only: windows
---
src/bin/pgevent/meson.build | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/bin/pgevent/meson.build b/src/bin/pgevent/meson.build
index 5c2d296fef9..f7422438664 100644
--- a/src/bin/pgevent/meson.build
+++ b/src/bin/pgevent/meson.build
@@ -21,13 +21,11 @@ if cc.get_id() == 'msvc'
pgevent_link_args += '/ignore:4104'
endif
-pgevent = shared_library('pgevent',
+pgevent = shared_module('pgevent',
pgevent_sources,
dependencies: [frontend_code],
link_args: pgevent_link_args,
vs_module_defs: 'pgevent.def',
- kwargs: default_lib_args + {
- 'name_prefix': '',
- },
+ kwargs: default_mod_args,
)
bin_targets += pgevent
--
2.47.0
^ permalink raw reply [nested|flat] 27+ messages in thread
* RE: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-12 16:02 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-12 16:52 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-13 08:53 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
@ 2024-11-15 13:53 ` Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-26 17:15 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 27+ messages in thread
From: Ryohei Takahashi (Fujitsu) @ 2024-11-15 13:53 UTC (permalink / raw)
To: 'Peter Eisentraut' <[email protected]>; [email protected] <[email protected]>; +Cc: Robert Haas <[email protected]>; Dave Page <[email protected]>; Gurjeet Singh <[email protected]>
Hi,
Thank you for your patch.
The patch worked in my Windows build environment and pgevent.dll is installed to lib/ directory.
Regards,
Ryohei Takahashi
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-12 16:02 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-12 16:52 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-13 08:53 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-15 13:53 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
@ 2024-11-26 17:15 ` Peter Eisentraut <[email protected]>
2024-11-29 11:41 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
0 siblings, 1 reply; 27+ messages in thread
From: Peter Eisentraut @ 2024-11-26 17:15 UTC (permalink / raw)
To: Ryohei Takahashi (Fujitsu) <[email protected]>; [email protected] <[email protected]>; +Cc: Robert Haas <[email protected]>; Dave Page <[email protected]>; Gurjeet Singh <[email protected]>
On 15.11.24 14:53, Ryohei Takahashi (Fujitsu) wrote:
> Thank you for your patch.
> The patch worked in my Windows build environment and pgevent.dll is installed to lib/ directory.
Thanks for checking. I have committed this patch and backpatched it to
PG16 and PG17. So the next minor releases will presumably have the file
back in the correct place.
^ permalink raw reply [nested|flat] 27+ messages in thread
* RE: doc: pgevent.dll location
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-12 16:02 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-12 16:52 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-13 08:53 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-15 13:53 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-26 17:15 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
@ 2024-11-29 11:41 ` Ryohei Takahashi (Fujitsu) <[email protected]>
0 siblings, 0 replies; 27+ messages in thread
From: Ryohei Takahashi (Fujitsu) @ 2024-11-29 11:41 UTC (permalink / raw)
To: 'Peter Eisentraut' <[email protected]>; [email protected] <[email protected]>; +Cc: Robert Haas <[email protected]>; Dave Page <[email protected]>; Gurjeet Singh <[email protected]>
Hi,
Thank you for your commit.
Regards,
Ryohei Takahashi
^ permalink raw reply [nested|flat] 27+ messages in thread
end of thread, other threads:[~2024-11-29 11:41 UTC | newest]
Thread overview: 27+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-03-22 21:09 [PATCH v9 10/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-03-22 21:09 [PATCH v10 11/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-03-22 21:09 [PATCH v10 11/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-03-22 21:09 [PATCH v12 11/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-03-22 21:09 [PATCH v8 11/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-03-22 21:09 [PATCH v9 10/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-03-22 21:09 [PATCH v8 11/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-03-22 21:09 [PATCH v11 11/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-03-22 21:09 [PATCH v9 10/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-03-22 21:09 [PATCH v8 11/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-03-22 21:09 [PATCH v11 11/17] table_scan_bitmap_next_block counts lossy and exact pages Melanie Plageman <[email protected]>
2024-11-05 03:02 doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-05 06:00 ` Re: doc: pgevent.dll location Gurjeet Singh <[email protected]>
2024-11-05 15:09 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-05 15:15 ` Re: doc: pgevent.dll location Tom Lane <[email protected]>
2024-11-05 15:27 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-06 12:57 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-06 16:11 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-07 08:16 ` Re: doc: pgevent.dll location Dave Page <[email protected]>
2024-11-11 11:11 ` Re: doc: pgevent.dll location Amit Kapila <[email protected]>
2024-11-12 16:02 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-12 16:52 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-12 17:27 ` Re: doc: pgevent.dll location Robert Haas <[email protected]>
2024-11-13 08:53 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-15 13:53 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[email protected]>
2024-11-26 17:15 ` Re: doc: pgevent.dll location Peter Eisentraut <[email protected]>
2024-11-29 11:41 ` RE: doc: pgevent.dll location Ryohei Takahashi (Fujitsu) <[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