public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 1/3] bootstrap: convert Typ to a List* 6+ messages / 3 participants [nested] [flat]
* [PATCH 1/3] bootstrap: convert Typ to a List* @ 2020-11-20 02:48 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Justin Pryzby @ 2020-11-20 02:48 UTC (permalink / raw) --- src/backend/bootstrap/bootstrap.c | 69 ++++++++++++++----------------- 1 file changed, 31 insertions(+), 38 deletions(-) diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c index 6f615e6622..18eb62ca47 100644 --- a/src/backend/bootstrap/bootstrap.c +++ b/src/backend/bootstrap/bootstrap.c @@ -159,7 +159,7 @@ struct typmap FormData_pg_type am_typ; }; -static struct typmap **Typ = NULL; +static List *Typ = NIL; /* List of struct typmap* */ static struct typmap *Ap = NULL; static Datum values[MAXATTR]; /* current row's attribute values */ @@ -597,7 +597,7 @@ boot_openrel(char *relname) * pg_type must be filled before any OPEN command is executed, hence we * can now populate the Typ array if we haven't yet. */ - if (Typ == NULL) + if (Typ == NIL) populate_typ_array(); if (boot_reldesc != NULL) @@ -688,7 +688,7 @@ DefineAttr(char *name, char *type, int attnum, int nullness) typeoid = gettype(type); - if (Typ != NULL) + if (Typ != NIL) { attrtypes[attnum]->atttypid = Ap->am_oid; attrtypes[attnum]->attlen = Ap->am_typ.typlen; @@ -877,36 +877,25 @@ populate_typ_array(void) Relation rel; TableScanDesc scan; HeapTuple tup; - int nalloc; - int i; - - Assert(Typ == NULL); - nalloc = 512; - Typ = (struct typmap **) - MemoryContextAlloc(TopMemoryContext, nalloc * sizeof(struct typmap *)); + Assert(Typ == NIL); rel = table_open(TypeRelationId, NoLock); scan = table_beginscan_catalog(rel, 0, NULL); - i = 0; while ((tup = heap_getnext(scan, ForwardScanDirection)) != NULL) { Form_pg_type typForm = (Form_pg_type) GETSTRUCT(tup); + struct typmap *newtyp; + MemoryContext old; - /* make sure there will be room for a trailing NULL pointer */ - if (i >= nalloc - 1) - { - nalloc *= 2; - Typ = (struct typmap **) - repalloc(Typ, nalloc * sizeof(struct typmap *)); - } - Typ[i] = (struct typmap *) - MemoryContextAlloc(TopMemoryContext, sizeof(struct typmap)); - Typ[i]->am_oid = typForm->oid; - memcpy(&(Typ[i]->am_typ), typForm, sizeof(Typ[i]->am_typ)); - i++; + old = MemoryContextSwitchTo(TopMemoryContext); + newtyp = (struct typmap *) palloc(sizeof(struct typmap)); + Typ = lappend(Typ, newtyp); + MemoryContextSwitchTo(old); + + newtyp->am_oid = typForm->oid; + memcpy(&newtyp->am_typ, typForm, sizeof(newtyp->am_typ)); } - Typ[i] = NULL; /* Fill trailing NULL pointer */ table_endscan(scan); table_close(rel, NoLock); } @@ -925,16 +914,17 @@ populate_typ_array(void) static Oid gettype(char *type) { - if (Typ != NULL) + if (Typ != NIL) { - struct typmap **app; + ListCell *lc; - for (app = Typ; *app != NULL; app++) + foreach (lc, Typ) { - if (strncmp(NameStr((*app)->am_typ.typname), type, NAMEDATALEN) == 0) + struct typmap *app = lfirst(lc); + if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0) { - Ap = *app; - return (*app)->am_oid; + Ap = app; + return app->am_oid; } } } @@ -980,14 +970,17 @@ boot_get_type_io_data(Oid typid, if (Typ != NULL) { /* We have the boot-time contents of pg_type, so use it */ - struct typmap **app; - struct typmap *ap; - - app = Typ; - while (*app && (*app)->am_oid != typid) - ++app; - ap = *app; - if (ap == NULL) + struct typmap *ap = NULL; + ListCell *lc; + + foreach (lc, Typ) + { + ap = lfirst(lc); + if (ap->am_oid == typid) + break; + } + + if (!ap || ap->am_oid != typid) elog(ERROR, "type OID %u not found in Typ list", typid); *typlen = ap->am_typ.typlen; -- 2.26.2 --------------76B8D0DC8AE327D516738282 Content-Type: text/x-patch; charset=UTF-8; name="0002-Allow-composite-types-in-bootstrap-20210108.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0002-Allow-composite-types-in-bootstrap-20210108.patch" ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: FileFallocate misbehaving on XFS @ 2024-12-10 00:31 Andres Freund <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Andres Freund @ 2024-12-10 00:31 UTC (permalink / raw) To: Michael Harris <[email protected]>; +Cc: Tomas Vondra <[email protected]>; pgsql-hackers Hi, On 2024-12-10 10:00:43 +1100, Michael Harris wrote: > On Mon, 9 Dec 2024 at 21:06, Tomas Vondra <[email protected]> wrote: > > Sounds more like an XFS bug/behavior, so it's not clear to me what we > > could do about it. I mean, if the filesystem reports bogus out-of-space, > > is there even something we can do? > > I don't disagree that it's most likely an XFS issue. However, XFS is > pretty widely used - it's the default FS for RHEL & the default in > SUSE for non-root partitions - so maybe some action should be taken. > > Some things we could consider: > > - Providing a way to configure PG not to use posix_fallocate at runtime > > - Detecting the use of XFS (probably nasty and complex to do in a > platform independent way) and disable posix_fallocate > > - In the case of posix_fallocate failing with ENOSPC, fall back to > FileZero (worst case that will fail as well, in which case we will > know that we really are out of space) > > - Documenting that XFS might not be a good choice, at least for some > kernel versions Pretty unexcited about all of these - XFS is fairly widely used for PG, but this problem doesn't seem very common. It seems to me that we're missing something that causes this to only happen in a small subset of cases. I think the source of this needs to be debugged further before we try to apply workarounds in postgres. Are you using any filesystem quotas? It'd be useful to get the xfs_info output that Jakub asked for. Perhaps also xfs_spaceman -c 'freesp -s' /mountpoint xfs_spaceman -c 'health' /mountpoint and df. What kind of storage is this on? Was the filesystem ever grown from a smaller size? Have you checked the filesystem's internal consistency? I.e. something like xfs_repair -n /dev/nvme2n1. It does require the filesystem to be read-only or unmounted though. But corrupted filesystem datastructures certainly could cause spurious ENOSPC. > > What is not clear to me is why would this affect pg_upgrade at all. We > > have the data files split into 1GB segments, and the copy/clone/... goes > > one by one. So there shouldn't be more than 1GB "extra" space needed. > > Surely you have more free space on the system? > > Yes, that also confused me. It actually fails during the schema > restore phase - where pg_upgrade calls pg_restore to restore a > schema-only dump that it takes earlier in the process. At this stage > it is only trying to restore the schema, not any actual table data. > Note that we use the --link option to pg_upgrade, so it should not be > using much space even when the table data is being upgraded. Are you using pg_upgrade -j? I'm asking because looking at linux's git tree I found this interesting recent commit: https://git.kernel.org/linus/94a0333b9212 - but IIUC it'd actually cause file creation, not fallocate to fail. > The filesystems have >1TB free space when this has occurred. > > It does continue to give this error after the upgrade, at apparently > random intervals, when data is being loaded into the DB using COPY > commands, so it might be best not to focus too much on the fact that > we first encounter it during the upgrade. I assume the file that actually errors out changes over time? It's always fallocate() that fails? Can you tell us anything about the workload / data? Lots of tiny tables, lots of big tables, write heavy, ...? Greetings, Andres Freund ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: FileFallocate misbehaving on XFS @ 2024-12-10 06:28 Michael Harris <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Michael Harris @ 2024-12-10 06:28 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Tomas Vondra <[email protected]>; pgsql-hackers Hi Andres Following up on the earlier question about OS upgrade paths - all the cases reported so far are either on RL8 (Kernel 4.18.0) or were upgraded to RL9 (kernel 5.14.0) and the affected filesystems were preserved. In fact the RL9 systems were initially built as Centos 7, and then when that went EOL they were upgraded to RL9. The process was as I described - the /var/opt filesystem which contained the database was preserved, and the root and other OS filesystems were scratched. The majority of systems where we have this problem are on RL8. On Tue, 10 Dec 2024 at 11:31, Andres Freund <[email protected]> wrote: > Are you using any filesystem quotas? No. > It'd be useful to get the xfs_info output that Jakub asked for. Perhaps also > xfs_spaceman -c 'freesp -s' /mountpoint > xfs_spaceman -c 'health' /mountpoint > and df. I gathered this info from one of the systems that is currently on RL9. This system is relatively small compared to some of the others that have exhibited this issue, but it is the only one I can access right now. # uname -a Linux 5.14.0-503.14.1.el9_5.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 15 12:04:32 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux # xfs_info /dev/mapper/ippvg-ipplv meta-data=/dev/mapper/ippvg-ipplv isize=512 agcount=4, agsize=262471424 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0, sparse=0, rmapbt=0 = reflink=0 bigtime=0 inobtcount=0 nrext64=0 data = bsize=4096 blocks=1049885696, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=512639, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 # for agno in `seq 0 3`; do xfs_spaceman -c "freesp -s -a $agno" /var/opt; done from to extents blocks pct 1 1 37502 37502 0.15 2 3 62647 148377 0.59 4 7 87793 465950 1.85 8 15 135529 1527172 6.08 16 31 184811 3937459 15.67 32 63 165979 7330339 29.16 64 127 101674 8705691 34.64 128 255 15123 2674030 10.64 256 511 973 307655 1.22 total free extents 792031 total free blocks 25134175 average free extent size 31.7338 from to extents blocks pct 1 1 43895 43895 0.22 2 3 59312 141693 0.70 4 7 83406 443964 2.20 8 15 120804 1362108 6.75 16 31 133140 2824317 14.00 32 63 118619 5188474 25.71 64 127 77960 6751764 33.46 128 255 16383 2876626 14.26 256 511 1763 546506 2.71 total free extents 655282 total free blocks 20179347 average free extent size 30.7949 from to extents blocks pct 1 1 72034 72034 0.26 2 3 98158 232135 0.83 4 7 126228 666187 2.38 8 15 169602 1893007 6.77 16 31 180286 3818527 13.65 32 63 164529 7276833 26.01 64 127 109687 9505160 33.97 128 255 22113 3921162 14.02 256 511 1901 592052 2.12 total free extents 944538 total free blocks 27977097 average free extent size 29.6199 from to extents blocks pct 1 1 51462 51462 0.21 2 3 98993 233204 0.93 4 7 131578 697655 2.79 8 15 178151 1993062 7.97 16 31 175718 3680535 14.72 32 63 145310 6372468 25.48 64 127 89518 7749021 30.99 128 255 18926 3415768 13.66 256 511 2640 813586 3.25 total free extents 892296 total free blocks 25006761 average free extent size 28.0252 # xfs_spaceman -c 'health' /var/opt Health status has not been collected for this filesystem. > What kind of storage is this on? As mentioned, there are quite a few systems in different sites, so a number of different storage solutions in use, some with directly attached disks, others with some SAN solutions. The instance I got the printout above from is a VM, but in the other site they are all bare metal. > Was the filesystem ever grown from a smaller size? I can't say for sure that none of them were, but given the number of different systems that have this issue I am confident that would not be a common factor. > Have you checked the filesystem's internal consistency? I.e. something like > xfs_repair -n /dev/nvme2n1. It does require the filesystem to be read-only or > unmounted though. But corrupted filesystem datastructures certainly could > cause spurious ENOSPC. I executed this on the same system as the above prints came from. It did not report any issues. > Are you using pg_upgrade -j? Yes, we use -j `nproc` > I assume the file that actually errors out changes over time? It's always > fallocate() that fails? Yes, correct, on both counts. > Can you tell us anything about the workload / data? Lots of tiny tables, lots > of big tables, write heavy, ...? It is a write heavy application which stores mostly time series data. The time series data is partitioned by time; the application writes constantly into the 'current' partition, and data is expired by removing the oldest partition. Most of the data is written once and not updated. There are quite a lot of these partitioned tables (in the 1000's or 10000's) depending on how the application is configured. Individual partitions range in size from a few MB to 10s of GB. Cheers Mike. ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: FileFallocate misbehaving on XFS @ 2024-12-10 16:09 Andres Freund <[email protected]> parent: Michael Harris <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Andres Freund @ 2024-12-10 16:09 UTC (permalink / raw) To: Michael Harris <[email protected]>; +Cc: Tomas Vondra <[email protected]>; pgsql-hackers Hi, On 2024-12-10 17:28:21 +1100, Michael Harris wrote: > On Tue, 10 Dec 2024 at 11:31, Andres Freund <[email protected]> wrote: > > It'd be useful to get the xfs_info output that Jakub asked for. Perhaps also > > xfs_spaceman -c 'freesp -s' /mountpoint > > xfs_spaceman -c 'health' /mountpoint > > and df. > > I gathered this info from one of the systems that is currently on RL9. > This system is relatively small compared to some of the others that > have exhibited this issue, but it is the only one I can access right > now. I think it's implied, but I just want to be sure: This was one of the affected systems? > # uname -a > Linux 5.14.0-503.14.1.el9_5.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 15 > 12:04:32 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux > > # xfs_info /dev/mapper/ippvg-ipplv > meta-data=/dev/mapper/ippvg-ipplv isize=512 agcount=4, agsize=262471424 blks > = sectsz=512 attr=2, projid32bit=1 > = crc=1 finobt=0, sparse=0, rmapbt=0 > = reflink=0 bigtime=0 inobtcount=0 nrext64=0 > data = bsize=4096 blocks=1049885696, imaxpct=5 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0, ftype=1 > log =internal log bsize=4096 blocks=512639, version=2 > = sectsz=512 sunit=0 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 It might be interesting that finobt=0, sparse=0 and nrext64=0. Those all affect space allocation to some degree and more recently created filesystems will have them to different values, which could explain why you but not that many others hit this issue. Any chance to get df output? I'm mainly curious about the number of used inodes. Could you show the mount options that end up being used? grep /var/opt /proc/mounts I rather doubt it is, but it'd sure be interesting if inode32 were used. I assume you have never set XFS options for the PG directory or files within it? Could you show xfs_io -r -c lsattr -c stat -c statfs /path/to/directory/with/enospc ? > # for agno in `seq 0 3`; do xfs_spaceman -c "freesp -s -a $agno" /var/opt; done > from to extents blocks pct > 1 1 37502 37502 0.15 > 2 3 62647 148377 0.59 > 4 7 87793 465950 1.85 > 8 15 135529 1527172 6.08 > 16 31 184811 3937459 15.67 > 32 63 165979 7330339 29.16 > 64 127 101674 8705691 34.64 > 128 255 15123 2674030 10.64 > 256 511 973 307655 1.22 > total free extents 792031 > total free blocks 25134175 > average free extent size 31.7338 > from to extents blocks pct > 1 1 43895 43895 0.22 > 2 3 59312 141693 0.70 > 4 7 83406 443964 2.20 > 8 15 120804 1362108 6.75 > 16 31 133140 2824317 14.00 > 32 63 118619 5188474 25.71 > 64 127 77960 6751764 33.46 > 128 255 16383 2876626 14.26 > 256 511 1763 546506 2.71 > total free extents 655282 > total free blocks 20179347 > average free extent size 30.7949 > from to extents blocks pct > 1 1 72034 72034 0.26 > 2 3 98158 232135 0.83 > 4 7 126228 666187 2.38 > 8 15 169602 1893007 6.77 > 16 31 180286 3818527 13.65 > 32 63 164529 7276833 26.01 > 64 127 109687 9505160 33.97 > 128 255 22113 3921162 14.02 > 256 511 1901 592052 2.12 > total free extents 944538 > total free blocks 27977097 > average free extent size 29.6199 > from to extents blocks pct > 1 1 51462 51462 0.21 > 2 3 98993 233204 0.93 > 4 7 131578 697655 2.79 > 8 15 178151 1993062 7.97 > 16 31 175718 3680535 14.72 > 32 63 145310 6372468 25.48 > 64 127 89518 7749021 30.99 > 128 255 18926 3415768 13.66 > 256 511 2640 813586 3.25 > total free extents 892296 > total free blocks 25006761 > average free extent size 28.0252 So there's *some*, but not a lot, of imbalance in AG usage. Of course that's as of this moment, and as you say below, you expire old partitions on a regular basis... My understanding of XFS's space allocation is that by default it continues to use the same AG for allocations within one directory, until that AG is full. For a write heavy postgres workload that's of course not optimal, as all activity will focus on one AG. I'd try monitoring the per-ag free space over time and see if the the ENOSPC issue is correlated with one AG getting full. 'freesp' is probably too expensive for that, but it looks like xfs_db -r -c agresv /dev/nvme6n1 should work? Actually that output might be interesting to see, even when you don't hit the issue. > > Can you tell us anything about the workload / data? Lots of tiny tables, lots > > of big tables, write heavy, ...? > > It is a write heavy application which stores mostly time series data. > > The time series data is partitioned by time; the application writes > constantly into the 'current' partition, and data is expired by > removing the oldest partition. Most of the data is written once and > not updated. > > There are quite a lot of these partitioned tables (in the 1000's or > 10000's) depending on how the application is configured. Individual > partitions range in size from a few MB to 10s of GB. So there are 1000s of tables that are concurrently being appended, but only into one partition each. That does make it plausible that there's a significant amount of fragmentation. Possibly transient due to the expiration. How many partitions are there for each of the tables? Mainly wondering because of the number of inodes being used. Are all of the active tables within one database? That could be relevant due to per-directory behaviour of free space allocation. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: FileFallocate misbehaving on XFS @ 2024-12-11 01:09 Michael Harris <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Michael Harris @ 2024-12-11 01:09 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Tomas Vondra <[email protected]>; pgsql-hackers Hi Andres On Wed, 11 Dec 2024 at 03:09, Andres Freund <[email protected]> wrote: > I think it's implied, but I just want to be sure: This was one of the affected > systems? Yes, correct. > Any chance to get df output? I'm mainly curious about the number of used > inodes. Sorry, I could swear I had included that already! Here it is: # df /var/opt Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/ippvg-ipplv 4197492228 3803866716 393625512 91% /var/opt # df -i /var/opt Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/ippvg-ipplv 419954240 1568137 418386103 1% /var/opt > Could you show the mount options that end up being used? > grep /var/opt /proc/mounts /dev/mapper/ippvg-ipplv /var/opt xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0 These seem to be the defaults. > I assume you have never set XFS options for the PG directory or files within > it? Correct. > Could you show > xfs_io -r -c lsattr -c stat -c statfs /path/to/directory/with/enospc -p--------------X pg_tblspc/16402/PG_16_202307071/49163/1132925906.4 fd.path = "pg_tblspc/16402/PG_16_202307071/49163/1132925906.4" fd.flags = non-sync,non-direct,read-only stat.ino = 4320612794 stat.type = regular file stat.size = 201211904 stat.blocks = 393000 fsxattr.xflags = 0x80000002 [-p--------------X] fsxattr.projid = 0 fsxattr.extsize = 0 fsxattr.cowextsize = 0 fsxattr.nextents = 165 fsxattr.naextents = 0 dioattr.mem = 0x200 dioattr.miniosz = 512 dioattr.maxiosz = 2147483136 fd.path = "pg_tblspc/16402/PG_16_202307071/49163/1132925906.4" statfs.f_bsize = 4096 statfs.f_blocks = 1049373057 statfs.f_bavail = 98406378 statfs.f_files = 419954240 statfs.f_ffree = 418386103 statfs.f_flags = 0x1020 geom.bsize = 4096 geom.agcount = 4 geom.agblocks = 262471424 geom.datablocks = 1049885696 geom.rtblocks = 0 geom.rtextents = 0 geom.rtextsize = 1 geom.sunit = 0 geom.swidth = 0 counts.freedata = 98406378 counts.freertx = 0 counts.freeino = 864183 counts.allocino = 2432320 > I'd try monitoring the per-ag free space over time and see if the the ENOSPC > issue is correlated with one AG getting full. 'freesp' is probably too > expensive for that, but it looks like > xfs_db -r -c agresv /dev/nvme6n1 > should work? > > Actually that output might be interesting to see, even when you don't hit the > issue. I will see if I can set that up. > How many partitions are there for each of the tables? Mainly wondering because > of the number of inodes being used. It is configurable and varies from site to site. It could range from 7 up to maybe 60. > Are all of the active tables within one database? That could be relevant due > to per-directory behaviour of free space allocation. Each pg instance may have one or more application databases. Typically data is being written into all of them (although sometimes a database will be archived, with no new data going into it). You might be onto something though. The system I got the above prints from is only experiencing this issue in one directory - that might not mean very much though, it only has 2 databases and one of them looks like it is not receiving imports. But another system I can access has multiple databases with ongoing imports, yet all the errors bar one relate to one directory. I will collect some data from that system and post it shortly. Cheers Mike ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: FileFallocate misbehaving on XFS @ 2024-12-11 07:40 Michael Harris <[email protected]> parent: Michael Harris <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Michael Harris @ 2024-12-11 07:40 UTC (permalink / raw) To: Andres Freund <[email protected]>; Jakub Wartak <[email protected]>; Robert Haas <[email protected]>; +Cc: Tomas Vondra <[email protected]>; pgsql-hackers Hi again On Wed, 11 Dec 2024 at 12:09, Michael Harris <[email protected]> wrote: > But another system I can access has multiple databases with ongoing > imports, yet all the errors bar one relate to one directory. > I will collect some data from that system and post it shortly. I've attached the same set of data collected from an RHEL8 system. Unfortunately the 'agresv' subcommand does not exist in the version of xfs_db that is available on RHEL8, so I was not able to implement that suggestion. I thought I had one *L8 system that had an XFS filesystem and had not experienced this issue, but it turns out it had - just at a much lower frequency. Cheers Mike Attachments: [application/octet-stream] rhel8_fallocate_fail.log (34.3K, ../../CADofcAVVA1hv+yZQQh42+oiBh2xm=eYAiWbnpDqRj8iy9A024A@mail.gmail.com/2-rhel8_fallocate_fail.log) download ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-12-11 07:40 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-20 02:48 [PATCH 1/3] bootstrap: convert Typ to a List* Justin Pryzby <[email protected]> 2024-12-10 00:31 Re: FileFallocate misbehaving on XFS Andres Freund <[email protected]> 2024-12-10 06:28 ` Re: FileFallocate misbehaving on XFS Michael Harris <[email protected]> 2024-12-10 16:09 ` Re: FileFallocate misbehaving on XFS Andres Freund <[email protected]> 2024-12-11 01:09 ` Re: FileFallocate misbehaving on XFS Michael Harris <[email protected]> 2024-12-11 07:40 ` Re: FileFallocate misbehaving on XFS Michael Harris <[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