s memory. For now, there's only one option that spills
to disk (external merge sort), but there's no reason it has to remain that
way. And in the future we might accurately report memory consumed even when
we've eventually spilled to disk also, so memory used would be relevant
potentially even if no in-memory sort was ever performed.
So I'm pretty confident checking the space used is the correct way to do
this.
James
be done by libraries they make use of transparently.
Let's help them to avoid unsafe code now, not wait until they show up on
this list with a critical failure and tap at the big sign that says "NO
THREADING".
- james
On Thu, Jul 30, 2020 at 10:12 PM David Rowley wrote:
>
> On Fri, 3 Jul 2020 at 07:47, James Coleman wrote:
> > Patch using int64 attached.
>
> I added this to the open items list for PG13.
>
> David
I'd previously attached a patch [1], and there seemed to be agreeme
tested, passed
>
> James,
>
> I'm on board with the point of pointing out explicitly the "concurrent index
> builds on multiple tables at the same time will not return on any one table
> until all have completed", with back-patching. I do not believe the new
>
On Mon, Jul 20, 2020 at 1:29 AM Thomas Munro wrote:
>
> On Fri, May 1, 2020 at 1:53 PM James Coleman wrote:
> > In another thread [1] I'd mused that "there might be some value in a
> > README or comments
> > addition that would be a guide to what the various h
On Wed, Jul 29, 2020 at 11:24 AM Fujii Masao
wrote:
>
>
>
> On 2020/04/03 22:49, James Coleman wrote:
> > On Thu, Apr 2, 2020 at 5:53 PM David Zhang wrote:
> >>
> >> The following review has been posted through the commitfest application:
> >> make in
On Fri, Jul 31, 2020 at 8:17 PM Thomas Munro wrote:
>
> 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
>
s a
worker line, likely with a "leader" tag), but that seems like a big
change to make now. On the other hand, perhaps designating what looks
like a summary line as the "leader" or some such would help clear up
the confusion? Perhaps it could also say "Participating" or
"Non-participating"?
James
ng
pg_sequence_last_value() in the sequence manipulation functions doc
page?
James
ertainly needs to be
> updated by any patch that's going to change the rules.
Agreed that the comment needs to be updated to discuss the
(im)possibility of arbitrary operations within a snapshot held by CIC.
James
On Tue, Aug 11, 2020 at 2:55 AM Masahiko Sawada
wrote:
>
> On Tue, 11 Aug 2020 at 07:56, Alvaro Herrera wrote:
> >
> > Last week, James reported to us that after promoting a replica, some
> > seqscan was taking a huge amount of time; on investigation he saw that
>
On Tue, Aug 11, 2020 at 11:14 AM Tom Lane wrote:
>
> James Coleman writes:
> > Why is a CIC in active index-building something we need to wait for?
> > Wouldn't it fall under a similar kind of logic to the other snapshot
> > types we can explicitly ignore?
On Tue, Aug 18, 2020 at 12:25 PM Fujii Masao
wrote:
> Thanks for updating the patch! But it failed to be applied to the master
> branch
> cleanly because of the recent commit 0038f94387. So could you update the patch
> again?
Updated patch attached.
James
v3-0001-Improve-standb
On Fri, Jul 31, 2020 at 2:51 PM James Coleman wrote:
>
> On Thu, Jul 16, 2020 at 7:34 PM David Johnston
> wrote:
> >
> > The following review has been posted through the commitfest application:
> > make installcheck-world: not tested
> > Implements feature:
lyze; and also:
>
> Note that this quasi-related patch has pretty thoroughly hijacked
> the CF entry for James' original docs patch proposal. The cfbot
> thinks that that's the latest patch in the original thread, and
> unsurprisingly is failing to apply it.
>
> Since
On Wed, Aug 19, 2020 at 3:16 AM Heikki Linnakangas wrote:
>
> On 01/05/2020 05:20, James Coleman wrote:
> > On Tue, Apr 28, 2020 at 8:25 AM Tomas Vondra
> > wrote:
> > ...
> >> Any particular reasons to pick dynahash over simplehash? ISTM we're
> >
Nice repro, thanks!
--
James Hunter, Amazon Web Services (AWS)
On 9/10/20 7:37 PM, Justin Pryzby wrote:
Against all odds, I was able to reproduce this.
begin;
CREATE TABLE t AS SELECT generate_series(1,99)i;
ALTER TABLE t SET (parallel_workers=2, autovacuum_enabled=off);
CREATE INDEX ON t
On Wed, Sep 8, 2021 at 8:47 AM James Coleman wrote:
> See updated patch series attached.
Jaime,
I noticed on 3-October you moved this into "waiting on author"; I
don't see anything waiting in this thread, however. Am I missing
something?
I'm planning to change i
On Fri, Jul 16, 2021 at 3:16 PM James Coleman wrote:
>
> On Thu, May 27, 2021 at 9:01 PM Greg Nancarrow wrote:
> >
> > On Tue, Dec 8, 2020 at 10:46 AM James Coleman wrote:
> > >
> > > While I haven't actually tracked down to guarantee this is handled
&
er than anyone.
>
> On Fri, May 7, 2021 at 12:30 PM James Coleman wrote:
> > The basic idea is that we need to track (both on nodes and relations)
> > not only whether that node or rel is parallel safe but also whether
> > it's parallel safe assuming params are rechecke
Yes, planning on it, just a bit behind right now so will likely be a
few more days at least.
On Thu, Sep 5, 2019 at 4:57 PM Alvaro Herrera from 2ndQuadrant
wrote:
>
> On 2019-Aug-26, Tom Lane wrote:
>
> > James Coleman writes:
>
> > I think the comment is fine as-is. P
s are useful? I'm not
> sure what the next steps are for this patch.
I wanted to note here that I haven't abandoned this patch, but ended
up needing to use my extra time for working on a conference talk. That
talk is today, so I'm hoping to be able to catch up on this again
soon.
James Coleman
On Fri, Sep 13, 2019 at 10:54 AM Tomas Vondra
wrote:
>
> On Thu, Sep 12, 2019 at 11:54:06AM -0400, James Coleman wrote:
> >> OK, so we have that now. I suppose this spreadsheet now tells us which
> >> places are useful and which aren't, at least for the queries t
on
the source of any copied blocks.
So I've attached a patch to summarize more correctly as well as
document clearly the state of the cluster after the operation and also
the operation sequencing dangers caused by copying configuration
files from the source.
James Coleman
001_pg_rewind_ex
On Sat, Aug 31, 2019 at 10:51 PM Amit Kapila wrote:
>
> On Fri, Jul 26, 2019 at 1:45 AM James Coleman wrote:
> >
> > We've discussed this internally many times, but today finally decided
> > to write up a doc patch.
> >
>
> Thanks, I think something
On Sat, Sep 14, 2019 at 12:20 AM Michael Paquier wrote:
>
> On Fri, Sep 13, 2019 at 01:47:03PM -0400, James Coleman wrote:
> > So I've attached a patch to summarize more correctly as well as
> > document clearly the state of the cluster after the operation and also
>
On Sun, Sep 15, 2019 at 10:25 AM Michael Paquier wrote:
>
> On Sat, Sep 14, 2019 at 07:00:54PM -0400, James Coleman wrote:
> > Updated (plus some additional wordsmithing).
>
> +The rewind operation is not expected to result in a consistent data
> +directory state eit
of me wants to pull it over to a separate thread just to get
additional feedback, but I'm not sure how useful that is given we
don't currently have an example case outside of this patch.
One thing to note though: the current patch does not also modify
add_partial_path_precheck which also does not take into account
startup cost, so we probably need to update that for completeness's
sake.
James Coleman
On Tue, Sep 17, 2019 at 2:21 AM Amit Kapila wrote:
>
> On Fri, Sep 13, 2019 at 11:59 PM James Coleman wrote:
> >
> > On Sat, Aug 31, 2019 at 10:51 PM Amit Kapila
> > wrote:
> > >
> >
> > Updated patch attached. I changed the wording to be about co
On Tue, Sep 17, 2019 at 3:51 AM Michael Paquier wrote:
>
> On Sun, Sep 15, 2019 at 10:36:04AM -0400, James Coleman wrote:
> > On Sun, Sep 15, 2019 at 10:25 AM Michael Paquier
> > wrote:
> >> +The rewind operation is not expected to result in a consistent dat
various stages might change the results.
James Coleman
commit 9e28e704820eebb81ff94c1c3cbfb7db087b2c45
Author: James Coleman
Date: Wed Sep 18 13:36:22 2019 -0400
Document concurrent indexes waiting on each other
It's not immediately obvious that because concurrent index b
s does rely on these gucs set in the
test harness:
set local max_parallel_workers_per_gather=4;
set local min_parallel_table_scan_size=0;
set local parallel_tuple_cost=0;
set local parallel_setup_cost=0;
So I think we can reduce the number of unused gucs to 3.
James
then, and maybe that would shed some light on whether
it's still inherently true.
I've attached a patch (by Tomas Vondra, also cc'd) to consider startup
cost in add_partial_path, but should we apply the patch we'll also
likely need to apply the same kind of change to
ad
On Mon, Sep 16, 2019 at 6:32 AM Tomas Vondra
wrote:
>
> On Sun, Sep 15, 2019 at 09:33:33PM -0400, James Coleman wrote:
> >On Sat, Jul 20, 2019 at 11:25 AM Tomas Vondra
> > wrote:
> >> >> ...
> >> >>
> >> >> I think this may be a thi
On Saturday, September 28, 2019, Tomas Vondra
wrote:
> On Sat, Sep 28, 2019 at 12:16:05AM -0400, Robert Haas wrote:
>
>> On Fri, Sep 27, 2019 at 2:24 PM James Coleman wrote:
>>
>>> Over in the incremental sort patch discussion we found [1] a case
>>> wh
You mean multiple CICs on a single table at the same time? Yes, that
(unfortunately) isn't possible, but I'm concerned in the patch with
the fact that CIC on table X blocks CIC on table Y.
James
On Sat, Sep 28, 2019 at 9:56 PM Bruce Momjian wrote:
>
> On Sat, Sep 28, 2019 at 09:54:48PM -0400, James Coleman wrote:
> > On Sat, Sep 28, 2019 at 9:22 PM Alvaro Herrera
> > wrote:
> > >
> > > On 2019-Sep-28, Bruce Momjian wrote:
> > &
On Sat, Sep 28, 2019 at 7:21 PM James Coleman wrote:
> Now the trick is to figure out a way to demonstrate it in test :)
>
> Basically we need:
> Path A: Can short circuit with LIMIT but has high total cost
> Path B: Can’t short circuit with LIMIT but has lower total cost
&g
On Fri, Oct 4, 2019 at 8:36 AM Robert Haas wrote:
>
> On Wed, Oct 2, 2019 at 10:22 AM James Coleman wrote:
> > In all cases I've been starting with:
> >
> > set enable_hashjoin = off;
> > set enable_nestloop = off;
> > set max_parallel_workers_per_gather
On Fri, Mar 1, 2019 at 5:28 PM Tom Lane wrote:
>
> James Coleman writes:
> > [ saop_is_not_null-v10.patch ]
>
> I went through this again, and this time (after some more rewriting
> of the comments) I satisfied myself that the logic is correct.
> Hence, pushed.
Thanks!
On Sat, Mar 2, 2019 at 5:29 PM Tom Lane wrote:
>
> James Coleman writes:
> > On Fri, Mar 1, 2019 at 5:28 PM Tom Lane wrote:
> >> I also tweaked it to recognize the case where we can prove the
> >> array, rather than the scalar, to be null. I'm not sure how u
ch to document that behavior (as opposed to just in
the code at src/backend/storage/lmgr/proc.c:1320-1321).
James Coleman
autovacuum-interruption-v1.patch
Description: Binary data
On Tue, Jan 21, 2020 at 9:25 AM Tomas Vondra
wrote:
>
> Hi,
>
> This patch has been marked as WoA since end of November, and there has
> been no discussion/reviews since then :-( Based on off-list discussion
> with James I don't think that's going to change in this
On Tue, Jan 21, 2020 at 9:58 AM Tomas Vondra
wrote:
>
> On Tue, Jan 21, 2020 at 09:37:01AM -0500, James Coleman wrote:
> >On Tue, Jan 21, 2020 at 9:25 AM Tomas Vondra
> > wrote:
> >>
> >> Hi,
> >>
> >> This patch has been marked as WoA since
changes you were
hoping to make after conversations you'd had with others? I'm hoping
for any pointers/context you have from those conversations as to what
you felt was necessary to get this change committed.
Thanks,
James Coleman
I've rebased the patch on master and confirmed make check world passes.
incremental-sort-27.patch
Description: Binary data
in not having to pull many more tuples in a
regular sort node, but the fallback logic kicks in anyway.
Unrelated to all of the above: if I read the patch properly it
intentionally excludes backwards scanning. I don't see any particular
reason why that ought to be the case, and it seems like an odd
limitation for the feature should it be merged. Should that be a
blocker to merging?
James Coleman
Bump, and curious if anyone on hackers has any ideas here: of particular
interest is why the (pk, created_at) index can possibly be more valuable
than the (created_at, pk) variant since the former effectively implies
having to scan the entire index.
On Fri, Sep 7, 2018 at 12:17 PM James Coleman
than continuing to execute?
Thanks,
James Coleman
Perfect. Thanks for the pointer, Andres, that's exactly what I was looking
for.
On Mon, Oct 15, 2018 at 1:28 PM Andres Freund wrote:
> Hi,
>
> On 2018-10-15 13:21:04 -0400, James Coleman wrote:
> > This my first real foray into the Postgres codebase, so an beginner
> >
n) into
tuple_data_{split,record}(). I'd appreciate feedback on this possibility.
TODO:
- Add documentation.
- Consider inlining _internal functions.
Thanks,
James Coleman
tuple-data-record-v1.patch
Description: Binary data
s like maybe the style guide could be a bit more
descriptive in some of these areas to be more friendly to newcomers. In
contrast the wiki page for submitting a patch is extremely detailed.
Thanks,
James Coleman
>
>
> I did compleatly got the question... The question is it safe to split
> tuple
> record into array of raw bytea? It is quite safe from my point of view.
> We
> use only data that is inside the tuple, and info from pg_catalog that
> describes the tuple structure. So we are not affected if for e
Indeed. But I do think your approach - which means that the binary data is
> actually interpreded as a datum of a specific type, drastically
> increases the risk.
>
>
Agreed.
As I noted earlier, I don't at all think deTOASTing is a must for this
function to be
valuable, just as tuple_data_split()
> It's far from only toast that could be problematic here.
>
Do you have an example in mind? Wouldn’t the tuples have to be corrupted in
some way to have problems with being interpreted as a datum? Or are you
thinking very old tuples with a radically different structure to be causing
the problem?
> There's plenty ways it can go horribly wrong. Let's start with something
> simple:
>
> BEGIN;
> ALTER TABLE ... ADD COLUMN blarg INT;
> INSERT ... (blag) VALUES (132467890);
> ROLLBACK;
>
> ALTER TABLE ... ADD COLUMN blarg TEXT;
>
> If you now read the table with your function you'll see a dead r
> I don't see why you'd get that error, if you re-add a column (with a
> different type), as I did above? Obviously the "replacement" column
> addition would need to be committed.
>
Here's my test case:
CREATE TABLE t3(i INTEGER);
BEGIN;
ALTER TABLE t3 ADD COLUMN blarg INT;
INSERT INTO t3(bla
a GUC knob?"
Status:
The attached patch applies cleanly to master, builds without error,
and passes tests locally.
Thanks,
James Coleman
array_optimization_size_limit_guc-v1.patch
Description: Binary data
Should I add additional tests for predtest? It already seems to cover some
null
test cases with scalar array ops, but I'd be happy to add more if desired.
Should I add a test case for the resulting plan with "foo IN (...)" with an
array with more than 100 elements?
Thanks,
James Coleman
saop_is_not_null-v1.patch
Description: Binary data
Note: the original email from David went to my spam folder, and it also
didn't show up on the archives (I assume caught by a spam filter there
also?)
Thanks for taking this on!
>
> As far as you can tell, is the default correct at 100?
>
I'm not sure what a good way of measuring it would be (that
master if you remove items from the test array to make the array <=
100 items) as well as a comment detailing the reasoning in predtest.c.
On Sat, Nov 10, 2018 at 4:33 PM James Coleman wrote:
>
> I've recently been investigating improving our plans for queries like:
> SELECT *
Also, my apologies for top posting; I forgot to remove the old email
before clicking send.
> Is skip scan only possible for index-only scan?
I haven't see much discussion of this question yet. Is there a
particular reason to lock ourselves into thinking about this only in
an index only scan?
>> I think we can improve this,
>> and the skip scan can be strictly faster than index scan reg
> > My main comment is that the description of the purpose of the GUC doesn't
> > help me understand when or why I might want to alter it from the default
> > value. If nobody is going to alter it, because nobody understands it, it
> > might as well remain a compile-time constant.
>
> Yeah, that's
>> I'd be happy to yank this in favor of my holistic solution to this
>> problem I posted recently on the mailing list [1].
>
> [1]
> https://www.postgresql.org/message-id/flat/CAAaqYe8yKSvzbyu8w-dThRs9aTFMwrFxn_BkTYeXgjqe3CbNjg%40mail.gmail.com
>
> Not precisely sure what you mean - are you sayin
On Fri, Dec 22, 2023 at 2:48 PM Tom Lane wrote:
>
> James Coleman writes:
> > I've not yet applied all of your feedback, but I wanted to get an
> > initial read on your thoughts on how using switch statements ends up
> > looking. Attached is a single (pure refa
mit_lsn() is marked as STABLE which is
> probably correct. But I would appreciate a second opinion on this.
Sounds good.
> - Wouldn't it be appropriate to add a test or two?
Added.
> - `if (!XLogRecPtrIsInvalid(commit_lsn))` - I suggest adding
> XLogRecPtrIsValid() macro for better read
On Sun, Jan 14, 2024 at 6:01 AM vignesh C wrote:
>
> On Sat, 10 Jun 2023 at 07:57, James Coleman wrote:
> >
> > I've previously noted in "Add last commit LSN to
> > pg_last_committed_xact()" [1] that it's not possible to monitor how
> > many
cation on the read column the error is more understandable:
ERROR: column reference "bar" is ambiguous
It seems to me that it'd be desirable to either allow the unnecessary
qualification or give an error that's more easily understood.
Regards,
James Coleman
On Fri, Jan 19, 2024 at 1:53 PM David G. Johnston
wrote:
>
> On Fri, Jan 19, 2024 at 10:01 AM James Coleman wrote:
>>
>> Making this more confusing is the fact that if I want to do something
>> like "SET bar = foo.bar + 1" the table qualification cannot be prese
On Sat, Jan 20, 2024 at 11:12 AM Tom Lane wrote:
>
> James Coleman writes:
> > Suppose I have this table:
> > create table foo (id int primary key);
>
> > On PG11 this works:
> > postgres=# insert into foo (id) values (1) on conflict (id) do update
> > set
On Sat, Jan 20, 2024 at 12:59 PM Tom Lane wrote:
>
> James Coleman writes:
> > I do wonder if it's plausible (and sufficiently easy) to improve the
> > error message here. "column 'foo' of relation 'foo'" makes one thing
> > that you&#
On Sat, Jan 20, 2024 at 5:57 PM Tom Lane wrote:
>
> James Coleman writes:
> > On Sat, Jan 20, 2024 at 12:59 PM Tom Lane wrote:
> >> A HINT if the bogus column name (1) matches the relation name and
> >> (2) is field-qualified seems plausible to me. Then it
f necessary.
>
> ==
> [1]
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/46/4355
>
> Kind Regards,
> Peter Smith.
Updated patch attached,
Thanks,
James Coleman
v3-0001-Add-last-commit-s-LSN-to-pg_stat_database.patch
Description: Binary data
f necessary.
>
> ==
> [1] https://commitfest.postgresql.org/46/4384//
> [2]
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/46/4384
See rebased patch attached.
Thanks,
James Coleman
v3-0001-Allow-getting-lock-before-calling-heap_page_prune.patch
Descripti
On Mon, Jan 22, 2024 at 8:21 PM James Coleman wrote:
>
> See rebased patch attached.
I just realized I left a change in during the rebase that wasn't necessary.
v4 attached.
Regards,
James Coleman
v4-0002-Opportunistically-prune-to-avoid-building-a-new-p.patch
Description: Binar
On Tue, Jan 23, 2024 at 2:46 AM Dilip Kumar wrote:
>
> On Tue, Jan 23, 2024 at 7:18 AM James Coleman wrote:
> >
> > On Mon, Jan 22, 2024 at 8:21 PM James Coleman wrote:
> > >
> > > See rebased patch attached.
> >
> > I just realized I left a c
On Fri, Jan 26, 2024 at 8:33 PM James Coleman wrote:
>
> On Tue, Jan 23, 2024 at 2:46 AM Dilip Kumar wrote:
> >
> > On Tue, Jan 23, 2024 at 7:18 AM James Coleman wrote:
> > >
> > > On Mon, Jan 22, 2024 at 8:21 PM James Coleman wrote:
> > > >
&
ross worker boundaries. However
looking at the diff in the patch at that point (v10) that particular
test query formed a different plan shape (there were two gather nodes
being created, and params crossing between them).
But in the current revision of master with the current patch applied
that's
so there's been nothing to reply to.
That being said, Vignesh's note in January about a now-failing test is
relevant activity, and I've just today responded to that, so I'm
changing the status back from Waiting on Author to Needs Review.
Regards,
James Coleman
On Tue, Jan 30, 2024 at 10:34 PM Tom Lane wrote:
>
> James Coleman writes:
> > I've finally had a chance to look at this, and I don't believe there's
> > any real failure here, merely drift of how the planner works on master
> > resulting in this query
e any reason why this
couldn't happen separately. That being said, on master I don't have a
case showing this is necessary.
Thanks,
James Coleman
1:
https://www.postgresql.org/message-id/flat/CAAaqYe-Aq6oNf9NPZnpPE7SgRLomXXWJA1Gz9L9ndi_Nv%3D94Yw%40mail.gmail.com#e0b1a803d0fdb971
On Wed, Jan 31, 2024 at 3:18 PM Robert Haas wrote:
>
> On Tue, Jan 30, 2024 at 9:56 PM James Coleman wrote:
> > I don't follow the "Idle since July" since it just hasn't received
> > review since then, so there's been nothing to reply to.
>
> It
On Thu, Feb 1, 2024 at 1:36 AM Richard Guo wrote:
>
>
> On Thu, Feb 1, 2024 at 11:37 AM David Rowley wrote:
>>
>> On Thu, 1 Feb 2024 at 16:29, Richard Guo wrote:
>> > On Thu, Feb 1, 2024 at 10:04 AM James Coleman wrote:
>> >> I don't see any
ble.
I'm wondering if this might be a surprise to anyone else, and if so,
is there a minor docs tweak that might avoid the confusion?
Thanks,
James Coleman
1:
https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-REPLICA-IDENTITY
2: https://www.postgresql.org/docs/current/logical-replication-publication.html
On Wed, Feb 7, 2024 at 3:22 PM Laurenz Albe wrote:
>
> On Wed, 2024-02-07 at 15:12 -0500, James Coleman wrote:
> > We recently noticed some behavior that seems reasonable but also
> > surprised our engineers based on the docs.
> >
> > If we have this setup
On Wed, Feb 7, 2024 at 6:04 PM Peter Smith wrote:
>
> On Thu, Feb 8, 2024 at 9:04 AM James Coleman wrote:
> >
> > On Wed, Feb 7, 2024 at 3:22 PM Laurenz Albe
> > wrote:
> > >
> > > On Wed, 2024-02-07 at 15:12 -0500, James Coleman wrote:
> >
or index that doesn't exist) is added ...
I think that would work also. I was reading the initial suggestion as
"(or with replica identity behavior the same as..." as defining what
"without a replica identity" meant, which would avoid the confusion.
But your proposal is more explicit and more succinct, so I think it's
the better option of the two.
Regards,
James Coleman
> NOTHING
>
> Records no information about the old row. This is equivalent to having
> no replica identity. This is the default for system tables.
This is the simplest change, and it does solve the confusion, so I'd
be happy with it also. The other proposals have the benefit of having
all the information necessary on the publications page rather than
requiring the user to refer to the ALTER TABLE REPLICA IDENTITY page
to understand what's meant.
Regards,
James Coleman
his thread earlier.
>
> I didn't realize that we had a notice about this in the docs. I'll go
> and remove that. Thanks!
>
> - Heikki
>
Thanks; I think the missing [1] (for reference) is:
https://www.postgresql.org/message-id/9f568c97-87fe-a716-bd39-65299b8a60f4%40iki.fi
James
On Thu, Mar 14, 2024 at 10:28 AM Robert Haas wrote:
>
> On Wed, Oct 4, 2023 at 9:12 PM James Coleman wrote:
> > All right, attached is a v3 which attempts to fix the wrong
> > information with an economy of words. I may at some point submit a
> > separate patch tha
On Wed, Mar 20, 2024 at 2:15 PM Robert Haas wrote:
>
> On Thu, Mar 14, 2024 at 9:07 PM James Coleman wrote:
> > Obviously I have reasons for the other changes I made: for example,
> > "no longer visible" improves the correctness, since being an old
> > version i
On Thu, Mar 21, 2024 at 1:09 PM Robert Haas wrote:
>
> On Thu, Mar 14, 2024 at 9:07 PM James Coleman wrote:
> > If the goal here is the most minimal patch possible, then please
> > commit what you proposed. I am interested in improving the document
> > further, but I d
tant, but perhaps future readers of the archives will
> be confused.
I was wondering myself :) so thanks for clarifying.
Regards,
James Coleman
On Mon, Mar 25, 2024 at 5:53 PM Tom Lane wrote:
>
> James Coleman writes:
> > [ v6 patchset ]
>
> I went ahead and committed 0001 after one more round of review
>
> statements; my bad). I also added the changes in test_predtest.c from
> 0002. I attach a rebased versi
On Mon, Apr 1, 2024 at 8:06 AM James Coleman wrote:
>
> On Mon, Mar 25, 2024 at 5:53 PM Tom Lane wrote:
> >
> > James Coleman writes:
> > > [ v6 patchset ]
> >
> > I went ahead and committed 0001 after one more round of review
> >
> >
ewhere. That's not likely to ever be as stable as we want
> PostgreSQL to be.
This is potentially a bit of a wild idea, but I wonder if having some
kind of argument to CHECK_FOR_INTERRUPTS() signifying we're in
"normal" as opposed to "critical" (using that word differently than
the existing critical sections) would be worth it.
Regards,
James Coleman
On Fri, Feb 23, 2024 at 10:23 AM Robert Haas wrote:
>
> On Fri, Feb 23, 2024 at 7:50 PM Julien Rouhaud wrote:
> > On Fri, Feb 23, 2024 at 10:22:32AM +0530, Robert Haas wrote:
> > > On Thu, Feb 22, 2024 at 6:25 AM James Coleman wrote:
> > > > This is potent
>
> If this is correctly implemented, the overhead in the case where the
> feature isn't used should be essentially zero, I believe.
If I can rephrase this idea: it's basically "delay this interrupt
until inline to the next ExecProcNode execution".
That seems pretty promising to me as well.
Regards,
James Coleman
This patch looks good to me. I have two very minor nits: The inflation of the
sample size by 10% is arbitrary but it doesn't seem unreasonable or concerning.
It just makes me curious if there are any known cases that motivated adding
this logic. Secondly, if the earliest non-deprecated versio
101 - 200 of 695 matches
Mail list logo
