Coincidentally, one of my buildfarm animals hanged several weeks in a
different test, 035_standby_logical_decoding.pl. A LOG_SNAPSHOT_INTERVAL_MS
reduction was part of making it reproducible:
On Fri, Feb 02, 2024 at 04:01:45PM -0800, Noah Misch wrote:
> On Fri, Feb 02, 2024 at 02:30:03PM -0
On Fri, Feb 09, 2024 at 08:33:23PM -0800, Andres Freund wrote:
> On 2024-02-09 15:27:57 -0800, Noah Misch wrote:
> > On Fri, Feb 09, 2024 at 10:24:32AM -0800, Andres Freund wrote:
> > > On 2024-01-26 07:42:33 +0100, Alvaro Herrera wrote:
> > > > This suggests that f
On Fri, Feb 16, 2024 at 06:37:38AM +, Bertrand Drouvot wrote:
> On Thu, Feb 15, 2024 at 12:48:16PM -0800, Noah Misch wrote:
> > On Wed, Feb 14, 2024 at 03:31:16PM +, Bertrand Drouvot wrote:
> > > What about creating a sub, say wait_for_restart_lsn_calculation() in
On Mon, Jan 29, 2024 at 04:03:44PM +0100, Jelte Fennema-Nio wrote:
> I feel like this is the type of change where there's not much
> discussion to be had. And the only way to resolve it is to use some
> voting to gauge community opinion.
>
> So my suggestion is for people to respond with -1,
On Fri, Feb 09, 2024 at 10:24:32AM -0800, Andres Freund wrote:
> On 2024-01-26 07:42:33 +0100, Alvaro Herrera wrote:
> > This suggests that finding a way to make the ifunc stuff work (with good
> > performance) is critical to this work.
>
> Ifuncs are effectively implemented as a function call
On Tue, Oct 10, 2023 at 05:54:34PM -0700, Andres Freund wrote:
> On 2023-10-10 17:08:25 -0700, Jeff Davis wrote:
> > After this, it seems "make check" no longer picks up the locale from
> > the system environment by default.
>
> Yea. I wonder if the better fix would have been to copy
On Fri, Jan 12, 2024 at 03:47:13PM -0500, Tom Lane wrote:
> I wrote:
> > This is uncomfortably much in bed with the tuple table slot code,
> > perhaps, but I don't see a way to do it more cleanly unless we want
> > to add some new provisions to that API. Andres, do you have any
> > thoughts about
On Sun, Dec 03, 2023 at 08:30:24PM +0530, Bharath Rupireddy wrote:
> On Sun, Dec 3, 2023 at 4:00 AM Nathan Bossart
> wrote:
> > On Sat, Dec 02, 2023 at 07:36:29PM +0530, Bharath Rupireddy wrote:
> > > b) Remove both the WAL_DEBUG macro and the wal_debug GUC. I don't
> > > think (2) is needed to
On Wed, Dec 06, 2023 at 03:17:12PM +0900, Michael Paquier wrote:
> On Sat, Nov 18, 2023 at 04:32:36PM -0800, Noah Misch wrote:
> > On Sat, Nov 18, 2023 at 03:09:58PM -0800, Andres Freund wrote:
> >> Unfortunately, there is a case of such an sqlstate that's not at al
On Thu, Dec 07, 2023 at 04:50:30PM +0530, Bharath Rupireddy wrote:
> On Mon, Dec 4, 2023 at 12:37 AM Noah Misch wrote:
> > On Sun, Dec 03, 2023 at 08:30:24PM +0530, Bharath Rupireddy wrote:
> > > On Sun, Dec 3, 2023 at 4:00 AM Nathan Bossart
> > > wrote:
> >
On Thu, Jan 25, 2024 at 12:28:43PM +0900, Fujii Masao wrote:
> On Thu, Jan 25, 2024 at 5:45 AM Noah Misch wrote:
> > On Thu, Jan 25, 2024 at 04:23:39AM +0900, Fujii Masao wrote:
> > > I found that this patch was committed at d3c5f37dd5 and changed the
> > > error messa
On Fri, Feb 02, 2024 at 02:30:03PM -0800, Noah Misch wrote:
> On Fri, Feb 02, 2024 at 05:07:14PM -0500, Tom Lane wrote:
> > If you look at the buildfarm's failures page and filter down to
> > just subscriptionCheck failures, what you find is that all of the
> >
On Fri, Feb 02, 2024 at 05:07:14PM -0500, Tom Lane wrote:
> If you look at the buildfarm's failures page and filter down to
> just subscriptionCheck failures, what you find is that all of the
> last 6 such failures are in 031_column_list.pl:
>
>
rocesses
> + attempted the cleanup concurrently.
> +
> +
Shall the top of the notes advise to reindex GIN indexes?
> +
> +
> +
> + Add more interlocks between CREATE DATABASE and
> + base backup (Noah Misch)
> +
> +
> +
On Fri, Feb 02, 2024 at 08:18:50PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > Shall the top of the notes advise to reindex GIN indexes?
>
> I thought about that, but it's a pretty low-probability failure
> I think, so I didn't write that advice. Maybe I misjudged it.
I c
On Sun, Feb 04, 2024 at 01:13:53PM -0500, Tom Lane wrote:
> I now have this text for your CREATE DATABASE fixes:
>
>
> Ensure durability of CREATE DATABASE (Noah Misch)
>
>
>
> If an operating system crash occurred during or shortly
>
On Sat, Nov 18, 2023 at 03:09:58PM -0800, Andres Freund wrote:
> We currently provide no way to learn about a postgres instance having
> corruption than searching the logs for corruption events than matching by
> sqlstate, for ERRCODE_DATA_CORRUPTED and ERRCODE_INDEX_CORRUPTED.
>
> Unfortunately,
est
suite checks that. Hence, I standardized on just inner_query.
I wrote this because pglogical needs these functions to cooperate with v15+
DROP DATABASE (https://github.com/2ndQuadrant/pglogical/issues/418).
Thanks,
nm
Author: Noah Misch
Commit: Noah Misch
Make dblink interruptible, via n
t I wonder if we should
> add a check similar to 3a9b18b [1] for the reason given in the commit
> message. I have added Noah to see if he has any suggestions on this
> matter.
>
> [1] -
> commit 3a9b18b3095366cd0c4305441d426d04572d88c1
> Author: Noah Misch
> Date: Mon
mprove the chance of future copy/paste finding the safe style. I'm attaching
a patch for that, too. I didn't add "volatile", because I couldn't think of
how we'd care if the load moved earlier.
Author: Noah Misch
Commit: Noah Misch
Test datfrozenxid/relfrozenxid update r
t have code that replaces an existing value
> with a value of a different length.
I saw a SIGSEGV there when using tidstore to write a fix for something else.
Patch attached.
Author: Noah Misch
Commit: Noah Misch
radixtree: Fix SIGSEGV at update of embeddable value to non-embedd
On Mon, Apr 29, 2024 at 10:18:35AM +0530, Amit Kapila wrote:
> On Mon, Apr 22, 2024 at 9:56 PM Noah Misch wrote:
> >
> > On Mon, Apr 15, 2024 at 11:17:54AM +0530, Amit Kapila wrote:
> > > On Thu, Apr 11, 2024 at 6:58 PM Kirill Reshke
> > > wrote:
> >
On Tue, Apr 30, 2024 at 09:10:52AM +0530, Amit Kapila wrote:
> On Tue, Apr 30, 2024 at 2:58 AM Noah Misch wrote:
> > On Mon, Apr 29, 2024 at 10:18:35AM +0530, Amit Kapila wrote:
> > > On Mon, Apr 22, 2024 at 9:56 PM Noah Misch wrote:
> >
> > >
On Thu, May 09, 2024 at 09:37:54AM +0900, Michael Paquier wrote:
> On Tue, May 07, 2024 at 11:53:10AM -0700, Noah Misch wrote:
> > The problem I'm trying to tackle in this thread is to make
> > src/test/modules/gin installcheck-safe. $SUBJECT's commit 5105c90 started
> > t
On Thu, May 09, 2024 at 04:40:43PM +0900, Michael Paquier wrote:
> So I like your suggestion. This version closes the race window
> between the shmem exit detach in backend A and a concurrent backend B
> running a point local to A so as B will never run the local point of
> A. However, it can
While writing an injection point test, I encountered a variant of the race
condition that f4083c4 fixed. It had three sessions and this sequence of
events:
s1: local-attach to POINT
s2: enter InjectionPointRun(POINT), yield CPU just before injection_callback()
s3: detach POINT, deleting the
On Thu, May 02, 2024 at 04:27:12PM +0900, Michael Paquier wrote:
> On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote:
> > While writing an injection point test, I encountered a variant of the race
> > condition that f4083c4 fixed. It had three sessions and this sequenc
XLogReadBufferForRedoExtended() precedes RestoreBlockImage() with
RBM_ZERO_AND_LOCK. Per src/backend/storage/buffer/README:
Once one has determined that a tuple is interesting (visible to the current
transaction) one may drop the content lock, yet continue to access the
tuple's data for as
On Fri, May 10, 2024 at 10:04:17AM +0900, Michael Paquier wrote:
> Attached is an updated patch for now, indented with a happy CI. I am
> still planning to look at that a second time on Monday with a fresher
> mind, in case I'm missing something now.
This looks correct, and it works well in my
On Mon, May 13, 2024 at 04:59:59PM +0900, Michael Paquier wrote:
> About inplace050-tests-inj-v1.patch.
>
> + /* Check if blocked_pid is in injection_wait(). */
> + proc = BackendPidGetProc(blocked_pid);
> + if (proc == NULL)
> + PG_RETURN_BOOL(false); /* session gone:
On Mon, May 06, 2024 at 10:03:37AM +0900, Michael Paquier wrote:
> On Thu, May 02, 2024 at 12:35:55PM -0700, Noah Misch wrote:
> > I should have given a simpler example:
> >
> > s1: local-attach to POINT
> > s2: enter InjectionPointRun(POINT), yield CPU just bef
On Tue, May 07, 2024 at 11:53:10AM -0700, Noah Misch wrote:
> On Tue, May 07, 2024 at 10:17:49AM +0900, Michael Paquier wrote:
> > Overall, this switches from one detach behavior to a different one,
>
> Can you say more about that? The only behavior change known to me is that a
&g
On Tue, May 07, 2024 at 10:17:49AM +0900, Michael Paquier wrote:
> On Mon, May 06, 2024 at 02:23:24PM -0700, Noah Misch wrote:
> > Here's how I've patched it locally. It does avoid changing the
> > backend-side,
> > which has some attraction. Shall I just push this?
>
On Mon, May 06, 2024 at 11:09:24PM -0400, Jonathan S. Katz wrote:
> * Avoid leaking a query result from
> [`psql`](https://www.postgresql.org/docs/current/app-psql.html)
> after the query is cancelled.
I'd delete this item about a psql-lifespan memory leak, because (a) it's so
minor and (b)
On Mon, May 13, 2024 at 03:53:08PM -0400, Robert Haas wrote:
> On Sun, May 12, 2024 at 7:29 PM Noah Misch wrote:
> > - [consequences limited to transient failure] Since a PROC_IN_VACUUM
> > backend's
> > xmin does not stop pruning, an MVCC scan in that backend can find z
On Wed, May 15, 2024 at 03:33:25PM +, Sriram RK wrote:
> Hi Team, we have any updated from the XLC team, the issue specific to the
> alignment is fixed
> and XLC had released it as part of 16.1.0.18. The PTF is available at the
> below location,
>
> You can also find a link here:
>
On Tue, Apr 30, 2024 at 09:10:52AM +0530, Amit Kapila wrote:
> On Tue, Apr 30, 2024 at 2:58 AM Noah Misch wrote:
> > On Mon, Apr 29, 2024 at 10:18:35AM +0530, Amit Kapila wrote:
> > > 3a9b18b309 didn't change the docs of pg_terminate_backend and whatever
> > > is
On Thu, Apr 25, 2024 at 04:59:54PM +0400, Pavel Borisov wrote:
> 0001: Optimize speed by avoiding heap visibility checking for different
> non-deduplicated index tuples as proposed by Noah Misch
>
> Speed measurements on my laptop using the exact method recommended by Noah
> upth
On Mon, Mar 18, 2024 at 08:02:24AM +0900, Michael Paquier wrote:
> > 1. Don't back-patch wait events to v17+. Use the closest existing event.
> > 2. Let wait_event_names.txt back-patches control the enum order. For
> > example,
> >a line could have an annotation that controls its position
On Wed, Jul 05, 2023 at 10:57:19AM +0900, Michael Paquier wrote:
> I have applied it.
I like the new developer experience of adding a wait event. After release of
v17, how should we approach back-patching an event, like was done in commits
8fa4a1a 1396b5c 78c0f85? Each of those commits put the
On Mon, Mar 18, 2024 at 09:04:44AM +, Bertrand Drouvot wrote:
> --- a/src/backend/utils/activity/wait_event_names.txt
> +++ b/src/backend/utils/activity/wait_event_names.txt
> @@ -24,7 +24,12 @@
> # SGML tables of wait events for inclusion in the documentation.
> #
> # When adding a
On Mon, Mar 18, 2024 at 07:40:10PM +0100, Alvaro Herrera wrote:
> I enabled the test again and also pushed the changes to dblink,
> isolationtester and fe_utils (which AFAICS is used by pg_dump,
I recommend adding a libpqsrv_cancel() function to libpq-be-fe-helpers.h, to
use from dblink and
On Thu, Mar 07, 2024 at 02:46:55PM +0500, Andrey M. Borodin wrote:
> I’m not sure if it is connected, but so far many patches in CFbot keep
> hanging in this test. For example [0].
> [0] https://cirrus-ci.com/task/5911176840740864?logs=check_world#L292
Relevant part:
[22:03:10.292] stderr:
On Mon, Oct 30, 2023 at 11:29:04AM +0400, Pavel Borisov wrote:
> On Wed, 25 Oct 2023 at 00:13, Alexander Korotkov wrote:
> > I think this patch is ready to go. I'm going to push it if there are
> > no objections.
> It's very good that this long-standing patch is finally committed. Thanks a
>
On Mon, Mar 25, 2024 at 12:03:10PM -0400, Peter Geoghegan wrote:
> On Sun, Mar 24, 2024 at 10:03 PM Noah Misch wrote:
> Separately, I now see that the committed patch just reuses the code
> that has long been used to check that things are in the correct order
> across pag
On Fri, Mar 29, 2024 at 02:17:08PM -0400, Peter Geoghegan wrote:
> On Mon, Mar 25, 2024 at 2:24 PM Noah Misch wrote:
> > I wasn't thinking about changing the pre-v17 bt_right_page_check_scankey()
> > code. I got interested in this area when I saw the interaction of the new
On Fri, Mar 29, 2024 at 09:17:55AM +0100, Jelte Fennema-Nio wrote:
> On Thu, 28 Mar 2024 at 19:03, Tom Lane wrote:
> > Could we make this test bulletproof by using an injection point?
> > If not, I remain of the opinion that we're better off without it.
>
> Possibly, and if so, I agree that
On Wed, Aug 30, 2023 at 09:48:42AM +1200, Thomas Munro wrote:
> On Wed, Aug 30, 2023 at 1:49 AM Noah Misch wrote:
> > On Tue, Aug 29, 2023 at 04:25:24PM +1200, Thomas Munro wrote:
> > > On Tue, Aug 29, 2023 at 1:48 PM Noah Misch wrote:
> > > > https://github.com/c
On Fri, Apr 05, 2024 at 04:12:06PM +, Sriram RK wrote:
>
> > What you do need to do to reproduce the described problems is
> > check out the Postgres git tree and rewind to just before
> > commit 0b16bb877, where we deleted AIX support. Any attempt
> > to restore AIX support would have to
On Fri, Apr 05, 2024 at 07:10:59PM -0400, Tom Lane wrote:
> I wondered why buildfarm member copperhead has started to fail
> xversion-upgrade-HEAD-HEAD tests. I soon reproduced the problem here:
>
> pg_restore: creating ACL "regress_pg_dump_schema.TYPE "test_type""
> pg_restore: while PROCESSING
On Thu, Mar 28, 2024 at 11:09:43AM +, Sriram RK wrote:
> We are setting up the build environment and trying to build the source and
> also trying to analyze the assert from the Aix point of view.
The thread Alvaro and Tom cited contains an analysis. It's a compiler bug.
You can get past the
On Fri, Feb 23, 2024 at 04:27:34PM +0200, Heikki Linnakangas wrote:
> Committed this. Thanks everyone!
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill=2024-02-24%2015%3A13%3A14
got:
TRAP: failed Assert("(uintptr_t) buffer == TYPEALIGN(PG_IO_ALIGN_SIZE,
buffer)"), File: "md.c",
On Sat, Feb 24, 2024 at 04:16:24PM +0530, Robert Haas wrote:
> On Sat, Feb 24, 2024 at 10:05 AM Noah Misch wrote:
> > On Fri, Feb 23, 2024 at 08:47:52PM +0530, Robert Haas wrote:
> > > I thought about whether there were any other WAL records that have
>
Hello,
On Sat, Feb 24, 2024 at 01:02:01PM +0200, Alexander Korotkov wrote:
> On Sat, Feb 24, 2024 at 7:12 AM Noah Misch wrote:
> > On Sat, Feb 24, 2024 at 12:36:59AM +0200, Alexander Korotkov wrote:
> > > On Thu, Feb 22, 2024 at 10:51 AM Andrei Lepikhov
> > > wrote:
On Fri, Feb 23, 2024 at 08:47:52PM +0530, Robert Haas wrote:
> If XLOG_DBASE_CREATE_FILE_COPY occurs between an incremental backup
> and its reference backup, every relation whose DB OID and tablespace
> OID match the corresponding values in that record should be backed up
> in full. Currently
On Sat, Feb 24, 2024 at 12:36:59AM +0200, Alexander Korotkov wrote:
> On Thu, Feb 22, 2024 at 10:51 AM Andrei Lepikhov
> wrote:
> > On 21/2/2024 14:26, Richard Guo wrote:
> > > I think the right fix for these issues is to introduce a new element
> > > 'sublevels_up' in ReplaceVarnoContext, and
On Sun, Feb 25, 2024 at 09:13:47AM +1300, Thomas Munro wrote:
> On Sun, Feb 25, 2024 at 9:12 AM Thomas Munro wrote:
> > On Sun, Feb 25, 2024 at 8:50 AM Noah Misch wrote:
> > > On GNU/Linux x64, gcc correctly records alignment=2**12 for the associated
> > > sectio
On Sun, Feb 25, 2024 at 07:52:16AM +1300, Thomas Munro wrote:
> On Sun, Feb 25, 2024 at 6:24 AM Noah Misch wrote:
> > On Fri, Feb 23, 2024 at 04:27:34PM +0200, Heikki Linnakangas wrote:
> > > Committed this. Thanks everyone!
> >
> > https://buildfarm.postgresql.org/c
On Sun, Feb 25, 2024 at 04:34:47PM +0200, Heikki Linnakangas wrote:
> I agree with Andres though, that unless someone raises their hand and
> volunteers to properly maintain the AIX support, we should drop it.
There's no way forward in which AIX support stops doing net harm. Even if AIX
On Wed, Feb 28, 2024 at 12:24:01AM +0400, Heikki Linnakangas wrote:
> Here's a patch to fully remove AIX support.
> Subject: [PATCH 1/1] Remove AIX support
>
> There isn't a lot of user demand for AIX support, no one has stepped
> up to the plate to properly maintain it, so it's best to remove
https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> Separable, nontrivial things not fixed in the attached patch stack:
>
> - Inplace update uses transactional CacheInvalidateHeapTuple(). ROLLBACK of
> CREATE INDEX wrongly discards the inval, leading to the relhasindex=t loss
>
On Sat, Oct 21, 2023 at 02:18:19AM -0400, Tom Lane wrote:
> Andres Freund writes:
> > It'd be one thing to continue supporting an almost-guaranteed-to-be-unused
> > platform, if we expected it to become more popular or complete enough to be
> > usable like e.g. risc-v a few years ago. But I doubt
On Wed, May 15, 2024 at 02:56:54PM +0900, Masahiko Sawada wrote:
> On Sat, May 4, 2024 at 7:36 AM Joe Conway wrote:
> > On 5/3/24 11:44, Peter Eisentraut wrote:
> > > On 03.05.24 16:13, Tom Lane wrote:
> > >> Peter Eisentraut writes:
> > >>> On 30.04.24 19:29, Tom Lane wrote:
> > Also, the
On Thu, May 23, 2024 at 02:00:00PM +0300, Alexander Lakhin wrote:
> I'd like to discuss ways to improve the buildfarm experience for anyone who
> are interested in using information which buildfarm gives to us.
>
> Unless I'm missing something, as of now there are no means to determine
> whether
On Sun, May 12, 2024 at 04:29:23PM -0700, Noah Misch wrote:
> I'm attaching patches implementing the LockTuple() design.
Starting 2024-06-10, I plan to push the first seven of the ten patches:
inplace005-UNEXPECTEDPASS-tap-meson-v1.patch
inplace010-tests-v1.patch
inplace040-waitfuncs-v1.pa
On Thu, Jun 06, 2024 at 12:36:32PM -0400, Robert Haas wrote:
> On Thu, Jun 6, 2024 at 6:00 AM Alexander Lakhin wrote:
> > Am I missing something or the the page buffer indeed lacks locking there?
>
> I don't know, but if the locks are really missing now, I feel like the
> first question is
On Mon, Jun 10, 2024 at 06:49:11PM -0700, Andres Freund wrote:
> On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote:
> > On 2024-06-10 Mo 16:04, Andres Freund wrote:
> > > Just for context for the rest the email: I think we desperately need to
> > > move
> > > off perl for tests. The
On Wed, Jun 12, 2024 at 10:02:00PM +0200, Michail Nikolaev wrote:
> > Can you say more about the connection you see between $SUBJECT and that?
> That
> > looks like a valid report of an important bug, but I'm not following the
> > potential relationship to $SUBJECT.
>
> I was guided by the
On Fri, Jun 14, 2024 at 09:58:59AM +0900, Michael Paquier wrote:
> Looking at inplace031-inj-wait-event..
>
> The comment at the top of GetWaitEventCustomNames() requires an
> update, still mentioning extensions.
Thanks. Fixed locally.
> GetWaitEventCustomIdentifier() is incorrect, and should
On Fri, Jun 07, 2024 at 09:08:03AM -0400, Robert Haas wrote:
> On Thu, Jun 6, 2024 at 7:20 PM Michael Paquier wrote:
> > On Thu, Jun 06, 2024 at 09:48:51AM -0400, Robert Haas wrote:
> > > It's not this patch set's fault, but I'm not very pleased to see that
> > > the injection point wait events
On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> > https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> > > Separable, nontrivial things not fixed in the attached patch stack:
> > >
On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > > On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> > > > https://pos
On Mon, Jun 17, 2024 at 11:11:17AM -0700, Andres Freund wrote:
> On 2024-06-15 16:48:24 -0700, Noah Misch wrote:
> > On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
> > > The one
> > > thing I know about that *I* think is a pretty big problem about
On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> > Separable, nontrivial things not fixed in the attached patch stack:
> >
> > - Inplace update uses transactional CacheInvalidateHeapTuple(). ROL
Separating this from the pytest thread:
On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
> The one
> thing I know about that *I* think is a pretty big problem about Perl
> is that IPC::Run is not really maintained.
I don't see in https://github.com/cpan-authors/IPC-Run/issues
On Sun, Jun 16, 2024 at 09:28:05AM +0900, Michael Paquier wrote:
> On Thu, Jun 13, 2024 at 07:42:25PM -0700, Noah Misch wrote:
> > On Fri, Jun 14, 2024 at 09:58:59AM +0900, Michael Paquier wrote:
> >> GetWaitEventCustomIdentifier() is incorrect, and should return
&g
On Thu, Oct 05, 2023 at 05:46:46PM +0200, Peter Eisentraut wrote:
> --- a/src/backend/Makefile
> +++ b/src/backend/Makefile
> $(top_builddir)/src/include/storage/lwlocknames.h: storage/lmgr/lwlocknames.h
> - prereqdir=`cd '$(dir $<)' >/dev/null && pwd` && \
> - cd '$(dir $@)' && rm -f
On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> I'm attaching the implementation.
I'm withdrawing inplace150-inval-durability-atcommit-v1.patch, having found
two major problems so far:
1. It sends transactional invalidation messages before
ProcArrayEndTransaction(), so ot
On Tue, Jun 11, 2024 at 01:37:21PM +0900, Michael Paquier wrote:
> On Mon, Jun 10, 2024 at 07:19:27PM -0700, Noah Misch wrote:
> > On Fri, Jun 07, 2024 at 09:08:03AM -0400, Robert Haas wrote:
> >> I think the core code should provide an "Injection Point" wait event
>
On Wed, Jun 12, 2024 at 03:02:43PM +0200, Michail Nikolaev wrote:
> I am not sure, but I think that issue may be related to the issue described
> in
> https://www.postgresql.org/message-id/CANtu0ojXmqjmEzp-%3DaJSxjsdE76iAsRgHBoK0QtYHimb_mEfsg%40mail.gmail.com
>
> It looks like REINDEX
On Wed, Jun 12, 2024 at 02:08:31PM -0400, Robert Haas wrote:
> On Wed, Jun 12, 2024 at 1:54 PM Noah Misch wrote:
> > If I were making a list of changes always welcome post-beta, it wouldn't
> > include adding wait event types. But I don't hesitate to add one if it
> > unbl
On Wed, Jun 12, 2024 at 01:40:30PM +0200, Jelte Fennema-Nio wrote:
> On Wed, 12 Jun 2024 at 01:48, Noah Misch wrote:
> > I also want the initial scope to be the new language coexisting with the
> > existing Perl tests. If a bulk translation ever happens, it should happen
> >
On Tue, Jun 18, 2024 at 08:23:49AM -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> > On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > > On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > > > On Wed, May 22,
rename the directory)
>
> The psql instance needs to be found and terminated first.
Thanks for that recipe. I've put that in my queue to fix.
On Tue, Jun 18, 2024 at 12:00:13PM -0700, Andres Freund wrote:
> On 2024-06-18 10:10:17 -0700, Noah Misch wrote:
> > On Mon, Jun 17, 20
ps://postgr.es/m/20240617235854.f8.nmi...@google.com.
This gets key testing from 027_stream_regress.pl; when I commented out some
memcpy lines of the heapam.c change, that test caught it.
This resolves the last inplace update defect known to me.
Thanks,
nm
Author: Noah Misch
Commit: Noah Mis
On Thu, Jun 20, 2024 at 09:29:45AM +0200, Peter Eisentraut wrote:
> On 16.06.24 21:34, Noah Misch wrote:
> > On Thu, Oct 05, 2023 at 05:46:46PM +0200, Peter Eisentraut wrote:
> > > --- a/src/backend/Makefile
> > > +++ b/src/backend/Makefile
> >
> >
On Thu, Jun 20, 2024 at 12:17:44PM +0500, Andrey M. Borodin wrote:
> On 20 Jun 2024, at 06:29, Noah Misch wrote:
> > This resolves the last inplace update defect known to me.
>
> That’s a huge amount of work, thank you!
>
> Do I get it right, that inplace updates are cata
801 - 887 of 887 matches
Mail list logo
