On Tue, Mar 23, 2021 at 1:53 AM Pavel Stehule wrote:
> po 22. 3. 2021 v 13:13 odesílatel Thomas Munro
> napsal:
>> The problem is that Apple's /dev/tty device is defective, and doesn't
>> work in poll(). It always returns immediately with revents=POLLNVAL,
>
On Sun, Mar 21, 2021 at 11:43 PM Pavel Stehule wrote:
> so 20. 3. 2021 v 23:45 odesílatel Thomas Munro
> napsal:
>> Thoughts? I put my changes into a separate patch for clarity, but
>> they need some more tidying up.
>
> yes, your solution is much better.
Hmm, the
On Tue, Mar 23, 2021 at 2:44 PM Fujii Masao wrote:
> I found 0001 patch was committed in de829ddf23, and which added new
> wait event WalrcvExit. This name seems not consistent with other wait
> events. I'm thinking it's better to rename it to WalReceiverExit. Thought?
> Patch attached.
Agreed, y
On Mon, Mar 22, 2021 at 3:29 PM Thomas Munro wrote:
> 2. The tests need tightening up. The thing with the "sleep 3" will
> not survive contact with the build farm, and I'm not sure if the SSL
> test is as short as it could be.
I don't think the TAP test can be
On Tue, Mar 23, 2021 at 11:47 PM Thomas Munro wrote:
> That leaves the thorny problem Tom mentioned at the top of this
> thread[1]: this socket-level approach can be fooled by an 'X' sitting
> in the socket buffer, if a client that did PQsendQuery() and then
> PQfinish().
simple, and doesn't have
v7's problem with pipelined queries. Hmm.
(I tried to make it work on Windows too by reading the manual, no idea
if that part compiles or works).
From 49948a11ebac1d835735ccedb9e0e2484d1cc13f Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Mon, 1 Mar 2021 1
int commit_ts_slru_buffers;
extern PGDLLIMPORT int MyProcPid;
extern PGDLLIMPORT pg_time_t MyStartTime;
diff --git a/src/include/storage/predicate.h b/src/include/storage/predicate.h
index 152b698611..c72779bd88 100644
--- a/src/include/storage/predicate.h
+++ b/src/include/storage/predicate.h
@@
On Thu, Mar 25, 2021 at 10:31 AM Thomas Munro wrote:
> We already know that increasing the number of CLOG buffers above the
> current number hurts as the linear search begins to dominate
> (according to the commit message for 5364b357), and it doesn't seem
> great to ship a new f
M. Borodin
Reviewed-by: Anastasia Lubennikova
Reviewed-by: Tomas Vondra
Reviewed-by: Alexander Korotkov
Reviewed-by: Gilles Darold
Reviewed-by: Thomas Munro
Discussion: https://postgr.es/m/2BEC2B3F-9B61-4C1D-9FB5-5FAB0F05EF86%40yandex-team.ru
---
doc/src/sgml/config.sgml
On Fri, Mar 26, 2021 at 2:57 AM David Steele wrote:
> On 1/22/21 6:46 PM, Finnerty, Jim wrote:
> > First 3 patches derived from the original 64-bit xid patch set by Alexander
> > Korotkov
>
> The patches no longer apply
> (http://cfbot.cputube.org/patch_32_2960.log), so marked Waiting on Author.
On Mon, Feb 15, 2021 at 11:56 PM Andrey Borodin wrote:
> > 16 янв. 2021 г., в 03:07, Alvaro Herrera
> > написал(а):
> > Andrey Borodin already has a patch to change the behavior for
> > multixact, which is something we should perhaps also do. I now notice
> > that they're also reporting a bug i
. Borodin
Reviewed-by: Anastasia Lubennikova
Reviewed-by: Tomas Vondra
Reviewed-by: Alexander Korotkov
Reviewed-by: Gilles Darold
Reviewed-by: Thomas Munro
Discussion: https://postgr.es/m/2BEC2B3F-9B61-4C1D-9FB5-5FAB0F05EF86%40yandex-team.ru
---
doc/src/sgml/config.sgml |
On Sat, Mar 27, 2021 at 6:31 PM Andrey Borodin wrote:
> > 27 марта 2021 г., в 01:26, Thomas Munro написал(а):
> > , and murmurhash which is inlineable and
> > branch-free.
> I think pageno is a hash already. Why hash any further? And pages accessed
> together will have
On Sat, Mar 27, 2021 at 6:51 AM Daniel Verite wrote:
> now_str| 17/mägabit/2013 après l’Incarnation 18:22:07.566 UTC+1
Very nice!
> For instance with the ethiopic calendar, the query above displays today as
> 17/mägabit/2013 and 1 month from now as 18/miyazya/2013,
> while the correct re
On Tue, Mar 30, 2021 at 6:25 AM Maksim Milyutin wrote:
>
> Hi Thomas! Thanks for working on this patch.
>
> I have attached a new version with some typo corrections of doc entry,
> removing of redundant `include` entries and trailing whitespaces. Also I
> added in doc the case
On Tue, Mar 30, 2021 at 6:37 AM James Hilliard
wrote:
> Should it work if I just attach it to the thread like this?
Yes. It automatically tries patches that are attached to threads that
are registered on commitfest.postgresql.org on 4 OSes, and we can see
that it succeeded, and we can inspect th
On Tue, Mar 30, 2021 at 12:32 PM James Hilliard
wrote:
> Should I resend with that changed or can it just be fixed when applied?
I'll move it when committing. I'll let this patch sit for another day
to see if any other objections show up.
On Thu, Mar 4, 2021 at 3:29 PM Kyotaro Horiguchi
wrote:
> A recent commot about LSN_FORMAT_ARGS conflicted this.
> Just rebased.
FYI I've been looking at this, and I think it's a very nice
improvement. I'll post some review comments and a rebase shortly.
On Tue, Mar 30, 2021 at 7:39 PM James Hilliard
wrote:
> On Mon, Mar 29, 2021 at 11:58 PM Tom Lane wrote:
> > We haven't claimed in the past to support MACOSX_DEPLOYMENT_TARGET,
> > and I'm not sure we should start now. How many people actually care
> > about that?
>
> Seems kinda important for a
On Fri, Mar 12, 2021 at 7:55 PM Thomas Munro wrote:
> On Thu, Mar 11, 2021 at 7:34 PM Michael Paquier wrote:
> > Wow. This probably means that we would be able to get rid of
> > USE_POSTMASTER_DEATH_SIGNAL?
>
> We'll still need it, because there'd still be s
On Thu, Apr 1, 2021 at 11:25 AM Tomas Vondra
wrote:
> As for why the regression tests did not catch this, it's most likely
> because the data is likely generated in "nice" ordering, or something
> like that. I'll see if I can tweak the ordering to trigger these issues
> reliably, and I'll do a bit
On Thu, Apr 1, 2021 at 10:09 AM Andrey Borodin wrote:
> > 29 марта 2021 г., в 11:26, Andrey Borodin написал(а):
> > My TODO list:
> > 1. Try to break patch set v13-[0001-0004]
> > 2. Think how to measure performance of linear search versus hash search in
> > SLRU
On Tue, Mar 30, 2021 at 10:00 AM Thomas Munro wrote:
> If we want to ship this in v14 we have to make a decision ASAP:
>
> 1. Ship the POLLHUP patch (like v9) that only works reliably on
> Linux. Maybe disable the feature completely on other OSes?
> 2. Ship the patch that trie
On Fri, Apr 2, 2021 at 9:42 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Tue, Jan 8, 2019 at 7:14 PM Tom Lane wrote:
> >> So I looked around for an alternative, and found out that modern
> >> OpenBSD releases support named POSIX semaphores (though not unnamed
>
On Fri, Mar 19, 2021 at 2:29 PM Tomas Vondra
wrote:
> On 3/18/21 1:54 AM, Thomas Munro wrote:
> > I'm now looking at Horiguchi-san and Heikki's patch[2] to remove
> > XLogReader's callbacks, to try to understand how these two patch sets
> > are related
On Thu, Apr 1, 2021 at 10:16 PM tsunakawa.ta...@fujitsu.com
wrote:
> From: Thomas Munro
> > I changed my mind. Let's commit the pleasingly simple Linux-only feature
> > for
> > now, and extend to it to send some kind of no-op message in a later release.
> > So
On Fri, Apr 2, 2021 at 1:36 AM Bharath Rupireddy
wrote:
> Here's a minor comment: it would be good if we have an extra line
> after variable assignments, before and after function calls/if
> clauses, something like
Done in v11. Thanks.
On Fri, Apr 2, 2021 at 6:18 PM tsunakawa.ta...@fujitsu.com
wrote:
> The patch looks committable to me.
I checked for performance impact compared to master with pgbench -S,
and didn't see any problem. I thought more about how to write a
decent race-free test but struggled with the lack of a good
On Wed, Mar 31, 2021 at 7:17 PM Kyotaro Horiguchi
wrote:
> At Wed, 31 Mar 2021 10:00:02 +1300, Thomas Munro
> wrote in
> > On Thu, Mar 4, 2021 at 3:29 PM Kyotaro Horiguchi
> > wrote:
> > > A recent commot about LSN_FORMAT_ARGS conflicted this.
> > > Just re
On Wed, Apr 7, 2021 at 5:09 AM Thomas Munro wrote:
> 0001 + 0002 get rid of the callback interface and replace it with a
> state machine, making it the client's problem to supply data when it
> returns XLREAD_NEED_DATA. I found this interface nicer to work with,
> for my WA
On Wed, Apr 7, 2021 at 11:18 AM Alvaro Herrera wrote:
> BTRW it's funny that after these patches, "xlogreader" no longer reads
> anything. It's more an "xlog interpreter" -- the piece of code that
> splits individual WAL records from a stream of WAL bytes that's caller's
> responsibility to obtai
r 16. Any ideas on how to evaluate this and
choose the number? See attached.
From 5f61bd7d227077f86649a890be603eae01c828f8 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Thu, 25 Mar 2021 10:11:31 +1300
Subject: [PATCH v15 1/3] Add a buffer mapping table for SLRUs.
Instead of doing a linear search f
On Wed, Apr 7, 2021 at 5:44 PM Robins Tharakan wrote:
> Bichir's been stuck for the past month and is unable to run regression tests
> since 6a2a70a02018d6362f9841cc2f499cc45405e86b.
Hrmph. That's "Use signalfd(2) for epoll latches." I had a similar
report from an illumos user (but it was inte
On Wed, Apr 7, 2021 at 8:50 PM Kyotaro Horiguchi
wrote:
> I haven't changed the name "XLog reader" to "XLog decoder". I'm doing
> that but it affects somewhat wide range of code.
Thanks for the new patch set! Let's not worry about renaming it for now.
This fails in check-world as seen on cfbot;
f (restoreQueryFout)
+ pset.queryFout = restoreQueryFout;
+
If someone has a tidier way to factor this, I'm keen to hear it. I'd
like to push this today.
From bd71cff8d25b919caeaab4db94b93d8647f6d911 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Sat, 20 Mar 2021 21:54:27
sn't seem too bad to me, as an incremental step
(but to be clear, of course we can do better than this with more work
in later releases).
From 72ebd5052851aa4b9aa281df30b9bf42c0ad5de4 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Thu, 25 Mar 2021 10:11:31 +1300
Subject: [PATCH v16 1/3] Add
: Thomas Munro
Discussion: https://postgr.es/m/20190418.210257.43726183.horiguchi.kyotaro%40lab.ntt.co.jp
---
src/backend/access/transam/twophase.c | 14 +-
src/backend/access/transam/xlog.c | 129 ++-
src/backend/access/transam/xlogreader.c | 932 +++---
src
Hi Julien, Bruce,
A warning appears on 32 bit systems:
In file included from pgstatfuncs.c:15:
pgstatfuncs.c: In function 'pg_stat_get_activity':
../../../../src/include/postgres.h:593:29: warning: cast to pointer
from integer of different size [-Wint-to-pointer-cast]
593 | #define DatumGetPoin
On Thu, Apr 8, 2021 at 3:27 AM Tomas Vondra
wrote:
> On 4/7/21 1:24 PM, Thomas Munro wrote:
> > I made one other simplifying change: previously, the prefetch module
> > would read the WAL up to the "written" LSN (so, allowing itself to
> > read data that had been
On Thu, Apr 8, 2021 at 9:46 PM Thomas Munro wrote:
> I squashed the patch set into one because half of them were fixups,
> and the two main patches were really parts of the same change and
> should go in together.
>
> I fixed a few compiler warnings (GCC 10.2 reported several
On Thu, Apr 8, 2021 at 7:24 PM Andrey Borodin wrote:
> I agree that this version of eviction seems much more effective and less
> intrusive than RR. And it's still LRU, which is important for subsystem that
> is called SLRU.
> shared->search_slotno is initialized implicitly with memset(). But th
On Wed, Mar 31, 2021 at 7:02 PM Thomas Munro wrote:
> On Fri, Mar 12, 2021 at 7:55 PM Thomas Munro wrote:
> > On Thu, Mar 11, 2021 at 7:34 PM Michael Paquier wrote:
> > > Wow. This probably means that we would be able to get rid of
> > > USE_POSTMASTER_DEATH_SIGNAL?
On Wed, Apr 7, 2021 at 7:31 PM Robins Tharakan wrote:
> Correct. This is easily reproducible on this test-instance, so let me know if
> you want me to test a patch.
>From your description it sounds like signals are not arriving at all,
rather than some more complicated race. Let's go back to ba
On Fri, Apr 9, 2021 at 3:37 PM Justin Pryzby wrote:
> Here's some little language fixes.
Thanks! Done. I rewrote the gibberish comment that made you say
"XXX: what?". Pushed.
> BTW, before beginning "recovery", PG syncs all the data dirs.
> This can be slow, and it seems like the slowness is
On Fri, Apr 9, 2021 at 11:53 PM Daniel Westermann (DWE)
wrote:
> all "short_desc" end with a dot, except these:
>
> - Prefetch referenced blocks during recovery
> - Prefetch blocks that have full page images in the WAL
Pushed, thanks.
On Sat, Apr 10, 2021 at 8:37 AM Justin Pryzby wrote:
> Did you see this?
> https://www.postgresql.org/message-id/GV0P278MB0483490FEAC879DCA5ED583DD2739%40GV0P278MB0483.CHEP278.PROD.OUTLOOK.COM
>
> I meant to mail you so you could include it in the same commit, but forgot
> until now.
Done, thanks
'm
not at all sure about this, but hmm... at first glance, perhaps there
is no live bug here because the use of *otid comes before
RelationPutHeapTuple() which is where newtup->t_self is really
updated?
From 32d5c87f38d383501d10dbbda1f93ab8eb4d0ab6 Mon Sep 17 00:00:00 2001
From: Thomas Mun
On Wed, Mar 17, 2021 at 8:20 AM Thomas Munro wrote:
> *I mean, we can discuss the different "timelines" like UT, UTC, TAI
> etc, but that's getting into the weeds, the usual timeline for
> computer software outside specialist scientific purposes is UTC
> without lea
On Tue, Apr 13, 2021 at 8:59 AM Tom Lane wrote:
> I am wondering what was the intent of this test case added by commit
> 257836a75:
>
> CREATE INDEX icuidx16_mood ON collate_test(id) WHERE mood > 'ok' COLLATE
> "fr-x-icu";
>
> where "mood" is of an enum type, which surely does not respond to
> co
On Mon, Apr 12, 2021 at 10:36 AM Thomas Munro wrote:
> Yeah. Patch attached.
Pushed.
On Tue, Apr 13, 2021 at 5:51 PM Tatsuo Ishii wrote:
> Currently standard pgbench scenario produces transaction serialize
> errors "could not serialize access due to concurrent update" if
> PostgreSQL runs in REPEATABLE READ or SERIALIZABLE level, and the
> session aborts. In order to achieve meani
On Wed, Jul 22, 2020 at 3:57 PM Amit Kapila wrote:
> Yeah, that is true but every time before the test the same amount of
> data should be present in shared buffers (or OS cache) if any which
> will help in getting consistent results. However, it is fine to
> reboot the machine as well if that is
On Thu, Jul 23, 2020 at 3:24 PM Lu, Chenyang wrote:
> When I analyze this commit:
>
> https://github.com/postgres/postgres/commit/7897e3bb902c557412645b82120f4d95f7474906
>
> I noticed that the message was not consistent with the previous one in
> ‘src/backend/storage/file/buffile.c’
>
> To keep
On Mon, Jul 27, 2020 at 1:58 AM Dilip Kumar wrote:
> On Sun, Jul 26, 2020 at 6:42 PM Dilip Kumar wrote:
> >
> > I would like to propose a patch for enabling the parallelism for the
> > bitmap index scan path.
Workers Planned: 4
-> Parallel Bitmap Heap Scan on ten
On Sat, Jun 20, 2020 at 7:17 AM Andres Freund wrote:
> On 2020-06-19 17:42:41 +1200, Thomas Munro wrote:
> > On Thu, Jun 18, 2020 at 6:05 PM Thomas Munro wrote:
> > > Here's a version that adds some documentation.
> >
> > I jumped on a dual socket machine
On Thu, Jul 9, 2020 at 8:17 AM Melanie Plageman
wrote:
> Last week as I was working on adaptive hash join [1] and trying to get
> parallel adaptive hash join batch 0 to spill correctly, I noticed what
> seemed like a problem with the code to repartition batch 0.
>
> If we run out of space while in
On Tue, Jul 21, 2020 at 4:33 PM Justin Pryzby wrote:
> /*
> * clean up a spool structure and its substructures.
> */
> static void
> _bt_spooldestroy(BTSpool *btspool)
> {
> + void *fileset = tuplesort_shared_fileset(btspool->sortstate);
> + if (fileset)
> + Share
On Wed, Dec 11, 2019 at 3:22 PM Thomas Munro wrote:
> On Tue, Oct 15, 2019 at 4:50 AM Tom Lane wrote:
> > > Filed at
> > > https://bugzilla.kernel.org/show_bug.cgi?id=205183
>
> For the curious-and-not-subscribed, there's now a kernel patch
> proposed for this
On Thu, Jul 2, 2020 at 6:39 PM James Sewell wrote:
> The patch replaces sigprocmask with pthread_sigmask. They have identical APIs
> ("[pthread_sigmask] shall be equivalent to sigprocmask(), without the
> restriction that the call be made in a single-threaded process"[1])
-#define PG_SETMASK(ma
On Wed, Jun 24, 2020 at 6:28 AM Andres Freund wrote:
> On 2020-06-23 13:30:39 +1200, Thomas Munro wrote:
> > I suppose it's remotely possible that someone might invent
> > physical-order index scans, and once you have those you might sync
> > scans of those too, and th
On Fri, Jul 24, 2020 at 1:11 PM Andres Freund wrote:
> On 2020-07-15 21:33:06 -0400, Alvaro Herrera wrote:
> > On 2020-Jul-15, Andres Freund wrote:
> > > It could make sense to split the conversion of
> > > VariableCacheData->latestCompletedXid to FullTransactionId out from 0001
> > > into is own
On Wed, Jul 29, 2020 at 6:15 PM Thomas Munro wrote:
> +static inline FullTransactionId
> +FullXidViaRelative(FullTransactionId rel, TransactionId xid)
>
> I'm struggling to find a better word for this than "relative".
The best I've got is "anchor"
On Tue, Jul 14, 2020 at 9:12 AM Robert Haas wrote:
> A number of EDB customers have had this error crop on their tables for
> reasons that we have usually not been able to determine. In many
Do you happen to know if they ever used the
snapshot-too-old feature?
On Thu, Jul 30, 2020 at 1:36 AM Robert Haas wrote:
> On Wed, Jul 29, 2020 at 3:23 AM Thomas Munro wrote:
> > On Tue, Jul 14, 2020 at 9:12 AM Robert Haas wrote:
> > > A number of EDB customers have had this error crop on their tables for
> > > reasons that we ha
On Fri, Jul 10, 2020 at 6:55 PM Andrey M. Borodin wrote:
> Thanks! Fixed.
It's not a bug, but I think those 64 bit constants should be wrapped
in UINT64CONST(), following our convention.
I'm confused about these two patches: 0001 introduces
gist_point_fastcmp(), but then 0002 changes it to gist_
On Tue, Jul 14, 2020 at 6:51 PM Thomas Munro wrote:
> In the meantime, here's a rebase of the more straightforward patches
> in the stack. These are the ones that deal only with fixed sets of
> file descriptors, and they survive check-world on Linux,
> Linux+EXEC_BACKEND (with A
On Thu, Jul 30, 2020 at 5:50 PM Thomas Munro wrote:
> I pushed those three patches, but will wait for more discussion on the rest.
And here's a rebase, to make cfbot happy.
From a760053ac6fea1b9a829e9a170902a555863ce66 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Mon, 24 Feb 2020
On Sat, Jun 20, 2020 at 10:32 AM Thomas Munro wrote:
> Rebased. I'll add this to the open commitfest.
I traced the recovery process while running pgbench -M prepared -c16
-j16 -t1 (= 160,000 transactions). With the patch, the number of
lseeks went from 1,080,661 (6.75 per
On Mon, Jul 27, 2020 at 2:45 PM Thomas Munro wrote:
> Here's a new version, using the name min_dynamic_shared_memory, which
> sounds better to me. Any objections? I also fixed the GUC's maximum
> setting so that it's sure to fit in size_t.
I pushed it like that. Ha
On Fri, Jul 31, 2020 at 2:36 PM Thomas Munro wrote:
> There's still the matter of crazy numbers of lseeks in regular
> backends; looking at all processes while running the above test, I get
> 1,469,060 (9.18 per pgbench transaction) without -M prepared, and
> 193,722 with -M p
On Sat, Aug 1, 2020 at 7:22 AM James Coleman wrote:
> [v2 patch set]
I ran it through pgindent which insisted on adding some newlines, I
manually replaced some spaces with tabs to match nearby lines, I added
some asterisks in your example function prototypes where is
returned because they seemed
On Fri, Feb 14, 2020 at 4:47 AM Alvaro Herrera wrote:
> So, you said lseek() is faster than fstat, and we would only use the
> latter because we want to avoid the file position jumping ahead, even
> though it's slower. But if the next read/write is not going to care
> about the file position beca
Hi,
There are one or two failures per month on crake. It looks like when
authentication is rejected, as expected in the tests, the psql process
is exiting, but there is a race where the Perl script still wants to
write a dummy query to its stdin (?), so you get:
psql: FATAL: LDAP authentication
16 -0400
>
> Use return instead of exit() in configure
>
> Using exit() requires stdlib.h, which is not included. Use return
> instead. Also add return type for main().
>
> Reviewed-by: Heikki Linnakangas
> Reviewed-by: Thomas Munro
>
On Sun, Aug 2, 2020 at 1:54 PM David Rowley wrote:
> On Sun, 2 Aug 2020 at 11:16, David Rowley wrote:
> > Maybe it would be better just to get rid of the enum and just #define
> > the values. It seems unlikely that we're every going to need many more
> > states than what are there already, let al
not sure.)
Good idea. Here's a patch like that.
> I've not been able to duplicate this locally, so I have no idea if
> that'd really fix it.
Me neither -- I guess someone who enjoys perl could hack IPC::Run to
take a short nap at the right moment.
From 22220d01b65cef920c953551ce1c
On Mon, Aug 3, 2020 at 11:42 AM David Rowley wrote:
> On Mon, 3 Aug 2020 at 11:36, David Rowley wrote:
> > So, with the current users, we'd stand to lose more than we'd gain
> > from doing it that way.
>
> FWIW, I'd be ok with just:
>
> - * The element type is required to contain a "uint32
On Mon, Aug 3, 2020 at 12:29 PM Noah Misch wrote:
> On Mon, Aug 03, 2020 at 12:12:57PM +1200, Thomas Munro wrote:
> > On Mon, Aug 3, 2020 at 4:09 AM Tom Lane wrote:
> > > I'm inclined to suggest that the LDAP test's test_access could use
> > > an empty stdin
On Tue, Aug 4, 2020 at 3:54 AM Konstantin Knizhnik
wrote:
> So in this thread three solutions are proposed:
> 1. "bullet-proof general shared invalidation"
> 2. recovery-only solution avoiding shared memory and invalidation
> 3. "relaxed" shared memory cache with simplified invalidation
Hi Konsta
On Wed, Feb 12, 2020 at 9:54 PM Thomas Munro wrote:
> In commit 3eb77eba we made it possible for any subsystem that wants a
> file to be flushed as part of the next checkpoint to ask the
> checkpointer to do that, as previously only md.c could do.
Hello,
While working on recovery perfo
required" I don't think this
would be a big risk.
Thomas
On Tue, Aug 4, 2020 at 6:02 PM Thomas Munro wrote:
> ... speedup of around 6% ...
I did some better testing. OS: Linux, storage: consumer SSD. I
repeatedly ran crash recovery on 3.3GB worth of WAL generated with 8M
pgbench transactions. I tested 3 different builds 7 times each and
u
On Tue, Aug 4, 2020 at 3:47 AM Tomas Vondra
wrote:
> On Thu, Jul 02, 2020 at 03:09:29PM +1200, Thomas Munro wrote:
> >FYI I am still trying to reproduce and understand the problem Tomas
> >reported; more soon.
>
> Any luck trying to reproduce thigs? Should I try a
o for the first attempt at prototyping
this I arbitrarily chose SIGURG.
From a45e9edaa315e62a0f823dbd55b42950fc8d5df3 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Sat, 8 Aug 2020 15:08:09 +1200
Subject: [PATCH 1/3] Optimize latches to send fewer signals.
Author: Andres Freund
---
src/backend/stor
On Tue, Jul 28, 2020 at 3:27 PM Tom Lane wrote:
> Anyway, I guess the interesting question for us is how long it
> will take for this fix to propagate into real-world systems.
> I don't have much of a clue about the Linux kernel workflow,
> anybody want to venture a guess?
Me neither. It just hi
t the installer overhead.
Any chance 2ndQuadrant can supply something like that as well?
Thomas
On Wed, Aug 12, 2020 at 12:19 PM Andres Freund wrote:
> On 2020-07-29 19:20:04 +1200, Thomas Munro wrote:
> > On Wed, Jul 29, 2020 at 6:15 PM Thomas Munro wrote:
> > > +static inline FullTransactionId
> > > +FullXidViaRelative(FullTransactionId rel, TransactionId xid)
On Sat, Aug 8, 2020 at 2:44 AM Robert Haas wrote:
> On Wed, Aug 5, 2020 at 2:01 AM Thomas Munro wrote:
> > * Master is around 11% faster than last week before commit c5315f4f
> > "Cache smgrnblocks() results in recovery."
> > * This patch gives a similar speedup,
On Thu, Aug 13, 2020 at 3:32 AM Bharath Rupireddy
wrote:
> After a smart shutdown is issued(with pg_ctl), run a parallel query,
> then the query hangs. The postmaster doesn't inform backends about the
> smart shutdown(see pmdie() -> SIGTERM -> BACKEND_TYPE_NORMAL are not
> informed), so if they
On Thu, Aug 13, 2020 at 6:00 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, Aug 13, 2020 at 3:32 AM Bharath Rupireddy
> > wrote:
> >> After a smart shutdown is issued(with pg_ctl), run a parallel query,
> >> then the query hangs.
>
> > Yeah, t
On Thu, Aug 13, 2020 at 8:59 AM Tom Lane wrote:
> I wrote:
> > Oh, excellent point! I'd not thought to look at tests of the Shutdown
> > variable, but yeah, those should be <= SmartShutdown if we want autovac
> > to continue to operate in this state.
>
> On looking closer, there's another problem
On Thu, Aug 13, 2020 at 10:21 AM Tom Lane wrote:
> Thomas Munro writes:
> > @@ -5911,11 +5912,11 @@ bgworker_should_start_now(BgWorkerStartTime
> > start_time)
> > + case PM_WAIT_READONLY:
> > + case PM_WAIT_CLIENTS:
> >
On Wed, Aug 12, 2020 at 6:06 PM Thomas Munro wrote:
> [patch]
Bitrot, rebased, no changes.
> Yeah, the combined effect of these two patches is better than I
> expected. To be clear though, I was only measuring the time between
> the "redo starts at ..." and "redo d
On Thu, Aug 13, 2020 at 2:37 PM Tom Lane wrote:
> I experimented with separating the shutdown-in-progress state into a
> separate variable, letting us actually reduce not increase the number of
> pmStates. This way, PM_RUN and other states still apply until we're
> ready to pull the shutdown trig
On Thu, Aug 6, 2020 at 10:47 PM Tomas Vondra
wrote:
> On Thu, Aug 06, 2020 at 02:58:44PM +1200, Thomas Munro wrote:
> >On Tue, Aug 4, 2020 at 3:47 AM Tomas Vondra
> >> Any luck trying to reproduce thigs? Should I try again and collect some
> >> additional debug info?
&
d = 1;
oldSnapshotControl->xid_by_minute[0] = xmin;
+ oldSnapshotControl->head_timestamp = ts;
}
else
{
@@ -1973,6 +1996,7 @@ MaintainOldSnapshotTimeMapping(TimestampTz whenTaken, TransactionId xmin)
else
oldSnapshotControl->head_offset = old_head + 1;
oldSn
On Fri, Aug 14, 2020 at 12:52 PM Thomas Munro wrote:
> Here's a rebase.
And another, since I was too slow and v6 is already in conflict...
sorry for the high frequency patches.
From 1ced7b8c881676f21623c048f5e9e012ca8416ec Mon Sep 17 00:00:00 2001
From: Robert Haas
Date: Thu, 16 Apr 20
On Thu, Jul 2, 2020 at 3:20 PM Etsuro Fujita wrote:
> On Thu, Jul 2, 2020 at 11:14 AM Kyotaro Horiguchi
> wrote:
> > As the result of a discussion with Fujita-san off-list, I'm going to
> > hold off development until he decides whether mine or Thomas' is
> >
On Thu, Aug 13, 2020 at 9:52 PM Julien Rouhaud wrote:
> Here's a rebased v27 that removes the current approach to ignore indexes that
> don't rely on a stable ordering. I'll start a new thread on that matter once
> the infrastructure pieces will be committed.
Thanks Julien. I'm planning to do a
On Thu, Aug 13, 2020 at 6:38 PM Amit Kapila wrote:
> I have pushed that patch last week and attached are the remaining
> patches. I have made a few changes in the next patch
> 0001-Extend-the-BufFile-interface.patch and have some comments on it
> which are as below:
Hi Amit,
I noticed that Konst
401 - 500 of 4325 matches
Mail list logo
