Hi,
On 2025-03-18 12:17:41 -0700, Noah Misch wrote:
> On Tue, Mar 18, 2025 at 03:03:52PM -0400, Andres Freund wrote:
> > Subject: [PATCH v1] meson: Flush stdout in testwrap
> >
> > Otherwise the progress won't reliably be displayed during a test.
> > ---
> > src/tools/testwrap | 1 +
> > 1 file
On Tue, Mar 18, 2025 at 03:03:52PM -0400, Andres Freund wrote:
> Subject: [PATCH v1] meson: Flush stdout in testwrap
>
> Otherwise the progress won't reliably be displayed during a test.
> ---
> src/tools/testwrap | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/tools/testwrap b/src/
Hi,
On 2024-05-12 16:29:23 -0700, Noah Misch wrote:
> Author: Noah Misch
> Commit: Noah Misch
>
> Make TAP todo_start effects the same under Meson and prove_check.
>
> This could have caused spurious failures only on SPARC Linux, because
> today's only todo_start tests
On Thu, Aug 22, 2024 at 12:32:00AM -0700, Noah Misch wrote:
> This move also loses the optimization of unpinning before XactLockTableWait().
> heap_update() doesn't optimize that way, so that's fine.
In this other thread, I'm proposing to go back to unpinning:
https://postgr.es/m/20241027214035.8a
On Mon, Oct 21, 2024 at 10:00:00PM +0300, Alexander Lakhin wrote:
> Please look at an anomaly introduced with a07e03fd8.
> With the attached modification for intra-grant-inplace.spec, running this
> test triggers a Valgrind-detected error for me:
> ==00:00:00:09.624 319033== Conditional jump or mov
Hello Noah,
25.09.2024 01:43, Noah Misch wrote:
Pushed, but the pushes contained at least one defect:
Please look at an anomaly introduced with a07e03fd8.
With the attached modification for intra-grant-inplace.spec, running this
test triggers a Valgrind-detected error for me:
==00:00:00:09.62
On Thu, Sep 19, 2024 at 02:33:46PM -0700, Noah Misch wrote:
> On Mon, Sep 09, 2024 at 10:55:32AM +0530, Nitin Motiani wrote:
> > On Sat, Sep 7, 2024 at 12:25 AM Noah Misch wrote:
> > > https://commitfest.postgresql.org/49/5090/ remains in status="Needs
> > > review".
> > > When someone moves it t
On Sat, Sep 7, 2024 at 12:25 AM Noah Misch wrote:
>
> On Fri, Sep 06, 2024 at 03:22:48PM +0530, Nitin Motiani wrote:
> > Thanks. I have no other comments.
>
> https://commitfest.postgresql.org/49/5090/ remains in status="Needs review".
> When someone moves it to status="Ready for Committer", I wil
On Fri, Sep 06, 2024 at 03:22:48PM +0530, Nitin Motiani wrote:
> Thanks. I have no other comments.
https://commitfest.postgresql.org/49/5090/ remains in status="Needs review".
When someone moves it to status="Ready for Committer", I will commit
inplace090, inplace110, and inplace120 patches. If o
On Fri, Sep 6, 2024 at 3:34 AM Noah Misch wrote:
>
> On Thu, Sep 05, 2024 at 07:10:04PM +0530, Nitin Motiani wrote:
> > On Thu, Sep 5, 2024 at 1:27 AM Noah Misch wrote:
> > > On Wed, Sep 04, 2024 at 09:00:32PM +0530, Nitin Motiani wrote:
> > > > Assert(rel->ri_needsLockTagTuple ==
> > > > IsIn
On Thu, Sep 05, 2024 at 07:10:04PM +0530, Nitin Motiani wrote:
> On Thu, Sep 5, 2024 at 1:27 AM Noah Misch wrote:
> > On Wed, Sep 04, 2024 at 09:00:32PM +0530, Nitin Motiani wrote:
> > > Assert(rel->ri_needsLockTagTuple ==
> > > IsInplaceUpdateRelation(rel->relationDesc)
> > >
> > > This can sa
On Thu, Sep 5, 2024 at 1:27 AM Noah Misch wrote:
>
> On Wed, Sep 04, 2024 at 09:00:32PM +0530, Nitin Motiani wrote:
> > How about this alternative then? The tuple length check
> > and the elog(ERROR) gets its own function. Something like
> > heap_inplace_update_validate or
> > heap_inplace_update_
On Wed, Sep 04, 2024 at 09:00:32PM +0530, Nitin Motiani wrote:
> How about this alternative then? The tuple length check
> and the elog(ERROR) gets its own function. Something like
> heap_inplace_update_validate or
> heap_inplace_update_validate_tuple_length. So in that case, it would
> look like t
On Wed, Sep 4, 2024 at 2:53 AM Noah Misch wrote:
>
>
> > So this also pulls the invalidation to the genam.c
> > layer. Am I understanding this correctly?
>
> Compared to the v9 patch, the "call both" alternative would just move the
> systable_endscan() call to a new systable_inplace_update_end().
On Tue, Sep 03, 2024 at 09:24:52PM +0530, Nitin Motiani wrote:
> On Sat, Aug 31, 2024 at 6:40 AM Noah Misch wrote:
> > On Thu, Aug 29, 2024 at 09:08:43PM +0530, Nitin Motiani wrote:
> > > On Thu, Aug 29, 2024 at 8:11 PM Noah Misch wrote:
> > > > - In the cancel case, call both systable_inplace_up
On Sat, Aug 31, 2024 at 6:40 AM Noah Misch wrote:
>
> On Thu, Aug 29, 2024 at 09:08:43PM +0530, Nitin Motiani wrote:
> > On Thu, Aug 29, 2024 at 8:11 PM Noah Misch wrote:
> > > On Tue, Aug 20, 2024 at 11:59:45AM +0300, Heikki Linnakangas wrote:
> > > > My order of preference is: 2, 1, 3.
> > >
>
On Thu, Aug 29, 2024 at 09:08:43PM +0530, Nitin Motiani wrote:
> On Thu, Aug 29, 2024 at 8:11 PM Noah Misch wrote:
> > On Tue, Aug 20, 2024 at 11:59:45AM +0300, Heikki Linnakangas wrote:
> > > My order of preference is: 2, 1, 3.
> >
> > I kept tuple locking responsibility in heapam.c. That's simp
On Thu, Aug 29, 2024 at 8:11 PM Noah Misch wrote:
>
> On Tue, Aug 20, 2024 at 11:59:45AM +0300, Heikki Linnakangas wrote:
> > My order of preference is: 2, 1, 3.
>
> I kept tuple locking responsibility in heapam.c. That's simpler and better
> for modularity, but it does mean we release+acquire af
On Tue, Aug 20, 2024 at 11:59:45AM +0300, Heikki Linnakangas wrote:
> On 17/08/2024 07:07, Noah Misch wrote:
> > On Fri, Aug 16, 2024 at 12:26:28PM +0300, Heikki Linnakangas wrote:
> > > I wonder if the functions should be called "systable_*" and placed in
> > > genam.c rather than in heapam.c. The
On 17/08/2024 07:07, Noah Misch wrote:
On Fri, Aug 16, 2024 at 12:26:28PM +0300, Heikki Linnakangas wrote:
On 14/07/2024 20:48, Noah Misch wrote:
+ * ... [any slow preparation not requiring oldtup] ...
+ * heap_inplace_update_scan([...], &tup, &inplace_state);
+ * if (!HeapTupleIsValid(tup))
+
Thanks for reviewing.
On Fri, Aug 16, 2024 at 12:26:28PM +0300, Heikki Linnakangas wrote:
> On 14/07/2024 20:48, Noah Misch wrote:
> > I've pushed the two patches for your reports. To placate cfbot, I'm
> > attaching
> > the remaining patches.
>
> inplace090-LOCKTAG_TUPLE-eoxact-v8.patch: Makes
On 14/07/2024 20:48, Noah Misch wrote:
I've pushed the two patches for your reports. To placate cfbot, I'm attaching
the remaining patches.
inplace090-LOCKTAG_TUPLE-eoxact-v8.patch: Makes sense. A comment would
be in order, it looks pretty random as it is. Something like:
/*
* Tuple locks
Noah Misch writes:
> On Sun, Jul 28, 2024 at 11:50:33AM -0400, Tom Lane wrote:
>> Is it time to worry yet? If this were HEAD only, I'd not be too
>> concerned; but two of these three are on allegedly-stable branches.
>> And we have releases coming up fast.
> I don't know; neither decision feels
On Sun, Jul 28, 2024 at 11:50:33AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Jul 20, 2024 at 11:00:00AM +0300, Alexander Lakhin wrote:
> >> A recent buildfarm test failure [1] showed that the
> >> intra-grant-inplace-db.spec test added with 0844b3968 may fail
>
> >> But as the test
Noah Misch writes:
> On Sat, Jul 20, 2024 at 11:00:00AM +0300, Alexander Lakhin wrote:
>> A recent buildfarm test failure [1] showed that the
>> intra-grant-inplace-db.spec test added with 0844b3968 may fail
>> on a slow machine
>> But as the test going to be modified by the inplace110-successors
On Sat, Jul 20, 2024 at 11:00:00AM +0300, Alexander Lakhin wrote:
> 28.06.2024 08:13, Noah Misch wrote:
> > Pushed.
>
> A recent buildfarm test failure [1] showed that the
> intra-grant-inplace-db.spec test added with 0844b3968 may fail
> on a slow machine
> But as the test going to be modified b
Hello Noah,
28.06.2024 08:13, Noah Misch wrote:
Pushed.
A recent buildfarm test failure [1] showed that the
intra-grant-inplace-db.spec test added with 0844b3968 may fail
on a slow machine (per my understanding):
test intra-grant-inplace-db ... FAILED 4302 ms
@@ -21,8 +21,7 @@
On Thu, Jul 04, 2024 at 03:08:16PM -0700, Noah Misch wrote:
> On Thu, Jul 04, 2024 at 08:00:00AM +0300, Alexander Lakhin wrote:
> > 28.06.2024 08:13, Noah Misch wrote:
> > > Pushed. ...
> >
> > Please look also at another anomaly, I've discovered.
> >
> > An Assert added with d5f788b41 may be fal
On Thu, Jul 04, 2024 at 08:00:00AM +0300, Alexander Lakhin wrote:
> 28.06.2024 08:13, Noah Misch wrote:
> > Pushed. ...
>
> Please look also at another anomaly, I've discovered.
>
> An Assert added with d5f788b41 may be falsified with:
> CREATE TABLE t(a int PRIMARY KEY);
> INSERT INTO t VALUES (
Hello Noah,
28.06.2024 08:13, Noah Misch wrote:
Pushed. ...
Please look also at another anomaly, I've discovered.
An Assert added with d5f788b41 may be falsified with:
CREATE TABLE t(a int PRIMARY KEY);
INSERT INTO t VALUES (1);
CREATE VIEW v AS SELECT * FROM t;
MERGE INTO v USING (VALUES (1
On Wed, Jul 03, 2024 at 04:09:54PM -0700, Noah Misch wrote:
> On Wed, Jul 03, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
> > 29.06.2024 05:42, Noah Misch wrote:
> > > Good point, any effort on (2) would be wasted once the fixes get
> > > certified. I
> > > pushed (1). I'm attaching the re
On Wed, Jul 03, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
> 29.06.2024 05:42, Noah Misch wrote:
> > Good point, any effort on (2) would be wasted once the fixes get certified.
> > I
> > pushed (1). I'm attaching the rebased fix patches.
>
> Please look at a new anomaly, introduced by in
Hello Noah,
29.06.2024 05:42, Noah Misch wrote:
Good point, any effort on (2) would be wasted once the fixes get certified. I
pushed (1). I'm attaching the rebased fix patches.
Please look at a new anomaly, introduced by inplace110-successors-v5.patch:
CREATE TABLE t (i int) PARTITION BY LIS
On Fri, Jun 28, 2024 at 01:17:22AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Pushed. Buildfarm member prion is failing the new inplace-inval.spec,
> > almost
> > surely because prion uses -DCATCACHE_FORCE_RELEASE and inplace-inval.spec is
> > testing an extant failure to inval a cache entr
Noah Misch writes:
> Pushed. Buildfarm member prion is failing the new inplace-inval.spec, almost
> surely because prion uses -DCATCACHE_FORCE_RELEASE and inplace-inval.spec is
> testing an extant failure to inval a cache entry. Naturally, inexorable inval
> masks the extant bug. Ideally, I'd j
On Fri, Jun 21, 2024 at 02:28:42PM -0700, Noah Misch wrote:
> On Thu, Jun 13, 2024 at 05:35:49PM -0700, Noah Misch wrote:
> > I think the attached covers all comments to date. I gave everything v3, but
> > most patches have just a no-conflict rebase vs. v2. The exceptions are
> > inplace031-inj-w
On Thu, Jun 13, 2024 at 05:35:49PM -0700, Noah Misch wrote:
> On Mon, Jun 10, 2024 at 07:45:25PM -0700, Noah Misch 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 event
On Sun, Jun 16, 2024 at 07:07:08AM -0700, Noah Misch wrote:
> It would be odd to detect exactly 0x0B00U and not other invalid inputs,
> like 0x0A01U where only 0x0B01U is valid. I'm attaching roughly what
> it would take. Shall I squash this into inplace031?
Agreed that merging both
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
> >> "InjectionPoint" in the defaul
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
>> "InjectionPoint" in the default case of this class name, no?
>
> I intentionally didn't provide a defa
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 r
On Thu, Jun 13, 2024 at 05:35:49PM -0700, Noah Misch wrote:
> I think the attached covers all comments to date. I gave everything v3, but
> most patches have just a no-conflict rebase vs. v2. The exceptions are
> inplace031-inj-wait-event (implements the holding from that branch of the
> thread)
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 followi
On Wed, Jun 12, 2024 at 12:32:23PM -0700, Noah Misch wrote:
> On Wed, Jun 12, 2024 at 02:08:31PM -0400, Robert Haas wrote:
>> Personally, I think the fact that injection point wait events were put
>> under Extension is a design mistake that should be corrected before 17
>> is out of beta.
Well, is
Hello!
> 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 following logic:
* A pg_class race condition can cause table indexes to look
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 CONCURRENTLY
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
> > unblocks a necessary test fo
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
> unblocks a necessary test for a bug present in all versions.
However, injection points themselve
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
> >> type and let extensions add
Hello, everyone.
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 CONCURRENTLY could interfere with ON CONFLICT UPDATE
in some strange w
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
>> type and let extensions add specific wait events there, just like you
>> did for "Extension".
>
> Mi
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 ha
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 have been shoehorned into the
> > "Extension" category - which they are
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 have been shoehorned into the
> "Extension" category - which they are not - instead of being a new
> wait_event_type. That would hav
On Wed, Jun 5, 2024 at 2:17 PM Noah Misch wrote:
> 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.patch
> inplace050-tests-inj-v1.patch
> inplace060-nodeModifyTable-comme
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.patch
inp
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 zero
> > tuples when on
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 zero
> tuples when one is live. This is like what all backends got in the days of
> Snapshot
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: def
On Sun, May 12, 2024 at 04:29:23PM -0700, Noah Misch wrote:
> I'm attaching patches implementing the LockTuple() design. It turns out we
> don't just lose inplace updates. We also overwrite unrelated tuples,
> reproduced at inplace.spec. Good starting points are README.tuplock and the
> heap_inp
I prototyped two ways, one with a special t_ctid and one with LockTuple().
On Fri, Oct 27, 2023 at 04:26:12PM -0700, Noah Misch wrote:
> On Fri, Oct 27, 2023 at 06:40:55PM -0400, Tom Lane wrote:
> > Noah Misch writes:
> > > On Fri, Oct 27, 2023 at 03:32:26PM -0400, Tom Lane wrote:
> > > I antici
On Fri, Oct 27, 2023 at 06:40:55PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Fri, Oct 27, 2023 at 03:32:26PM -0400, Tom Lane wrote:
> >> I'm inclined to propose that heap_inplace_update should check to
> >> make sure that it's operating on the latest version of the tuple
> >> (including,
Noah Misch writes:
> On Fri, Oct 27, 2023 at 03:32:26PM -0400, Tom Lane wrote:
>> I'm inclined to propose that heap_inplace_update should check to
>> make sure that it's operating on the latest version of the tuple
>> (including, I guess, waiting for an uncommitted update?) and throw
>> error if n
On Fri, Oct 27, 2023 at 03:32:26PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Oct 26, 2023 at 09:44:04PM -0700, Noah Misch wrote:
> >> We'll likely need to change how we maintain relhasindex or perhaps take a
> >> lock
> >> in GRANT.
>
> > The main choice is accepting more DDL block
Noah Misch writes:
> On Thu, Oct 26, 2023 at 09:44:04PM -0700, Noah Misch wrote:
>> We'll likely need to change how we maintain relhasindex or perhaps take a
>> lock
>> in GRANT.
> The main choice is accepting more DDL blocking vs. accepting inefficient
> relcache builds. Options I'm seeing:
I
On Thu, Oct 26, 2023 at 09:44:04PM -0700, Noah Misch wrote:
> On Wed, Oct 25, 2023 at 01:39:41PM +0300, Smolkin Grigory wrote:
> > We are running PG13.10 and recently we have encountered what appears to be
> > a bug due to some race condition between ALTER TABLE ... ADD CONSTRAINT and
> > some othe
> This is going to be a problem with any operation that does a transactional
> pg_class update without taking a lock that conflicts with ShareLock.
GRANT
> doesn't lock the table at all, so I can reproduce this in v17 as follows:
>
> == session 1
> create table t (c int);
> begin;
> grant select on
On Wed, Oct 25, 2023 at 01:39:41PM +0300, Smolkin Grigory wrote:
> We are running PG13.10 and recently we have encountered what appears to be
> a bug due to some race condition between ALTER TABLE ... ADD CONSTRAINT and
> some other catalog-writer, possibly ANALYZE.
> The problem is that after succ
> ALTER TABLE ADD CONSTRAINT would certainly have taken
> AccessExclusiveLock on the "example" table, which should be sufficient
> to prevent anything else from touching its pg_class row. The only
> mechanism I can think of that might bypass that is a manual UPDATE on
> pg_class, which would just
Smolkin Grigory writes:
> We are running PG13.10 and recently we have encountered what appears to be
> a bug due to some race condition between ALTER TABLE ... ADD CONSTRAINT and
> some other catalog-writer, possibly ANALYZE.
> The problem is that after successfully creating index on relation (whi
> On 25 Oct 2023, at 13:39, Smolkin Grigory wrote:
>
> We are running PG13.10 and recently we have encountered what appears to be a
> bug due to some race condition between ALTER TABLE ... ADD CONSTRAINT and
> some other catalog-writer, possibly ANALYZ
> I've tried to reproduce this scenari
71 matches
Mail list logo
