public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Set PD_ALL_VISIBLE and visibility map bits in COPY FREEZE
16+ messages / 9 participants
[nested] [flat]
* [PATCH] Set PD_ALL_VISIBLE and visibility map bits in COPY FREEZE
@ 2021-01-10 19:30 Tomas Vondra <[email protected]>
0 siblings, 0 replies; 16+ messages in thread
From: Tomas Vondra @ 2021-01-10 19:30 UTC (permalink / raw)
Make sure COPY FREEZE marks the pages as PD_ALL_VISIBLE and updates the
visibility map. Until now it only marked individual tuples as frozen,
but page-level flags were not updated.
This is a fairly old patch, and multiple people worked on it. The first
version was written by Jeff Janes, and then reworked by Pavan Deolasee
and Anastasia Lubennikova.
Author: Pavan Deolasee, Anastasia Lubennikova, Jeff Janes
Reviewed-by: Kuntal Ghosh, Jeff Janes, Tomas Vondra, Masahiko Sawada, Andres Freund, Ibrar Ahmed, Robert Haas, Tatsuro Ishii
Discussion: https://postgr.es/m/CABOikdN-ptGv0mZntrK2Q8OtfUuAjqaYMGmkdU1dCKFtUxVLrg@mail.gmail.com
Discussion: https://postgr.es/m/CAMkU%3D1w3osJJ2FneELhhNRLxfZitDgp9FPHee08NT2FQFmz_pQ%40mail.gmail.com
---
.../pg_visibility/expected/pg_visibility.out | 64 +++++++++++++++
contrib/pg_visibility/sql/pg_visibility.sql | 77 +++++++++++++++++++
src/backend/access/heap/heapam.c | 76 ++++++++++++++++--
src/backend/access/heap/hio.c | 17 ++++
src/include/access/heapam_xlog.h | 3 +
5 files changed, 229 insertions(+), 8 deletions(-)
diff --git a/contrib/pg_visibility/expected/pg_visibility.out b/contrib/pg_visibility/expected/pg_visibility.out
index ca4b6e186b..0017e3415c 100644
--- a/contrib/pg_visibility/expected/pg_visibility.out
+++ b/contrib/pg_visibility/expected/pg_visibility.out
@@ -179,6 +179,69 @@ select pg_truncate_visibility_map('test_partition');
(1 row)
+-- test copy freeze
+create table copyfreeze (a int, b char(1500));
+-- load all rows via COPY FREEZE and ensure that all pages are set all-visible
+-- and all-frozen.
+begin;
+truncate copyfreeze;
+copy copyfreeze from stdin freeze;
+commit;
+select * from pg_visibility_map('copyfreeze');
+ blkno | all_visible | all_frozen
+-------+-------------+------------
+ 0 | t | t
+ 1 | t | t
+ 2 | t | t
+(3 rows)
+
+select * from pg_check_frozen('copyfreeze');
+ t_ctid
+--------
+(0 rows)
+
+-- load half the rows via regular COPY and rest via COPY FREEZE. The pages
+-- which are touched by regular COPY must not be set all-visible/all-frozen. On
+-- the other hand, pages allocated by COPY FREEZE should be marked
+-- all-frozen/all-visible.
+begin;
+truncate copyfreeze;
+copy copyfreeze from stdin;
+copy copyfreeze from stdin freeze;
+commit;
+select * from pg_visibility_map('copyfreeze');
+ blkno | all_visible | all_frozen
+-------+-------------+------------
+ 0 | f | f
+ 1 | f | f
+ 2 | t | t
+(3 rows)
+
+select * from pg_check_frozen('copyfreeze');
+ t_ctid
+--------
+(0 rows)
+
+-- Try a mix of regular COPY and COPY FREEZE.
+begin;
+truncate copyfreeze;
+copy copyfreeze from stdin freeze;
+copy copyfreeze from stdin;
+copy copyfreeze from stdin freeze;
+commit;
+select * from pg_visibility_map('copyfreeze');
+ blkno | all_visible | all_frozen
+-------+-------------+------------
+ 0 | t | t
+ 1 | f | f
+ 2 | t | t
+(3 rows)
+
+select * from pg_check_frozen('copyfreeze');
+ t_ctid
+--------
+(0 rows)
+
-- cleanup
drop table test_partitioned;
drop view test_view;
@@ -188,3 +251,4 @@ drop server dummy_server;
drop foreign data wrapper dummy;
drop materialized view matview_visibility_test;
drop table regular_table;
+drop table copyfreeze;
diff --git a/contrib/pg_visibility/sql/pg_visibility.sql b/contrib/pg_visibility/sql/pg_visibility.sql
index f79b54480b..ec1afd4906 100644
--- a/contrib/pg_visibility/sql/pg_visibility.sql
+++ b/contrib/pg_visibility/sql/pg_visibility.sql
@@ -94,6 +94,82 @@ select count(*) > 0 from pg_visibility_map_summary('test_partition');
select * from pg_check_frozen('test_partition'); -- hopefully none
select pg_truncate_visibility_map('test_partition');
+-- test copy freeze
+create table copyfreeze (a int, b char(1500));
+
+-- load all rows via COPY FREEZE and ensure that all pages are set all-visible
+-- and all-frozen.
+begin;
+truncate copyfreeze;
+copy copyfreeze from stdin freeze;
+1 '1'
+2 '2'
+3 '3'
+4 '4'
+5 '5'
+6 '6'
+7 '7'
+8 '8'
+9 '9'
+10 '10'
+11 '11'
+12 '12'
+\.
+commit;
+select * from pg_visibility_map('copyfreeze');
+select * from pg_check_frozen('copyfreeze');
+
+-- load half the rows via regular COPY and rest via COPY FREEZE. The pages
+-- which are touched by regular COPY must not be set all-visible/all-frozen. On
+-- the other hand, pages allocated by COPY FREEZE should be marked
+-- all-frozen/all-visible.
+begin;
+truncate copyfreeze;
+copy copyfreeze from stdin;
+1 '1'
+2 '2'
+3 '3'
+4 '4'
+5 '5'
+6 '6'
+\.
+copy copyfreeze from stdin freeze;
+7 '7'
+8 '8'
+9 '9'
+10 '10'
+11 '11'
+12 '12'
+\.
+commit;
+select * from pg_visibility_map('copyfreeze');
+select * from pg_check_frozen('copyfreeze');
+
+-- Try a mix of regular COPY and COPY FREEZE.
+begin;
+truncate copyfreeze;
+copy copyfreeze from stdin freeze;
+1 '1'
+2 '2'
+3 '3'
+4 '4'
+5 '5'
+\.
+copy copyfreeze from stdin;
+6 '6'
+\.
+copy copyfreeze from stdin freeze;
+7 '7'
+8 '8'
+9 '9'
+10 '10'
+11 '11'
+12 '12'
+\.
+commit;
+select * from pg_visibility_map('copyfreeze');
+select * from pg_check_frozen('copyfreeze');
+
-- cleanup
drop table test_partitioned;
drop view test_view;
@@ -103,3 +179,4 @@ drop server dummy_server;
drop foreign data wrapper dummy;
drop materialized view matview_visibility_test;
drop table regular_table;
+drop table copyfreeze;
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 53e997cd55..32cc010cb7 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -2103,6 +2103,7 @@ heap_multi_insert(Relation relation, TupleTableSlot **slots, int ntuples,
int ndone;
PGAlignedBlock scratch;
Page page;
+ Buffer vmbuffer = InvalidBuffer;
bool needwal;
Size saveFreeSpace;
bool need_tuple_data = RelationIsLogicallyLogged(relation);
@@ -2157,8 +2158,9 @@ heap_multi_insert(Relation relation, TupleTableSlot **slots, int ntuples,
while (ndone < ntuples)
{
Buffer buffer;
- Buffer vmbuffer = InvalidBuffer;
+ bool starting_with_empty_page;
bool all_visible_cleared = false;
+ bool all_frozen_set = false;
int nthispage;
CHECK_FOR_INTERRUPTS();
@@ -2166,12 +2168,20 @@ heap_multi_insert(Relation relation, TupleTableSlot **slots, int ntuples,
/*
* Find buffer where at least the next tuple will fit. If the page is
* all-visible, this will also pin the requisite visibility map page.
+ *
+ * Also pin visibility map page if COPY FREEZE inserts tuples into an
+ * empty page. See all_frozen_set below.
*/
buffer = RelationGetBufferForTuple(relation, heaptuples[ndone]->t_len,
InvalidBuffer, options, bistate,
&vmbuffer, NULL);
page = BufferGetPage(buffer);
+ starting_with_empty_page = PageGetMaxOffsetNumber(page) == 0;
+
+ if (starting_with_empty_page && (options & HEAP_INSERT_FROZEN))
+ all_frozen_set = true;
+
/* NO EREPORT(ERROR) from here till changes are logged */
START_CRIT_SECTION();
@@ -2205,7 +2215,14 @@ heap_multi_insert(Relation relation, TupleTableSlot **slots, int ntuples,
log_heap_new_cid(relation, heaptup);
}
- if (PageIsAllVisible(page))
+ /*
+ * If the page is all visible, need to clear that, unless we're only
+ * going to add further frozen rows to it.
+ *
+ * If we're only adding already frozen rows to a previously empty
+ * page, mark it as all-visible.
+ */
+ if (PageIsAllVisible(page) && !(options & HEAP_INSERT_FROZEN))
{
all_visible_cleared = true;
PageClearAllVisible(page);
@@ -2213,6 +2230,8 @@ heap_multi_insert(Relation relation, TupleTableSlot **slots, int ntuples,
BufferGetBlockNumber(buffer),
vmbuffer, VISIBILITYMAP_VALID_BITS);
}
+ else if (all_frozen_set)
+ PageSetAllVisible(page);
/*
* XXX Should we set PageSetPrunable on this page ? See heap_insert()
@@ -2236,8 +2255,7 @@ heap_multi_insert(Relation relation, TupleTableSlot **slots, int ntuples,
* If the page was previously empty, we can reinit the page
* instead of restoring the whole thing.
*/
- init = (ItemPointerGetOffsetNumber(&(heaptuples[ndone]->t_self)) == FirstOffsetNumber &&
- PageGetMaxOffsetNumber(page) == FirstOffsetNumber + nthispage - 1);
+ init = starting_with_empty_page;
/* allocate xl_heap_multi_insert struct from the scratch area */
xlrec = (xl_heap_multi_insert *) scratchptr;
@@ -2255,7 +2273,15 @@ heap_multi_insert(Relation relation, TupleTableSlot **slots, int ntuples,
/* the rest of the scratch space is used for tuple data */
tupledata = scratchptr;
- xlrec->flags = all_visible_cleared ? XLH_INSERT_ALL_VISIBLE_CLEARED : 0;
+ /* check that the mutually exclusive flags are not both set */
+ Assert (!(all_visible_cleared && all_frozen_set));
+
+ xlrec->flags = 0;
+ if (all_visible_cleared)
+ xlrec->flags = XLH_INSERT_ALL_VISIBLE_CLEARED;
+ if (all_frozen_set)
+ xlrec->flags = XLH_INSERT_ALL_FROZEN_SET;
+
xlrec->ntuples = nthispage;
/*
@@ -2329,13 +2355,39 @@ heap_multi_insert(Relation relation, TupleTableSlot **slots, int ntuples,
END_CRIT_SECTION();
- UnlockReleaseBuffer(buffer);
- if (vmbuffer != InvalidBuffer)
- ReleaseBuffer(vmbuffer);
+ /*
+ * If we've frozen everything on the page, update the visibilitymap.
+ * We're already holding pin on the vmbuffer.
+ */
+ if (all_frozen_set)
+ {
+ Assert(PageIsAllVisible(page));
+ Assert(visibilitymap_pin_ok(BufferGetBlockNumber(buffer), vmbuffer));
+ /*
+ * It's fine to use InvalidTransactionId here - this is only used
+ * when HEAP_INSERT_FROZEN is specified, which intentionally
+ * violates visibility rules.
+ */
+ visibilitymap_set(relation, BufferGetBlockNumber(buffer), buffer,
+ InvalidXLogRecPtr, vmbuffer,
+ InvalidTransactionId,
+ VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
+ }
+
+ UnlockReleaseBuffer(buffer);
ndone += nthispage;
+
+ /*
+ * NB: Only release vmbuffer after inserting all tuples - it's fairly
+ * likely that we'll insert into subsequent heap pages that are likely
+ * to use the same vm page.
+ */
}
+ if (vmbuffer != InvalidBuffer)
+ ReleaseBuffer(vmbuffer);
+
/*
* We're done with the actual inserts. Check for conflicts again, to
* ensure that all rw-conflicts in to these inserts are detected. Without
@@ -8265,6 +8317,10 @@ heap_xlog_multi_insert(XLogReaderState *record)
XLogRecGetBlockTag(record, 0, &rnode, NULL, &blkno);
+ /* check that the mutually exclusive flags are not both set */
+ Assert (!((xlrec->flags & XLH_INSERT_ALL_VISIBLE_CLEARED) &&
+ (xlrec->flags & XLH_INSERT_ALL_FROZEN_SET)));
+
/*
* The visibility map may need to be fixed even if the heap page is
* already up-to-date.
@@ -8354,6 +8410,10 @@ heap_xlog_multi_insert(XLogReaderState *record)
if (xlrec->flags & XLH_INSERT_ALL_VISIBLE_CLEARED)
PageClearAllVisible(page);
+ /* XLH_INSERT_ALL_FROZEN_SET implies that all tuples are visible */
+ if (xlrec->flags & XLH_INSERT_ALL_FROZEN_SET)
+ PageSetAllVisible(page);
+
MarkBufferDirty(buffer);
}
if (BufferIsValid(buffer))
diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c
index fac3b8e9ff..2d23b3ef71 100644
--- a/src/backend/access/heap/hio.c
+++ b/src/backend/access/heap/hio.c
@@ -433,6 +433,14 @@ loop:
buffer = ReadBufferBI(relation, targetBlock, RBM_NORMAL, bistate);
if (PageIsAllVisible(BufferGetPage(buffer)))
visibilitymap_pin(relation, targetBlock, vmbuffer);
+
+ /*
+ * If the page is empty, pin vmbuffer to set all_frozen bit later.
+ */
+ if ((options & HEAP_INSERT_FROZEN) &&
+ (PageGetMaxOffsetNumber(BufferGetPage(buffer)) == 0))
+ visibilitymap_pin(relation, targetBlock, vmbuffer);
+
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
}
else if (otherBlock == targetBlock)
@@ -619,6 +627,15 @@ loop:
PageInit(page, BufferGetPageSize(buffer), 0);
MarkBufferDirty(buffer);
+ /*
+ * The page is empty, pin vmbuffer to set all_frozen bit.
+ */
+ if (options & HEAP_INSERT_FROZEN)
+ {
+ Assert(PageGetMaxOffsetNumber(BufferGetPage(buffer)) == 0);
+ visibilitymap_pin(relation, BufferGetBlockNumber(buffer), vmbuffer);
+ }
+
/*
* Release the file-extension lock; it's now OK for someone else to extend
* the relation some more.
diff --git a/src/include/access/heapam_xlog.h b/src/include/access/heapam_xlog.h
index 51586b883d..178d49710a 100644
--- a/src/include/access/heapam_xlog.h
+++ b/src/include/access/heapam_xlog.h
@@ -69,6 +69,9 @@
#define XLH_INSERT_CONTAINS_NEW_TUPLE (1<<3)
#define XLH_INSERT_ON_TOAST_RELATION (1<<4)
+/* all_frozen_set always implies all_visible_set */
+#define XLH_INSERT_ALL_FROZEN_SET (1<<5)
+
/*
* xl_heap_update flag values, 8 bits are available.
*/
--
2.26.2
--------------19F6AF79E033375862CBEBB4
Content-Type: text/x-patch; charset=UTF-8;
name="0002_handle_HEAP_INSERT_FROZEN_in_heap_insert.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="0002_handle_HEAP_INSERT_FROZEN_in_heap_insert.patch"
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 32cc010cb7..3663ff4b83 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -1862,8 +1862,12 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid,
TransactionId xid = GetCurrentTransactionId();
HeapTuple heaptup;
Buffer buffer;
+ Page page;
Buffer vmbuffer = InvalidBuffer;
+ bool starting_with_empty_page;
bool all_visible_cleared = false;
+ bool all_frozen_set = false;
+ uint8 vmstatus = 0;
/*
* Fill in tuple header fields and toast the tuple if necessary.
@@ -1876,11 +1880,36 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid,
/*
* Find buffer to insert this tuple into. If the page is all visible,
* this will also pin the requisite visibility map page.
+ *
+ * Also pin visibility map page if COPY FREEZE inserts tuples into an
+ * empty page. See all_frozen_set below.
*/
buffer = RelationGetBufferForTuple(relation, heaptup->t_len,
InvalidBuffer, options, bistate,
&vmbuffer, NULL);
+
+ /*
+ * If we're inserting frozen entry into an empty page,
+ * set visibility map bits and PageAllVisible() hint.
+ *
+ * If we're inserting frozen entry into already all_frozen page,
+ * preserve this state.
+ */
+ if (options & HEAP_INSERT_FROZEN)
+ {
+ page = BufferGetPage(buffer);
+
+ starting_with_empty_page = PageGetMaxOffsetNumber(page) == 0;
+
+ if (visibilitymap_pin_ok(BufferGetBlockNumber(buffer), vmbuffer))
+ vmstatus = visibilitymap_get_status(relation,
+ BufferGetBlockNumber(buffer), &vmbuffer);
+
+ if ((starting_with_empty_page || vmstatus & VISIBILITYMAP_ALL_FROZEN))
+ all_frozen_set = true;
+ }
+
/*
* We're about to do the actual insert -- but check for conflict first, to
* avoid possibly having to roll back work we've just done.
@@ -1904,7 +1933,14 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid,
RelationPutHeapTuple(relation, buffer, heaptup,
(options & HEAP_INSERT_SPECULATIVE) != 0);
- if (PageIsAllVisible(BufferGetPage(buffer)))
+ /*
+ * If the page is all visible, need to clear that, unless we're only
+ * going to add further frozen rows to it.
+ *
+ * If we're only adding already frozen rows to a previously empty
+ * or all visible page, mark it as all-visible.
+ */
+ if (PageIsAllVisible(BufferGetPage(buffer)) && !(options & HEAP_INSERT_FROZEN))
{
all_visible_cleared = true;
PageClearAllVisible(BufferGetPage(buffer));
@@ -1912,6 +1948,8 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid,
ItemPointerGetBlockNumber(&(heaptup->t_self)),
vmbuffer, VISIBILITYMAP_VALID_BITS);
}
+ else if (all_frozen_set)
+ PageSetAllVisible(page);
/*
* XXX Should we set PageSetPrunable on this page ?
@@ -1959,6 +1997,8 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid,
xlrec.flags = 0;
if (all_visible_cleared)
xlrec.flags |= XLH_INSERT_ALL_VISIBLE_CLEARED;
+ if (all_frozen_set)
+ xlrec.flags = XLH_INSERT_ALL_FROZEN_SET;
if (options & HEAP_INSERT_SPECULATIVE)
xlrec.flags |= XLH_INSERT_IS_SPECULATIVE;
Assert(ItemPointerGetBlockNumber(&heaptup->t_self) == BufferGetBlockNumber(buffer));
@@ -2007,6 +2047,29 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid,
END_CRIT_SECTION();
+ /*
+ * If we've frozen everything on the page, update the visibilitymap.
+ * We're already holding pin on the vmbuffer.
+ *
+ * No need to update the visibilitymap if it had all_frozen bit set
+ * before this insertion.
+ */
+ if (all_frozen_set && ((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0))
+ {
+ Assert(PageIsAllVisible(page));
+ Assert(visibilitymap_pin_ok(BufferGetBlockNumber(buffer), vmbuffer));
+
+ /*
+ * It's fine to use InvalidTransactionId here - this is only used
+ * when HEAP_INSERT_FROZEN is specified, which intentionally
+ * violates visibility rules.
+ */
+ visibilitymap_set(relation, BufferGetBlockNumber(buffer), buffer,
+ InvalidXLogRecPtr, vmbuffer,
+ InvalidTransactionId,
+ VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
+ }
+
UnlockReleaseBuffer(buffer);
if (vmbuffer != InvalidBuffer)
ReleaseBuffer(vmbuffer);
@@ -8197,6 +8260,10 @@ heap_xlog_insert(XLogReaderState *record)
ItemPointerSetBlockNumber(&target_tid, blkno);
ItemPointerSetOffsetNumber(&target_tid, xlrec->offnum);
+ /* check that the mutually exclusive flags are not both set */
+ Assert (!((xlrec->flags & XLH_INSERT_ALL_VISIBLE_CLEARED) &&
+ (xlrec->flags & XLH_INSERT_ALL_FROZEN_SET)));
+
/*
* The visibility map may need to be fixed even if the heap page is
* already up-to-date.
@@ -8267,6 +8334,11 @@ heap_xlog_insert(XLogReaderState *record)
if (xlrec->flags & XLH_INSERT_ALL_VISIBLE_CLEARED)
PageClearAllVisible(page);
+ /* XLH_INSERT_ALL_FROZEN_SET implies that all tuples are visible */
+ if (xlrec->flags & XLH_INSERT_ALL_FROZEN_SET)
+ PageSetAllVisible(page);
+
+
MarkBufferDirty(buffer);
}
if (BufferIsValid(buffer))
--------------19F6AF79E033375862CBEBB4--
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2024-12-16 17:52 Andres Freund <[email protected]>
0 siblings, 1 reply; 16+ messages in thread
From: Andres Freund @ 2024-12-16 17:52 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Robert Haas <[email protected]>; Michael Harris <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
Hi,
On 2024-12-16 18:05:59 +0100, Alvaro Herrera wrote:
> On 2024-Dec-16, Robert Haas wrote:
>
> > On Mon, Dec 16, 2024 at 9:12 AM Andres Freund <[email protected]> wrote:
> > > Personally I don't like the obfuscation of "allocate" and "zero" vs just
> > > naming the function names. But I guess that's just taste thing.
> > >
> > > When looking for problems it's considerably more work with bytes, because - at
> > > least for me - the large number is hard to compare quickly and to know how
> > > aggressively we extended also requires to translate to blocks.
> >
> > FWIW, I think that what we report in the error should hew as closely
> > to the actual system call as possible. Hence, I agree with your first
> > complaint and would prefer to simply see the system calls named, but I
> > disagree with your second complaint and would prefer to see the byte
> > count.
>
> Maybe we can add errdetail("The system call was FileFallocate( ... %u ...)")
> with the number of bytes, and leave the errmsg() mentioning the general
> operation being done (allocate, zero, etc) with the number of blocks.
I don't see what we gain by requiring guesswork (what does allocating vs
zeroing mean, zeroing also allocates disk space after all) to interpret the
main error message. My experience is that it's often harder to get the DETAIL
than the actual error message (grepping becomes harder due to separate line,
terse verbosity is commonly used).
I think we're going too far towards not mentioning the actual problems in too
many error messages in general.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2024-12-16 23:23 Robert Haas <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 1 reply; 16+ messages in thread
From: Robert Haas @ 2024-12-16 23:23 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Michael Harris <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
On Mon, Dec 16, 2024 at 12:52 PM Andres Freund <[email protected]> wrote:
> I don't see what we gain by requiring guesswork (what does allocating vs
> zeroing mean, zeroing also allocates disk space after all) to interpret the
> main error message. My experience is that it's often harder to get the DETAIL
> than the actual error message (grepping becomes harder due to separate line,
> terse verbosity is commonly used).
I feel like the normal way that we do this is basically:
could not {name of system call} file "\%s\": %m
e.g.
could not read file \"%s\": %m
I don't know why we should do anything else in this type of case.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2024-12-19 06:47 Michael Harris <[email protected]>
parent: Robert Haas <[email protected]>
0 siblings, 3 replies; 16+ messages in thread
From: Michael Harris @ 2024-12-19 06:47 UTC (permalink / raw)
To: Robert Haas <[email protected]>; Andres Freund <[email protected]>; Jakub Wartak <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
Hello,
I finally managed to get the patched version installed in a production
database where the error is occurring very regularly.
Here is a sample of the output:
2024-12-19 01:08:50 CET [2533222]: LOG: mdzeroextend FileFallocate
failing with ENOSPC: free space for filesystem containing
"pg_tblspc/107724/PG_16_202307071/465960/2591590762.15" f_blocks:
2683831808, f_bfree: 205006167, f_bavail: 205006167 f_files:
1073741376, f_ffree: 1069933796
2024-12-19 01:08:50 CET [2533222]: ERROR: could not extend file
"pg_tblspc/107724/PG_16_202307071/465960/2591590762.15" by 13 blocks,
from 110869 to 110882, using FileFallocate(): No space left on device
2024-12-19 01:08:51 CET [2533246]: LOG: mdzeroextend FileFallocate
failing with ENOSPC: free space for filesystem containing
"pg_tblspc/107724/PG_16_202307071/465960/2591590762.15" f_blocks:
2683831808, f_bfree: 205004945, f_bavail: 205004945 f_files:
1073741376, f_ffree: 1069933796
2024-12-19 01:08:51 CET [2533246]: ERROR: could not extend file
"pg_tblspc/107724/PG_16_202307071/465960/2591590762.15" by 14 blocks,
from 110965 to 110979, using FileFallocate(): No space left on device
2024-12-19 01:08:59 CET [2531320]: LOG: mdzeroextend FileFallocate
failing with ENOSPC: free space for filesystem containing
"pg_tblspc/107724/PG_16_202307071/465960/2591590762.15" f_blocks:
2683831808, f_bfree: 204980672, f_bavail: 204980672 f_files:
1073741376, f_ffree: 1069933795
2024-12-19 01:08:59 CET [2531320]: ERROR: could not extend file
"pg_tblspc/107724/PG_16_202307071/465960/2591590762.15" by 14 blocks,
from 111745 to 111759, using FileFallocate(): No space left on device
2024-12-19 01:09:01 CET [2531331]: LOG: mdzeroextend FileFallocate
failing with ENOSPC: free space for filesystem containing
"pg_tblspc/107724/PG_16_202307071/465960/2591590762.15" f_blocks:
2683831808, f_bfree: 204970783, f_bavail: 204970783 f_files:
1073741376, f_ffree: 1069933795
2024-12-19 01:09:01 CET [2531331]: ERROR: could not extend file
"pg_tblspc/107724/PG_16_202307071/465960/2591590762.15" by 12 blocks,
from 112045 to 112057, using FileFallocate(): No space left on device
I have attached a file containing all the errors I collected. The
error is happening pretty regularly - over 400 times in a ~6 hour
period. The number of blocks being extended varies from ~9 to ~15, and
the statfs result shows plenty of available space & inodes at the
time. The errors do seem to come in bursts.
This is a different system to those I previously provided logs from.
It is also running RHEL8 with a similar configuration to the other
system.
I have so far not installed the bpftrace that Jakub suggested before -
as I say this is a production machine and I am wary of triggering a
kernel panic or worse (even though it seems like the risk for that
would be low?). While a kernel stack trace would no doubt be helpful
to the XFS developers, from a postgres point of view, would that be
likely to help us decide what to do about this?
Cheers
Mike
On Tue, 17 Dec 2024 at 10:23, Robert Haas <[email protected]> wrote:
>
> On Mon, Dec 16, 2024 at 12:52 PM Andres Freund <[email protected]> wrote:
> > I don't see what we gain by requiring guesswork (what does allocating vs
> > zeroing mean, zeroing also allocates disk space after all) to interpret the
> > main error message. My experience is that it's often harder to get the DETAIL
> > than the actual error message (grepping becomes harder due to separate line,
> > terse verbosity is commonly used).
>
> I feel like the normal way that we do this is basically:
>
> could not {name of system call} file "\%s\": %m
>
> e.g.
>
> could not read file \"%s\": %m
>
> I don't know why we should do anything else in this type of case.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
Attachments:
[application/octet-stream] rhel8_fallocate_extended.log (191.5K, ../../CADofcAXMX3OuPfbOU98v+nqGRxVWyUB+KrLs3LhPojgxTAntog@mail.gmail.com/2-rhel8_fallocate_extended.log)
download
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2024-12-20 12:25 Jakub Wartak <[email protected]>
parent: Michael Harris <[email protected]>
2 siblings, 1 reply; 16+ messages in thread
From: Jakub Wartak @ 2024-12-20 12:25 UTC (permalink / raw)
To: Michael Harris <[email protected]>; +Cc: Robert Haas <[email protected]>; Andres Freund <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
On Thu, Dec 19, 2024 at 7:49 AM Michael Harris <[email protected]> wrote:
> Hello,
>
> I finally managed to get the patched version installed in a production
> database where the error is occurring very regularly.
>
> Here is a sample of the output:
>
> 2024-12-19 01:08:50 CET [2533222]: LOG: mdzeroextend FileFallocate
> failing with ENOSPC: free space for filesystem containing
> "pg_tblspc/107724/PG_16_202307071/465960/2591590762.15" f_blocks:
> 2683831808, f_bfree: 205006167, f_bavail: 205006167 f_files:
> 1073741376, f_ffree: 1069933796
[..]
> I have attached a file containing all the errors I collected. The
> error is happening pretty regularly - over 400 times in a ~6 hour
> period. The number of blocks being extended varies from ~9 to ~15, and
> the statfs result shows plenty of available space & inodes at the
> time. The errors do seem to come in bursts.
>
I couldn't resist: you seem to have entered the quantum realm of free disk
space AKA Schrodinger's free space: you both have the space and dont have
it... ;)
No one else has responded, so I'll try. My take is that we got very limited
number of reports (2-3) of this stuff happening and it always seem to be
>90% space used, yet the adoption of PG16 is rising, so we may or may not
see more errors of those kind, but on another side of things: it's
frequency is so rare that it's really wild we don't see more reports like
this one. Lots of OS upgrades in the wild are performed by building new
standbys (maybe that lowers the fs fragmentation), rather than in-place OS
upgrades. To me it sounds like a new bug in XFS that is rare. You can
probably live with #undef HAVE_POSIX_FALLOCATE as a way to survive, another
would be probably to try to run xfs_fsr to defragment the fs.
Longer-term: other than collecting the eBPF data to start digging from
where it is really triggered, I don't see a way forward. It would be
suboptimal to just abandon fallocate() optimizations from commit
31966b151e6ab7a6284deab6e8fe5faddaf2ae4c, just because of very unusual
combinations of factors (XFS bug).
Well we could be having some kludge like pseudo-code: if(posix_falloc() ==
ENOSPC && statfs().free_space_pct >= 1) fallback_to_pwrites(), but it is
ugly. Another is GUC (or even two -- how much to extend or to use or not
the posix_fallocate()), but people do not like more GUCs...
> I have so far not installed the bpftrace that Jakub suggested before -
> as I say this is a production machine and I am wary of triggering a
> kernel panic or worse (even though it seems like the risk for that
> would be low?). While a kernel stack trace would no doubt be helpful
> to the XFS developers, from a postgres point of view, would that be
> likely to help us decide what to do about this?[..]
Well you could try having reproduction outside of production, or even clone
the storage (but not using backup/restore), but literally clone the XFS
LUNs on the storage itself and connect those separate VM to have a safe
testbed (or even use dd(1) of some smaller XFS fs exhibiting such behaviour
to some other place)
As for eBPF/bpftrace: it is safe (it's sandboxed anyway), lots of customers
are using it, but as always YMMV.
There's also xfs_fsr that might help overcome.
You can also experiment if -o allocsize helps or just even try -o
allocsize=0 (but that might have some negative effects on performance
probably)
-J.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2024-12-20 16:39 Andres Freund <[email protected]>
parent: Michael Harris <[email protected]>
2 siblings, 1 reply; 16+ messages in thread
From: Andres Freund @ 2024-12-20 16:39 UTC (permalink / raw)
To: Michael Harris <[email protected]>; +Cc: Robert Haas <[email protected]>; Jakub Wartak <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
Hi,
On 2024-12-19 17:47:13 +1100, Michael Harris wrote:
> I finally managed to get the patched version installed in a production
> database where the error is occurring very regularly.
Thanks!
> Here is a sample of the output:
>
> 2024-12-19 01:08:50 CET [2533222]: LOG: mdzeroextend FileFallocate
> failing with ENOSPC: free space for filesystem containing
> "pg_tblspc/107724/PG_16_202307071/465960/2591590762.15" f_blocks:
> 2683831808, f_bfree: 205006167, f_bavail: 205006167 f_files:
> 1073741376, f_ffree: 1069933796
That's ~700 GB of free space...
It'd be interesting to see filefrag -v for that segment.
> This is a different system to those I previously provided logs from.
> It is also running RHEL8 with a similar configuration to the other
> system.
Given it's a RHEL system, have you raised this as an issue with RH? They
probably have somebody with actual XFS hacking experience on staff.
RH's kernels are *heavily* patched, so it's possible the issue is actually RH
specific.
> I have so far not installed the bpftrace that Jakub suggested before -
> as I say this is a production machine and I am wary of triggering a
> kernel panic or worse (even though it seems like the risk for that
> would be low?). While a kernel stack trace would no doubt be helpful
> to the XFS developers, from a postgres point of view, would that be
> likely to help us decide what to do about this?
Well, I'm personally wary of installing workarounds for a problem I don't
understand and can't reproduce, which might be specific to old filesystems
and/or heavily patched kernels. This clearly is an FS bug.
That said, if we learn that somehow this is a fundamental XFS issue that can
be triggered on every XFS filesystem, with current kernels, it becomes more
reasonable to implement a workaround in PG.
Another thing I've been wondering about is if we could reduce the frequency of
hitting problems by rounding up the number of blocks we extend by to powers of
two. That would probably reduce fragmentation, and the extra space would be
quickly used in workloads where we extend by a bunch of blocks at once,
anyway.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2024-12-27 14:16 Bruce Momjian <[email protected]>
parent: Jakub Wartak <[email protected]>
0 siblings, 0 replies; 16+ messages in thread
From: Bruce Momjian @ 2024-12-27 14:16 UTC (permalink / raw)
To: Jakub Wartak <[email protected]>; +Cc: Michael Harris <[email protected]>; Robert Haas <[email protected]>; Andres Freund <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
On Fri, Dec 20, 2024 at 01:25:41PM +0100, Jakub Wartak wrote:
> On Thu, Dec 19, 2024 at 7:49 AM Michael Harris <[email protected]> wrote:
> No one else has responded, so I'll try. My take is that we got very limited
> number of reports (2-3) of this stuff happening and it always seem to be >90%
> space used, yet the adoption of PG16 is rising, so we may or may not see more
> errors of those kind, but on another side of things: it's frequency is so rare
My guess is that if you are seeing this with 90% full, and not lesser
values, that something is being temporarily exhausted in XFS and the
kernel errno API just doesn't allow returning enough detail to explain
what is being exhausted. A traditional Unix file system only has limits
for the inode table and free blocks, but I am sure XFS has many more
areas of possible exhaustion.
I didn't see any mention of checking the kernel log, which might have
more details of what XFS is having problems with.
I agree trying to modify Postgres for this now makes no sense since we
don't even know the cause. Once we find the cause, and admit it can't
be avoided or quickly fixed, we can reevaluate.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2024-12-31 15:31 Andres Freund <[email protected]>
parent: Michael Harris <[email protected]>
2 siblings, 1 reply; 16+ messages in thread
From: Andres Freund @ 2024-12-31 15:31 UTC (permalink / raw)
To: Michael Harris <[email protected]>; +Cc: Robert Haas <[email protected]>; Jakub Wartak <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
Hi,
On 2024-12-19 17:47:13 +1100, Michael Harris wrote:
> I have attached a file containing all the errors I collected. The
> error is happening pretty regularly - over 400 times in a ~6 hour
> period. The number of blocks being extended varies from ~9 to ~15, and
> the statfs result shows plenty of available space & inodes at the
> time. The errors do seem to come in bursts.
One interesting moment is this:
2024-12-19 01:59:39 CET [2559130]: LOG: mdzeroextend FileFallocate failing with ENOSPC: free space for filesystem containing "pg_tblspc/107724/PG_16_202307071/465960/3232056651" f_blocks: 2683831808, f_bfree: 198915036, f_bavail: 198915036 f_files: 1073741376, f_ffree: 1069932412
2024-12-19 01:59:39 CET [2559130]: ERROR: could not extend file "pg_tblspc/107724/PG_16_202307071/465960/3232056651" by 9 blocks, from 59723 to 59732, using FileFallocate(): No space left on device
2024-12-19 04:47:04 CET [2646363]: LOG: mdzeroextend FileFallocate failing with ENOSPC: free space for filesystem containing "pg_tblspc/107724/PG_16_202307071/465960/3232056651.2" f_blocks: 2683831808, f_bfree: 300862306, f_bavail: 300862306 f_files: 1073741376, f_ffree: 1069821450
2024-12-19 04:47:04 CET [2646363]: ERROR: could not extend file "pg_tblspc/107724/PG_16_202307071/465960/3232056651.2" by 11 blocks, from 29850 to 29861, using FileFallocate(): No space left on device
Note that there's
a) a few hours between messages, whereas previous they were more frequent
b) f_bfree increased substantially.
I assume that somewhere around 2AM some script prunes old partitions?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2025-01-02 10:41 Andrea Gelmini <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 1 reply; 16+ messages in thread
From: Andrea Gelmini @ 2025-01-02 10:41 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Michael Harris <[email protected]>; Robert Haas <[email protected]>; Jakub Wartak <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
Il giorno mar 31 dic 2024 alle ore 16:31 Andres Freund <[email protected]>
ha scritto:
2024-12-19 04:47:04 CET [2646363]: ERROR: could not extend file
> "pg_tblspc/107724/PG_16_202307071/465960/3232056651.2" by 11 blocks, from
> 29850 to 29861, using FileFallocate(): No space left on device
Dunno it it helps, but today I read this reference in latest patchset on
XFS mailing list:
https://lore.kernel.org/linux-xfs/[email protected]/
It could be related and explain the effect?
For the record, I found it here:
https://lore.kernel.org/linux-xfs/CANubcdXWHOtTW4PjJE1qjAJHEg48LS7MFc065gcQwoH7s0Ybqw@mail.gmail.com...
Ciao,
Gelma
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2025-01-02 14:38 Andres Freund <[email protected]>
parent: Andrea Gelmini <[email protected]>
0 siblings, 0 replies; 16+ messages in thread
From: Andres Freund @ 2025-01-02 14:38 UTC (permalink / raw)
To: Andrea Gelmini <[email protected]>; +Cc: Michael Harris <[email protected]>; Robert Haas <[email protected]>; Jakub Wartak <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
Hi,
On 2025-01-02 11:41:56 +0100, Andrea Gelmini wrote:
> Il giorno mar 31 dic 2024 alle ore 16:31 Andres Freund <[email protected]>
> ha scritto:
>
> 2024-12-19 04:47:04 CET [2646363]: ERROR: could not extend file
> > "pg_tblspc/107724/PG_16_202307071/465960/3232056651.2" by 11 blocks, from
> > 29850 to 29861, using FileFallocate(): No space left on device
>
>
> Dunno it it helps, but today I read this reference in latest patchset on
> XFS mailing list:
> https://lore.kernel.org/linux-xfs/[email protected]/
>
>
> It could be related and explain the effect?
I doubt it - there was a lot more free space in the various AGs and they, with
the exception of 1-2 AGs, weren't that fragmented.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2025-01-02 14:40 Andres Freund <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 2 replies; 16+ messages in thread
From: Andres Freund @ 2025-01-02 14:40 UTC (permalink / raw)
To: Michael Harris <[email protected]>; +Cc: Robert Haas <[email protected]>; Jakub Wartak <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
Hi,
On 2024-12-20 11:39:42 -0500, Andres Freund wrote:
> On 2024-12-19 17:47:13 +1100, Michael Harris wrote:
> > This is a different system to those I previously provided logs from.
> > It is also running RHEL8 with a similar configuration to the other
> > system.
>
> Given it's a RHEL system, have you raised this as an issue with RH? They
> probably have somebody with actual XFS hacking experience on staff.
>
> RH's kernels are *heavily* patched, so it's possible the issue is actually RH
> specific.
FWIW, I raised this on the #xfs irc channel. One ask they had was:
│15:56:40 dchinner | andres: can you get a metadump of a filesystem that is displaying these symptoms for us to analyse?
│15:57:54 dchinner | metadumps don't contain data, and metadata is obfuscated so no filenames or attributes are exposed, either.
Greetings,
Andres
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2025-01-04 04:34 Michael Harris <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 16+ messages in thread
From: Michael Harris @ 2025-01-04 04:34 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Robert Haas <[email protected]>; Jakub Wartak <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
Hi Andres
On Wed, 1 Jan 2025 at 02:31, Andres Freund <[email protected]> wrote:
> Note that there's
> a) a few hours between messages, whereas previous they were more frequent
> b) f_bfree increased substantially.
>
> I assume that somewhere around 2AM some script prunes old partitions?
Correct.
Data is imported continuously, and the pruning is typically scheduled for 02:00.
In general the events do seem more frequent when the FS is more full.
On Fri, 3 Jan 2025 at 01:40, Andres Freund <[email protected]> wrote:
> FWIW, I raised this on the #xfs irc channel. One ask they had was:
>
> │15:56:40 dchinner | andres: can you get a metadump of a filesystem that is displaying these symptoms for us to analyse?
> │15:57:54 dchinner | metadumps don't contain data, and metadata is obfuscated so no filenames or attributes are exposed, either.
I'm on leave from work at the moment, but I will try to collect this
when I'm back.
Cheers
Mike
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2025-01-30 23:53 Michael Harris <[email protected]>
parent: Michael Harris <[email protected]>
0 siblings, 0 replies; 16+ messages in thread
From: Michael Harris @ 2025-01-30 23:53 UTC (permalink / raw)
To: Andres Freund <[email protected]>; Robert Haas <[email protected]>; Jakub Wartak <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
Hello All
An update on this.
Earlier in this thread, Jakub had suggested remounting the XFS
filesystems with the mount option allocsize=1m.
I've done that now, on a few systems that have been experiencing this
error multiple times a day, and it does seem to stop the errors from
occurring.
It has only been a few days, but it does look encouraging as a workaround.
From the xfs man page, it seems that manually setting allocsize turns
off the dynamic preallocation size heuristics that are normally used
by XFS.
The other piece of info is that we have raised a support ticket with
Redhat. I'm not directly in contact with them (it's another team that
handles that) but I will let you know of any developments.
Cheers
Mike
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2026-02-05 07:15 Jakub Wartak <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 16+ messages in thread
From: Jakub Wartak @ 2026-02-05 07:15 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Michael Harris <[email protected]>; Robert Haas <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
On Thu, Feb 5, 2026 at 7:59 AM Andres Freund <[email protected]> wrote:
>
> Hi,
>
> On 2024-12-20 11:39:42 -0500, Andres Freund wrote:
> > On 2024-12-19 17:47:13 +1100, Michael Harris wrote:
> > > This is a different system to those I previously provided logs from.
> > > It is also running RHEL8 with a similar configuration to the other
> > > system.
> >
> > Given it's a RHEL system, have you raised this as an issue with RH? They
> > probably have somebody with actual XFS hacking experience on staff.
> >
> > RH's kernels are *heavily* patched, so it's possible the issue is actually RH
> > specific.
>
> FWIW, I raised this on the #xfs irc channel. One ask they had was:
>
> │15:56:40 dchinner | andres: can you get a metadump of a filesystem that is displaying these symptoms for us to analyse?
> │15:57:54 dchinner | metadumps don't contain data, and metadata is obfuscated so no filenames or attributes are exposed, either.
FWIW, I just learned yesterday that we went full circle on this:
Redhat has published [1] "XFS fallocate(2) returning ENOSPC
prematurely" several months ago. It references "commit
6773da870ab89123d1b513da63ed59e32a29cb77" titled "xfs: fix error
returns from xfs_bmapi_write" , so folks just need to update to proper
kernels. In addition we can do now:
postgresql_discovering_linux_kernel_bugs++. Quick search also shows
that e.g. linux-stable 6.1.x got it in 6.1.138 around May 2025, so
probably all kernels released before are all affected.
This pretty much matches the observation made earlier that it was
mainly hit by people upgrading databases on the same host without
updating OS/reinstalling hardware (re-using the older kernel).
BTW: from our side we also have workaround patch (with GUC for this)
solving 2nd problem and that is pending for inclusion in separate
thread[2]
-J.
[1] - https://access.redhat.com/solutions/7129010
[2] - https://www.postgresql.org/message-id/flat/CAKZiRmyDR5d7jdKdhL6TNKMtcY0fAaS-OQ3Bk3ZVejLZMrTCQw%40mai...
by Thomas.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2026-02-05 13:07 Thomas Munro <[email protected]>
parent: Jakub Wartak <[email protected]>
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Munro @ 2026-02-05 13:07 UTC (permalink / raw)
To: Jakub Wartak <[email protected]>; +Cc: Andres Freund <[email protected]>; Michael Harris <[email protected]>; Robert Haas <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
On Thu, Feb 5, 2026 at 8:16 PM Jakub Wartak
<[email protected]> wrote:
> FWIW, I just learned yesterday that we went full circle on this:
> Redhat has published [1] "XFS fallocate(2) returning ENOSPC
> prematurely" several months ago. It references "commit
> 6773da870ab89123d1b513da63ed59e32a29cb77" titled "xfs: fix error
> returns from xfs_bmapi_write" , so folks just need to update to proper
> kernels. In addition we can do now:
> postgresql_discovering_linux_kernel_bugs++. Quick search also shows
> that e.g. linux-stable 6.1.x got it in 6.1.138 around May 2025, so
> probably all kernels released before are all affected.
>
> This pretty much matches the observation made earlier that it was
> mainly hit by people upgrading databases on the same host without
> updating OS/reinstalling hardware (re-using the older kernel).
Good news. We had no hope of reproducing this, our kernels were fixed
:-). I can't read the paywalled article but the top mentions kernels
back to 4.18 (RHEL 8). Should be everywhere by now.
> BTW: from our side we also have workaround patch (with GUC for this)
> solving 2nd problem and that is pending for inclusion in separate
> thread[2]
Yeah, I'll push 0001 shortly to get it into the minor releases before
the freeze, as it's still useful for the BTRFS people. With this new
info I can improve the reference to unexplained XFS failures in the
commit message. Thanks!
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: FileFallocate misbehaving on XFS
@ 2026-02-05 17:14 Andrew Dunstan <[email protected]>
parent: Thomas Munro <[email protected]>
0 siblings, 0 replies; 16+ messages in thread
From: Andrew Dunstan @ 2026-02-05 17:14 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; Jakub Wartak <[email protected]>; +Cc: Andres Freund <[email protected]>; Michael Harris <[email protected]>; Robert Haas <[email protected]>; Alvaro Herrera <[email protected]>; Tomas Vondra <[email protected]>; pgsql-hackers
On 2026-02-05 Th 8:07 AM, Thomas Munro wrote:
> On Thu, Feb 5, 2026 at 8:16 PM Jakub Wartak
> <[email protected]> wrote:
>> BTW: from our side we also have workaround patch (with GUC for this)
>> solving 2nd problem and that is pending for inclusion in separate
>> thread[2]
> Yeah, I'll push 0001 shortly to get it into the minor releases before
> the freeze, as it's still useful for the BTRFS people. With this new
> info I can improve the reference to unexplained XFS failures in the
> commit message. Thanks!
>
+many for getting this into the maintenance releases.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 16+ messages in thread
end of thread, other threads:[~2026-02-05 17:14 UTC | newest]
Thread overview: 16+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-01-10 19:30 [PATCH] Set PD_ALL_VISIBLE and visibility map bits in COPY FREEZE Tomas Vondra <[email protected]>
2024-12-16 17:52 Re: FileFallocate misbehaving on XFS Andres Freund <[email protected]>
2024-12-16 23:23 ` Re: FileFallocate misbehaving on XFS Robert Haas <[email protected]>
2024-12-19 06:47 ` Re: FileFallocate misbehaving on XFS Michael Harris <[email protected]>
2024-12-20 12:25 ` Re: FileFallocate misbehaving on XFS Jakub Wartak <[email protected]>
2024-12-27 14:16 ` Re: FileFallocate misbehaving on XFS Bruce Momjian <[email protected]>
2024-12-20 16:39 ` Re: FileFallocate misbehaving on XFS Andres Freund <[email protected]>
2025-01-02 14:40 ` Re: FileFallocate misbehaving on XFS Andres Freund <[email protected]>
2025-01-04 04:34 ` Re: FileFallocate misbehaving on XFS Michael Harris <[email protected]>
2025-01-30 23:53 ` Re: FileFallocate misbehaving on XFS Michael Harris <[email protected]>
2026-02-05 07:15 ` Re: FileFallocate misbehaving on XFS Jakub Wartak <[email protected]>
2026-02-05 13:07 ` Re: FileFallocate misbehaving on XFS Thomas Munro <[email protected]>
2026-02-05 17:14 ` Re: FileFallocate misbehaving on XFS Andrew Dunstan <[email protected]>
2024-12-31 15:31 ` Re: FileFallocate misbehaving on XFS Andres Freund <[email protected]>
2025-01-02 10:41 ` Re: FileFallocate misbehaving on XFS Andrea Gelmini <[email protected]>
2025-01-02 14:38 ` Re: FileFallocate misbehaving on XFS Andres Freund <[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