Pushed.
I wasn't sure it was worth keeping the test in the tree. It's here in
the mailing list archives for future reference.
be
called whenever free pages are returned to the segment's free page map.
Back-patch to all supported releases.
Author: Dongming Liu
Reviewed-by: Robert Haas (earlier version)
Reviewed-by: Thomas Munro
Discussion:
https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ
be
called whenever free pages are returned to the segment's free page map.
Back-patch to all supported releases.
Author: Dongming Liu
Reviewed-by: Robert Haas (earlier version)
Reviewed-by: Thomas Munro
Discussion:
https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ
be
called whenever free pages are returned to the segment's free page map.
Back-patch to all supported releases.
Author: Dongming Liu
Reviewed-by: Robert Haas (earlier version)
Reviewed-by: Thomas Munro
Discussion:
https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ
be
called whenever free pages are returned to the segment's free page map.
Back-patch to all supported releases.
Author: Dongming Liu
Reviewed-by: Robert Haas (earlier version)
Reviewed-by: Thomas Munro
Discussion:
https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ
be
called whenever free pages are returned to the segment's free page map.
Back-patch to all supported releases.
Author: Dongming Liu
Reviewed-by: Robert Haas (earlier version)
Reviewed-by: Thomas Munro
Discussion:
https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ
be
called whenever free pages are returned to the segment's free page map.
Back-patch to all supported releases.
Author: Dongming Liu
Reviewed-by: Robert Haas (earlier version)
Reviewed-by: Thomas Munro
Discussion:
https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ
be
called whenever free pages are returned to the segment's free page map.
Back-patch to all supported releases.
Author: Dongming Liu
Reviewed-by: Robert Haas (earlier version)
Reviewed-by: Thomas Munro
Discussion:
https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ
On Mon, Jun 12, 2023 at 8:53 PM David Steele wrote:
> + if (strcmp(endptr, "kB") == 0)
>
> Why kB here instead of KB to match MB, GB, TB below?
Those are SI prefixes[1], and we use kB elsewhere too. ("K" was used
for kelvins, so they went with "k" for kilo. Obviously these aren't
Fix race in SSI interaction with bitmap heap scan.
When performing a bitmap heap scan, we don't want to miss concurrent
writes that occurred after we observed the heap's rs_nblocks, but before
we took predicate locks on index pages. Therefore, we can't skip
fetching any heap tuples that are
Fix race in SSI interaction with empty btrees.
When predicate-locking btrees, we have a special case for completely
empty btrees, since there is no page to lock. This was racy, because,
without buffer lock held, a matching key could be inserted between the
_bt_search() and the
Fix race in SSI interaction with gin fast path.
The ginfast.c code previously checked for conflicts in before locking
the relevant buffer, leaving a window where a RW conflict could be
missed. Re-order.
There was also a place where buffer ID and block number were confused
while trying to
Fix race in SSI interaction with bitmap heap scan.
When performing a bitmap heap scan, we don't want to miss concurrent
writes that occurred after we observed the heap's rs_nblocks, but before
we took predicate locks on index pages. Therefore, we can't skip
fetching any heap tuples that are
Fix race in SSI interaction with empty btrees.
When predicate-locking btrees, we have a special case for completely
empty btrees, since there is no page to lock. This was racy, because,
without buffer lock held, a matching key could be inserted between the
_bt_search() and the
Fix race in SSI interaction with gin fast path.
The ginfast.c code previously checked for conflicts in before locking
the relevant buffer, leaving a window where a RW conflict could be
missed. Re-order.
There was also a place where buffer ID and block number were confused
while trying to
Fix race in SSI interaction with bitmap heap scan.
When performing a bitmap heap scan, we don't want to miss concurrent
writes that occurred after we observed the heap's rs_nblocks, but before
we took predicate locks on index pages. Therefore, we can't skip
fetching any heap tuples that are
Fix race in SSI interaction with empty btrees.
When predicate-locking btrees, we have a special case for completely
empty btrees, since there is no page to lock. This was racy, because,
without buffer lock held, a matching key could be inserted between the
_bt_search() and the
Fix race in SSI interaction with gin fast path.
The ginfast.c code previously checked for conflicts in before locking
the relevant buffer, leaving a window where a RW conflict could be
missed. Re-order.
There was also a place where buffer ID and block number were confused
while trying to
Fix race in SSI interaction with empty btrees.
When predicate-locking btrees, we have a special case for completely
empty btrees, since there is no page to lock. This was racy, because,
without buffer lock held, a matching key could be inserted between the
_bt_search() and the
Fix race in SSI interaction with gin fast path.
The ginfast.c code previously checked for conflicts in before locking
the relevant buffer, leaving a window where a RW conflict could be
missed. Re-order.
There was also a place where buffer ID and block number were confused
while trying to
Fix race in SSI interaction with bitmap heap scan.
When performing a bitmap heap scan, we don't want to miss concurrent
writes that occurred after we observed the heap's rs_nblocks, but before
we took predicate locks on index pages. Therefore, we can't skip
fetching any heap tuples that are
Fix race in SSI interaction with empty btrees.
When predicate-locking btrees, we have a special case for completely
empty btrees, since there is no page to lock. This was racy, because,
without buffer lock held, a matching key could be inserted between the
_bt_search() and the
Fix race in SSI interaction with bitmap heap scan.
When performing a bitmap heap scan, we don't want to miss concurrent
writes that occurred after we observed the heap's rs_nblocks, but before
we took predicate locks on index pages. Therefore, we can't skip
fetching any heap tuples that are
Fix race in SSI interaction with gin fast path.
The ginfast.c code previously checked for conflicts in before locking
the relevant buffer, leaving a window where a RW conflict could be
missed. Re-order.
There was also a place where buffer ID and block number were confused
while trying to
Fix race in SSI interaction with bitmap heap scan.
When performing a bitmap heap scan, we don't want to miss concurrent
writes that occurred after we observed the heap's rs_nblocks, but before
we took predicate locks on index pages. Therefore, we can't skip
fetching any heap tuples that are
Fix race in SSI interaction with empty btrees.
When predicate-locking btrees, we have a special case for completely
empty btrees, since there is no page to lock. This was racy, because,
without buffer lock held, a matching key could be inserted between the
_bt_search() and the
Fix race in SSI interaction with gin fast path.
The ginfast.c code previously checked for conflicts in before locking
the relevant buffer, leaving a window where a RW conflict could be
missed. Re-order.
There was also a place where buffer ID and block number were confused
while trying to
Fix race in SSI interaction with empty btrees.
When predicate-locking btrees, we have a special case for completely
empty btrees, since there is no page to lock. This was racy, because,
without buffer lock held, a matching key could be inserted between the
_bt_search() and the
Fix race in SSI interaction with gin fast path.
The ginfast.c code previously checked for conflicts in before locking
the relevant buffer, leaving a window where a RW conflict could be
missed. Re-order.
There was also a place where buffer ID and block number were confused
while trying to
Fix race in SSI interaction with bitmap heap scan.
When performing a bitmap heap scan, we don't want to miss concurrent
writes that occurred after we observed the heap's rs_nblocks, but before
we took predicate locks on index pages. Therefore, we can't skip
fetching any heap tuples that are
On Tue, Jul 4, 2023 at 6:46 AM Daniel Gustafsson wrote:
> > On 3 Jul 2023, at 20:32, Yurii Rashkovskii wrote:
> > If there's a willingness to try this out, I am happy to prepare a patch.
>
> This has been discussed a number of times in the past, and the conclusion from
> last time IIRC was to
On Mon, Jul 3, 2023 at 4:26 PM Michael Paquier wrote:
> I have not gone back to this part yet, though I plan to do so. As we
> are at the beginning of the development cycle, I have applied the
> patch to remove support for 1.0.1 for now on HEAD. Let's see what the
> buildfarm tells.
curculio
On Mon, Jul 3, 2023 at 6:13 PM Peter Eisentraut wrote:
> On 27.06.23 17:02, Tristan Partin wrote:
> > This is a patch which implements an issue discussed in bug #17946[0]. It
> > doesn't fix the overarching issue of the bug, but merely a consistency
> > issue which was found while analyzing code
On Sun, Jul 2, 2023 at 4:25 AM Noah Misch wrote:
> On Wed, Jun 28, 2023 at 01:02:21PM +1200, Thomas Munro wrote:
> > On Wed, Jun 28, 2023 at 11:03 AM Thomas Munro
> > wrote:
> > > The GCC build farm has just received some SPARC hardware new enough to
> > > ru
On Mon, Jul 3, 2023 at 6:12 AM Tomas Vondra
wrote:
> On 7/2/23 04:09, Thomas Munro wrote:
> > When I added that new error I was thinking about that third case. We
> > generally expect to detect the end of WAL replay after a crash with an
> > error ("invalid record le
Silence "missing contrecord" error.
Commit dd38ff28ad added a new error message "missing contrecord" when
we fail to reassemble a record. Unfortunately that caused noisy
messages to be logged by pg_waldump at end of segment, and by walsender
when asked to shut down on a segment boundary.
Remove
Silence "missing contrecord" error.
Commit dd38ff28ad added a new error message "missing contrecord" when
we fail to reassemble a record. Unfortunately that caused noisy
messages to be logged by pg_waldump at end of segment, and by walsender
when asked to shut down on a segment boundary.
Remove
Silence "missing contrecord" error.
Commit dd38ff28ad added a new error message "missing contrecord" when
we fail to reassemble a record. Unfortunately that caused noisy
messages to be logged by pg_waldump at end of segment, and by walsender
when asked to shut down on a segment boundary.
Remove
Trust signalfd on illumos, again.
Commit 3ab4fc5d avoided choosing signalfd by default on illumos, because
it triggered kernel panics. That was fixed, so we can remove a kludge
from our code. Users/packagers can still override the default choice at
compile time if desired, and we'll leave the
uot; from "unexpectedly ran out of
data" for v17?
[1]
https://www.postgresql.org/message-id/ca+hukg+wkszpdoryeqm8_rk5uqpcqs2hgy92wimgfsk2wvk...@mail.gmail.com
From a6fbff139d27f53cf39521e0e78b734c59fd8211 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Sun, 2 Jul 2023 13:07:17 +1200
Subject: [PATCH] Sile
On Sat, May 20, 2023 at 10:01 AM Jacob Champion wrote:
> - The client implementation is currently epoll-/Linux-specific. I think
> kqueue shouldn't be too much trouble for the BSDs, but it's even more
> code to maintain.
I guess you also need a fallback that uses plain old POSIX poll()? I
see
On Fri, Jun 30, 2023 at 10:47 PM Palak Chaturvedi
wrote:
> pgbench=# select count(pg_buffercache_invalidate(bufferid)) from
> pg_buffercache where relfilenode =
> pg_relation_filenode('pgbench_accounts'::regclass);
Hi Palak,
Thanks for working on this! I think this will be very useful for
-check the race for
> increasing the usage count of the wrong buffer is quite small, without the
> pre-check it doesn't seem that small anymore.
Yeah, that makes sense. Done in this version.
From d5b9f345961e2adb31213c645e40037f15ba6a83 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Thu,
itself, in later work on lock-free
tricks.
Experimental patches attached.
From b91d996c691077a7fa48718c933159136d650e77 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Thu, 29 Jun 2023 10:52:56 +1200
Subject: [PATCH 1/2] Improve ReadRecentBuffer() scalability.
While testing a new potential use
On Wed, Jun 28, 2023 at 11:03 AM Thomas Munro wrote:
> The GCC build farm has just received some SPARC hardware new enough to
> run modern Solaris (hostname gcc106), so if wrasse were moved over
> there we could finally assume all systems have POSIX 2008 (AKA
> SUSv4)'s locale_t.
Tha
The GCC build farm has just received some SPARC hardware new enough to
run modern Solaris (hostname gcc106), so if wrasse were moved over
there we could finally assume all systems have POSIX 2008 (AKA
SUSv4)'s locale_t.
It's slightly annoying that Windows has locale_t but doesn't have
On Tue, Jun 27, 2023 at 4:53 PM Peter Geoghegan wrote:
> On Mon, Jun 26, 2023 at 9:40 PM Thomas Munro wrote:
> > If the goal is to get rid of both pins and content locks, LSN isn't
> > enough. A page might be evicted and replaced by another page that has
> > the same
On Tue, Jun 27, 2023 at 4:32 PM Peter Geoghegan wrote:
> On Mon, Jun 26, 2023 at 9:09 PM Andres Freund wrote:
> > I think we should be able to have a post-check that can figure out
> > if the copied root page is out of date after searching it, without needing
> > the
> > content lock.
>
> I'm
On Tue, Jun 27, 2023 at 2:05 PM Andres Freund wrote:
> As mentioned nearby [1], Thomas brought up [2] the idea of using
> ReadRecentBuffer() _bt_getroot(). I couldn't resist and prototyped it.
Thanks!
> Unfortunately it scaled way worse at first. This is not an inherent issue, but
> due to an
On Tue, Jun 20, 2023 at 6:48 AM Jeff Davis wrote:
> On Sat, 2023-06-17 at 17:54 +1200, Thomas Munro wrote:
> > > Would it be correct to interpret LC_COLLATE=C.UTF-8 as
> > > LC_COLLATE=C,
> > > but leave LC_CTYPE=C.UTF-8 as-is?
> >
> > Yes. T
On Sat, Jun 17, 2023 at 10:03 AM Jeff Davis wrote:
> On Thu, 2023-06-15 at 19:15 +1200, Thomas Munro wrote:
> > Hmm, OK let's explore that. What could we do that would be helpful
> > here, without affecting users of the "true" C.UTF-8 for the rest of
> > time?
On Sun, Apr 23, 2023 at 5:22 AM Daniel Verite wrote:
> I understand that my proposal to version C.* like any other collation
> might be erring on the side of caution, but ignoring these collation
> changes on at least one major OS does not feel right either.
> Maybe we should consider doing
On Thu, Jun 15, 2023 at 2:51 PM Vladimir Churyukin
wrote:
> Do you foresee any difficulties in implementation of the "unwarm" operation?
> It requires a cache flush operation,
> so I'm curious how complicated that is (probably there is a reason this is
> not supported by Postgres by now? mssql
On Thu, Jun 15, 2023 at 1:37 PM Vladimir Churyukin
wrote:
> Ok, got it, thanks.
> Is there any alternative approach to measuring the performance as if the
> cache was empty?
There are two levels of cache. If you're on Linux you can ask it to
drop its caches by writing certain values to
On Wed, Jun 14, 2023 at 10:50 PM Juan José Santamaría Flecha
wrote:
> Yes, I think the situation is quite similar to what you describe, with its
> WIN32 peculiarities. Take for example the attached program, it'll output:
>
> s1 = s2
> s2 = s3
> s1 > s3
> c1 > c2
> c2 > c3
> c1 > c3
>
> As you
On Thu, Jun 15, 2023 at 10:55 AM Jeff Davis wrote:
> The locale "C" (and equivalently, "POSIX") is not really a libc locale;
> it's implemented internally with memcmp for collation and
> pg_ascii_tolower, etc., for ctype.
>
> The attached patch implements a new collation provider, "builtin",
>
're using it, you
probably want to know that it isn't available anymore and think about
the implications for your application).
From 3e2b3f3b20ce83737f3421ab3c7794853724266d Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Wed, 14 Jun 2023 13:41:37 +1200
Subject: [PATCH] Remove old_snapshot_threshold.
Trying to follow along here... you're doing the moral equivalent of
strxfrm(), so sort keys have the transitive property but direct string
comparisons don't? Or is this because LCIDs reach a different
algorithm somehow (or otherwise why do you need to use LCIDs for this,
when there is a non-LCID
On Mon, Feb 20, 2023 at 5:52 PM Thomas Munro wrote:
> I'm wondering about this bit in rebin_segment():
>
> + if (segment_map->header == NULL)
> + return;
>
> Why would we be rebinning an uninitialised/unused segment?
Answering my own question: because des
On Mon, Apr 17, 2023 at 8:00 AM Thomas Munro wrote:
> On Sun, Dec 18, 2022 at 10:27 AM Thomas Munro wrote:
> > With my garbage collector hat on, that made me wonder if there was
> > some more potential cleanup here: could we require locale_t yet? The
> > last straggler sys
On Thu, May 18, 2023 at 8:53 PM Wei Wang (Fujitsu)
wrote:
> On Sat, April 1, 2023 at 11:00 AM Thomas Munro wrote:
> I tried to test this patch on Windows. And I did cover the new code path
> below:
> ```
> + /* We have another event to decode. */
> +
On Fri, Jun 9, 2023 at 4:00 AM Andres Freund wrote:
> On 2023-06-08 12:15:58 +0200, Hannu Krosing wrote:
> > > This part was touched in the "AMA with a Linux Kernale Hacker"
> > > Unconference session where he mentioned that the had proposed a
> > > 'mshare' syscall for this.
>
> As-is that'd
On Fri, Jun 9, 2023 at 5:02 AM Ilya Anfimov wrote:
> Isn't all the memory operations would require nearly the same
> shared memory allocators if someone switches to a threaded imple-
> mentation?
It's true that we'd need concurrency-aware MemoryContext
implementations (details can be
On Thu, Jun 8, 2023 at 10:37 AM Jeremy Schneider
wrote:
> On 6/7/23 2:39 PM, Thomas Kellerer wrote:
> > Tomas Vondra schrieb am 07.06.2023 um 21:20:
> >> Also, which other projects did this transition? Is there something we
> >> could learn from them? Were they restricted to much smaller list of
On Thu, Jun 8, 2023 at 7:20 AM Tomas Vondra
wrote:
> Is the platform support really there for all platforms we want/intend to
> support? I have no problem believing that for modern Linux/BSD systems,
> but what about the older stuff we currently support.
There is a conversation to be had about
On Tue, Jun 6, 2023 at 6:52 AM Andrew Dunstan wrote:
> If we were starting out today we would probably choose a threaded
> implementation. But moving to threaded now seems to me like a
> multi-year-multi-person project with the prospect of years to come chasing
> bugs and the prospect of
On Tue, Jun 6, 2023 at 1:30 PM Thomas Munro wrote:
> On Tue, Jun 6, 2023 at 10:08 AM Daniel Verite wrote:
> > Also, it does not occur at all if parallel scan is disabled.
>
> Could this be a clue that it is failing to be transitive?
That vaguely rang a bell for me... and th
On Tue, Jun 6, 2023 at 10:08 AM Daniel Verite wrote:
> Also, it does not occur at all if parallel scan is disabled.
Could this be a clue that it is failing to be transitive?
On Mon, Jun 5, 2023 at 12:56 PM Daniel Verite wrote:
> postgres=# select collversion,count(*) from pg_collation group by
> collversion;
> collversion | count
> ---+---
>| 5
> 1539.5,1539.5 | 1457
> (2 rows)
>
> According to [1] the second number is
571e68a2948c5bff9fa1d66f382c859fc6606829 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Fri, 2 Jun 2023 13:35:54 -0400
Subject: [PATCH] Add --copy-file-range option to pg_upgrade.
The copy_file_range() system call is available on at least Linux and
FreeBSD, and asks the kernel to use efficient ways to copy ranges of a
file
On Sun, May 28, 2023 at 2:48 AM Thomas Munro wrote:
> (you'd need over 2 billion
> directories ...
directory *entries* (segment files), I meant to write there.
On Thu, May 25, 2023 at 1:08 PM Stephen Frost wrote:
> * Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> > On 24.05.23 02:34, Thomas Munro wrote:
> > > * pg_upgrade would convert if source and target don't match
> >
> > This would be good, but it coul
On Thu, May 25, 2023 at 12:34 PM Tom Lane wrote:
> Dunno about antique MIPS. I think there's still some interest in
> not-antique 32-bit MIPS; I have some current-production routers
> with such CPUs. (Sadly, they don't have enough storage to do
> anything useful with, or I'd think about
On Thu, May 25, 2023 at 11:51 AM Tom Lane wrote:
> Andres Freund writes:
> > On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
> > So it looks like the only certain problem is PA-RISC - which I personally
> > wouldn't include in "relevant" :), with some evaluation needed for 32bit
> > mips
> > and
Thanks all for the feedback. It was a nice idea and it *almost*
works, but it seems like we just can't drop segmented mode. And the
automatic transition schemes I showed don't make much sense without
that goal.
What I'm hearing is that something simple like this might be more acceptable:
*
Oh, one important thing I forgot to mention: that patch is for LLVM 16
only, and I developed it with a local build of their "release/16.x"
branch on a FreeBSD box, and also tested with a released package for
16 on a Debian box. Further changes are already needed for their
"main" branch (LLVM
as they
catch some classes of silly mistake that otherwise just segfault
inscrutably on execution.
[1] https://llvm.org/docs/GetElementPtr.html
From 996e4bceee21a9f27116623c1fdac8eab0cdf814 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Mon, 9 May 2022 08:27:47 +1200
Subject: [PATCH] jit: S
On Wed, May 17, 2023 at 2:57 AM Jonathan S. Katz wrote:
> On 3/31/23 11:00 PM, Thomas Munro wrote:
> >>> I mention this now because I'm not sure whether to consider this an
> >>> 'open item' for 16, or merely an enhancement for 17. I guess the
> >>> former
On Fri, May 12, 2023 at 11:58 PM Bharath Rupireddy
wrote:
> Andres, rightly put it - 'mis-using' CV infrastructure. It is simple,
> works, and makes the WalSndWakeup() easy solving the performance
> regression.
Yeah, this seems OK, and better than the complicated alternatives. If
one day we
On Mon, May 15, 2023 at 2:57 PM Michael Paquier wrote:
> On Mon, May 15, 2023 at 02:08:32PM +1200, Thomas Munro wrote:
> > After 495ed0e, do these references to Windows SDK 8.1 still make sense?
> As listed on https://en.wikipedia.org/wiki/Microsoft_Windows_SDK,
> likely not. Wh
After 495ed0e, do these references to Windows SDK 8.1 still make sense?
src/sgml/install-windows.sgml: as well as standalone Windows SDK
releases 8.1a to 10.
src/sgml/install-windows.sgml: Microsoft Windows
SDK version 8.1a to 10 or
On Sat, Apr 8, 2023 at 5:21 PM Andres Freund wrote:
> On 2023-04-08 13:18:55 +1200, Thomas Munro wrote:
> > Subject: [PATCH] Fix default wal_writer_flush_after value.
> LGTM.
Thanks, pushed.
On Mon, May 15, 2023 at 9:09 AM Noah Misch wrote:
> This looks reasonable.
Pushed with a small change: a couple of GUC_check_errdetail strings
needed s/io_direct/debug_io_direct/. Thanks.
Fix wal_writer_flush_after initializer value.
Commit a73952b7956 (new in 16) required default values in guc_table.c
and C variable initializers to match. This one only matched when
XLOG_BLCKSZ == 8kB. Fix by using the same expression in both places
with a new DEFAULT_XXX macro, as done for
Rename io_direct to debug_io_direct.
Give the new GUC introduced by d4e71df6 a name that is clearly not
intended for mainstream use quite yet.
Future proposals would drop the prefix only after adding infrastructure
to make it efficient. Having the switch in the tree sooner is good
because it
On Sat, May 13, 2023 at 11:01 AM Thomas Munro wrote:
> On Sat, May 13, 2023 at 4:41 AM MARK CALLAGHAN wrote:
> > use XFS and O_DIRECT
As for direct I/O, we're only just getting started on that. We
currently can't produce more than one concurrent WAL write, and then
for relation data
On Sat, May 13, 2023 at 4:41 AM MARK CALLAGHAN wrote:
> Repeating what was mentioned on Twitter, because I had some experience with
> the topic. With fewer files per table there will be more contention on the
> per-inode mutex (which might now be the per-inode rwsem). I haven't read
>
On Sat, May 13, 2023 at 6:07 AM Greg Stark wrote:
> On Thu, 11 May 2023 at 05:37, Peter Eisentraut
> wrote:
> > Maybe it was never meant that way and only works accidentally? Maybe
> > hash indexes are broken?
>
> It's explicitly documented to be this way. And I think it has to work
> this way
On Fri, May 12, 2023 at 8:16 AM Jim Mlodgenski wrote:
> On Mon, May 1, 2023 at 9:29 PM Thomas Munro wrote:
>> I am not aware of any modern/non-historic filesystem[2] that can't do
>> large files with ease. Anyone know of anything to worry about on that
>> front?
>
On Thu, May 11, 2023 at 11:34 AM Michael Paquier wrote:
> On Wed, May 10, 2023 at 09:24:39AM -0400, Andrew Dunstan wrote:
> > We will definitely want buildfarm support. I don't have such a machine and
> > am not likely to have one any time soon. I do run drongo and fairywren on an
> > EC2
nk i22of32.p2.0
93662: unlink i5of32.p0.0
93662: unlink o20of32.p0.0
93662: unlink i24of32.p0.0
93662: unlink o18of32.p1.0
93662: unlink o17of32.p1.0
93662: unlink i13of32.p1.0
93662: unlink o30of32.p0.0
93662: unlink o5of32.p1.0
From 660ee4b9f7ba6c08cc8bc00b18bdbe6c83eb581b Mon Sep 17 00:00:00 2001
Fr
On Tue, May 9, 2023 at 3:41 PM Thomas Munro wrote:
> I tried out the patch you posted over at [1].
I forgot to add, +1, I think this is a good approach.
(I'm still a little embarrassed at how long we spent trying to debug
this in the other thread from the supplied clues, when you'd alre
I tried out the patch you posted over at [1]. For those wanting an
easy way to test it, or test the buggy behaviour in master without
this patch, you can simply kill -STOP the checkpointer, so that DROP
DATABASE hangs in RequestCheckpoint() (or you could SIGSTOP any other
backend so it hangs in
On Tue, May 9, 2023 at 10:04 AM Tom Lane wrote:
> Michael Paquier writes:
> > One thing I was wondering about to improve the odds of the hits is to
> > be more aggressive with the number of relations created at once, so as
> > we are much more aggressive with the number of pages extended in
> >
On Mon, May 8, 2023 at 2:24 PM Michael Paquier wrote:
> I can reproduce the same backtrace here. That's just my usual laptop
> with ext4, so this would be a Postgres bug. First, here are the four
> things running in parallel so as I can get a failure in loading a
> critical index when
On Mon, May 8, 2023 at 4:10 AM Evgeny Morozov
wrote:
> On 6/05/2023 11:13 pm, Thomas Munro wrote:
> > Would you like to try requesting FILE_COPY for a while and see if it
> > eventually happens like that too?
> Sure, we can try that.
Maybe you could do some one way and
On Sun, May 7, 2023 at 1:21 PM Tom Lane wrote:
> Thomas Munro writes:
> > Did you previously run this same workload on versions < 15 and never
> > see any problem? 15 gained a new feature CREATE DATABASE ...
> > STRATEGY=WAL_LOG, which is also the default. I wond
On Sun, May 7, 2023 at 10:23 AM Jeffrey Walton wrote:
> This may be related... I seem to recall the GNUlib folks talking about
> a cp bug on sparse files. It looks like it may be fixed in coreutils
> release 9.2 (2023-03-20):
> https://github.com/coreutils/coreutils/blob/master/NEWS#L233
>
> If I
On Sun, May 7, 2023 at 12:29 AM Evgeny Morozov
wrote:
> On 6/05/2023 12:34 pm, Thomas Munro wrote:
> > So it does indeed look like something unknown has replaced 32KB of
> > data with 32KB of zeroes underneath us. Are there more non-empty
> > files that are all-zeroes? Some
On Sat, May 6, 2023 at 9:58 PM Evgeny Morozov
wrote:
> Right - I should have realised that! base/1414389/2662 is indeed all
> nulls, 32KB of them. I included the file anyway in
> https://objective.realityexists.net/temp/pgstuff2.zip
OK so it's not just page 0, you have 32KB or 4 pages of all
601 - 700 of 6134 matches
Mail list logo
