On Fri, Aug 30, 2024 at 1:00 AM Alexander Lakhin wrote:
> I looked at two perf profiles of such out-of-sync processes and found no
> extra calls or whatsoever in the slow one, it just has the number of perf
> samples increased proportionally. It made me suspect CPU frequency
> scaling... Indeed, w
Hello Tom,
30.08.2024 23:55, Tom Lane wrote:
Pushed with that addition and some comment-tweaking. We'll see
whether that actually makes things more stable, but I don't think
it could make it worse.
Thank you for fixing that issue!
I've tested your fix with the modification I proposed upthrea
Pushed. Thanks!
On Thu, Aug 29, 2024 at 03:48:53PM -0500, Masahiko Sawada wrote:
> On Sun, May 19, 2024 at 6:46 AM Noah Misch wrote:
> > If I were standardizing pg_trgm on one or the other notion of "char", I
> > would
> > choose signed char, since I think it's still the majority. More broadly, I
> > see these
On Thu, Aug 15, 2024 at 5:06 AM Imseih (AWS), Sami wrote:
>
> > I think the testing discussion should be moved to a different thread.
> > What do you think?
> See v4.
>
> 0001 deals with reporting queryId in exec_execute_message and
> exec_bind_message.
> 0002 deals with reporting queryId after a
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 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, 2024 at 05:05:48PM -0700, Noah M
LGTM in general, but here are some final nitpicks:
+ if (maxFd != 0)
+ (void) select(maxFd + 1, &input_mask, &output_mask,
&except_mask, NULL);
It’s a good idea to check for the return value of select, in case it returns
any errors.
+ dbs_complete++;
+
On Sat, Aug 31, 2024 at 10:17 AM Heikki Linnakangas wrote:
> > * This direction seems to fit quite nicely with future ideas about
> > asynchronous network I/O. That may sound unrelated, but imagine that
> > a future version of WaitEventSet is built on Linux io_uring (or
> > Windows iorings, or Wi
On Tue, Aug 27, 2024 at 10:49:19AM +0300, Nazir Bilal Yavuz wrote:
> On Fri, 23 Aug 2024 at 22:01, Noah Misch wrote:
> > On Fri, Aug 23, 2024 at 02:20:06PM +0300, Nazir Bilal Yavuz wrote:
> > > On Tue, 20 Aug 2024 at 21:47, Noah Misch wrote:
> > > > On Tue, Aug 13, 2024 at 03:22:27PM +0300, Nazir
On Fri, 30 Aug 2024 at 22:12, Tom Lane wrote:
>
> Jelte Fennema-Nio writes:
> > On Fri, Aug 30, 2024, 21:21 Tom Lane wrote:
> >> While we're piling on, has anyone noticed that *non* Windows buildfarm
> >> animals are also failing this test pretty frequently?
>
> > Yes. Fixes are here (see the ~1
On Fri, Aug 30, 2024 at 04:07:30PM -0400, Robert Haas wrote:
> On Thu, Aug 29, 2024 at 1:36 PM Nathan Bossart
> wrote:
>> Thanks. Robert, do you have any concerns with this?
>
> I don't know if I'm exactly concerned but I don't understand what
> problem we're solving, either. I thought Ayush sa
I wrote:
> Hmm. I'm not convinced that 0001 is an actual *fix*, but it should
> at least reduce the frequency of occurrence a lot, which'd help.
After enabling log_statement = all to verify what commands are being
sent to the remote, I realized that there's a third thing this patch
can do to stab
On 8/30/24 16:12, Andrew Dunstan wrote:
Sorry for empty reply. Errant finger hit send.
No problem.
So anyway... my main point is to highlight this:
On 2024-08-29 Th 5:50 PM, Mark Murawski wrote:
And then in this hypothetical situation -- magic ensues, and you're
left with this:
# t
Hello Hackers,
While working on inlining non-SQL SRFs [1] I noticed we don't have tests for when a PL/pgSQL
function requires materialize mode but doesn't have a result TupleDesc. Here is a patch adding tests
for that, as well as some other conditions around SRF calls with `SETOF RECORD` vs `TA
On 2024-08-30 Fr 3:49 PM, Andrew Dunstan wrote:
Sorry for empty reply. Errant finger hit send.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Jelte Fennema-Nio writes:
> On Fri, Aug 30, 2024, 21:21 Tom Lane wrote:
>> While we're piling on, has anyone noticed that *non* Windows buildfarm
>> animals are also failing this test pretty frequently?
> Yes. Fixes are here (see the ~10 emails above in the thread for details):
> https://www.pos
On 2024-08-29 Th 4:44 PM, Jacob Champion wrote:
As for the other patches, I'll ping Andrew about 0001,
Patch 0001 looks sane to me.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On Thu, Aug 29, 2024 at 1:36 PM Nathan Bossart wrote:
> Thanks. Robert, do you have any concerns with this?
I don't know if I'm exactly concerned but I don't understand what
problem we're solving, either. I thought Ayush said that the function
wouldn't produce useful results for sequences; so th
On Fri, Aug 30, 2024 at 1:42 PM Jeff Davis wrote:
> As far as performance goes, I'm only looking at branch in add_path()
> that calls compare_pathkeys(). Do you have some example queries which
> would be a worst case for that path?
I think we must be talking past each other somehow. It seems to m
On 2024-08-29 Th 5:50 PM, Mark Murawski wrote:
On 8/29/24 16:54, Andrew Dunstan wrote:
On 2024-08-29 Th 1:01 PM, Mark Murawski wrote:
On 8/29/24 11:56, Andrew Dunstan wrote:
On 2024-08-28 We 5:53 PM, Mark Murawski wrote:
Hi Hackers!
This would be version v1 of this feature
Basically
On Fri, Aug 30, 2024, 21:21 Tom Lane wrote:
>
> While we're piling on, has anyone noticed that *non* Windows buildfarm
> animals are also failing this test pretty frequently?
>
Any thoughts?
>
Yes. Fixes are here (see the ~10 emails above in the thread for details):
https://www.postgresql.org/
On Mon, 19 Aug 2024 at 13:43, Matthias van de Meent
wrote:
>
> On Sun, 11 Aug 2024 at 21:44, Peter Geoghegan wrote:
> >
> > On Tue, Aug 6, 2024 at 6:31 PM Matthias van de Meent
> > wrote:
> > > +1, LGTM.
> > >
> > > This changes the backward scan code in _bt_readpage to have an
> > > approximate
Alexander Lakhin writes:
> Let me show you another related anomaly, which drongo kindly discovered
> recently: [1]. That test failed with:
> SELECT dblink_cancel_query('dtest1');
> - dblink_cancel_query
> --
> - OK
> + dblink_cancel_query
> +--
> + c
On Wed, Aug 28, 2024 at 8:21 AM Nazir Bilal Yavuz wrote:
> I do not exactly remember the reason but I think I copied the same
> behavior as before, PG_TEST_EXTRA variable was checked in the
> src/test/Makefile so I exported it there.
Okay, give v3 a try then. This exports directly from Makefile.g
On Fri, 2024-08-30 at 07:33 -0400, Robert Haas wrote:
> This is a fair point. I dislike the fact that add_path() is a thicket
> of if-statements that's actually quite hard to understand and easy to
> screw up when you're making modifications. But I feel like it would
> be
> difficult to generalize
On 7/26/24 11:58, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 28/06/2024 01:01, Paul Jungwirth wrote:
>>> Another approach I considered is using a separate support request, e.g.
SupportRequestInlineSRF, and
>>> just calling it from inline_set_returning_function. I didn't like having
two
On 8/29/24 1:51 PM, David Rowley wrote:
I had planned to work on this for PG18, but I'd be happy for some
assistance if you're willing.
I am interested in working on this, unless Andy Fan wants to do this
work. :) I believe that optimizing the out, in and send functions would
be worth the pai
I normally wouldn't mention my blog entries here, but this one was about
the hackers mailing list, so wanted to let people know about it in case you
don't follow Planet Postgres. I scanned the last year's worth of posts and
gathered the most used acronyms and jargon. The most commonly used acronym
On Wed, 28 Aug 2024 at 15:53, Peter Geoghegan wrote:
> On Wed, Aug 28, 2024 at 9:49 AM Robert Haas wrote:
> > On Wed, Aug 28, 2024 at 9:41 AM Peter Geoghegan wrote:
> > > On Wed, Aug 28, 2024 at 9:35 AM Robert Haas wrote:
> > > > > If you think it's important to have this info on all indexes th
> From this discussion, there is desire for a sleep function that:
> 1/ Sleeps for the full duration of the requested time
> 2/ Continues to handle important interrupts during the sleep
>
> While something like CF 5118 will take care of point #1,
> I'm not sure, even with CF entry 5118, nanoslee
I created a commitfest entry[1] to have the CI test the patch. There
was a failure in headerscheck and cpluspluscheck when the include of
SectionMemoryManager.h is checked[2]
In file included from /usr/include/llvm/ADT/SmallVector.h:18,
from /tmp/cirrus-ci-build/src/include/jit/SectionMemoryManage
On Fri, Aug 30, 2024 at 7:36 AM b ro wrote:
> this is the patch attachment.
We discussed this recently:
https://www.postgresql.org/message-id/80384.1715458896%40sss.pgh.pa.us
I think that we should do this.
It doesn't make a huge difference in practice, because we'll still end
the scan o
On 8/30/24 5:55 AM, Xing Guo wrote:
I find there are some unnecessary load/store instructions being
emitted by the JIT compiler.
Well spotted! All of these are obvious dead instructions and while LLVM
might be able to optimize them away there is no reason to create extra
work for the optimize
Hi,
On Fri, Aug 30, 2024 at 03:34:56PM +0900, Michael Paquier wrote:
> On Tue, Aug 20, 2024 at 04:23:06PM +, Bertrand Drouvot wrote:
> > Please find attached v3 that:
> >
> > - takes care of your comments (and also removed the use of PG_TBLSPC_DIR in
> > RELATIVE_PG_TBLSPC_DIR).
> > - removes
On 8/29/24 4:53 PM, Frédéric Yhuel wrote:
So I think we should just use PageGetExactFreeSpace().
I agree, I feel that is the least surprising behavior because we
currently sum tiny amounts of free space that is unusable anyway. E.g.
imagine one million pages with 10 free bytes each, that look
Hi,
On Fri, Aug 30, 2024 at 03:43:12PM +0530, Amit Kapila wrote:
> On Thu, Aug 29, 2024 at 6:33 PM Bharath Rupireddy
> wrote:
> >
> > On Thu, Aug 29, 2024 at 3:44 PM Bertrand Drouvot
> > wrote:
> > >
> > > Yeah that's fair. And now I'm wondering if we need an extra module. I
> > > think
> > > w
Hi,
this is the patch attachment.
发件人: b ro
发送时间: 2024年8月30日 0:56
收件人: pgsql-hackers
主题: bt Scankey in another contradictory case
Hi,
when i read source code of the part of nbtree, i detected another kind of
contradictory case postgresql has not eliminate
Hi,
when i read source code of the part of nbtree, i detected another kind of
contradictory case postgresql has not eliminated
(eg. x >4 and x <3) in the function _bt_preprocess_keys in nbtutils.c. this
cause next unnecessary index scan and qual evaluation.
it seems no one will write SQL like th
On Thu, Aug 29, 2024 at 6:49 PM Jeff Davis wrote:
> I don't see that in the code yet, so I assume you are referring to the
> comment at [1]?
FYI, I'm hacking on a revised approach but it's not ready to show to
other people yet.
> I still like my idea to generalize the pathkey infrastructure, and
Hi,
On Tue, Aug 27, 2024 at 8:01 PM Antonin Houska wrote:
>
> Attached is version 2, the feature itself is now in 0004.
>
> Unlike version 1, it contains some regression tests (0006) and a new GUC to
> control how long the AccessExclusiveLock may be held (0007).
>
> Kirill Reshke wrote:
>
> > On
On Thu, Aug 29, 2024 at 6:33 PM Bharath Rupireddy
wrote:
>
> On Thu, Aug 29, 2024 at 3:44 PM Bertrand Drouvot
> wrote:
> >
> > Yeah that's fair. And now I'm wondering if we need an extra module. I think
> > we could "simply" expose 2 new functions in core, thoughts?
> >
> > > > What do you think?
On 28.08.24 18:31, Jacob Champion wrote:
On Mon, Aug 26, 2024 at 4:23 PM Jacob Champion
wrote:
I was having trouble reasoning about the palloc-that-isn't-palloc code
during the first few drafts, so I will try a round with the jsonapi_
prefix.
v27 takes a stab at that. I have kept the ALLOC/FR
> BTW, we should do some performance testing by having a mix of DML and
> DDLs to see the performance impact of this patch.
>
> [1] -
> https://www.postgresql.org/message-id/CAD21AoAenVqiMjpN-PvGHL1N9DWnHSq673bfgr6phmBUzx=k...@mail.gmail.com
>
I did some performance testing and I found some perfo
Hi,
On Thu, Aug 29, 2024 at 02:15:47PM +, Bertrand Drouvot wrote:
> I don't see any use case where it could be useful when the server is down. So,
> I think I'll move forward with in core functions (unless someone has a
> different
> opinion).
>
Please find v2 attached that creates the 2 ne
Hi Michael,
On Fri, 23 Aug 2024 at 22:01, Michael Harris wrote:
> V2 of the patch is attached.
(I understand this is your first PostgreSQL patch)
I just wanted to make sure you knew about the commitfest cycle we use
for the development of PostgreSQL. If you've not got one already, can
you regi
On Fri, Aug 30, 2024 at 12:15 PM Zhijie Hou (Fujitsu)
wrote:
>
>
> Here is V5 patch which addressed above and Shveta's[1] comments.
>
The patch looks good to me.
thanks
Shveta
On Thu, Aug 29, 2024 at 7:31 PM Melih Mutlu wrote:
>
> Hi Michael,
>
> Michael Harris , 23 Ağu 2024 Cum, 13:01 tarihinde şunu
> yazdı:
>>
>> V2 of the patch is attached.
>
>
> Thanks for updating the patch. I have a few more minor feedbacks.
>
>> -ANALYZE [ ( option [, ...] ) ]
>> [ table_and_co
On Tue, Aug 27, 2024 at 11:14 AM jian he wrote:
> also it's ok to use passed (ParseState *pstate) for
> {
> estate = CreateExecutorState();
> estate->es_param_list_info = params;
> paramLI = EvaluateParams(pstate, entry, execstmt->params, estate);
> }
> ?
> I really don't k
On Thu, Aug 22, 2024 at 12:44 PM Amit Langote wrote:
> On Thu, Aug 22, 2024 at 11:02 jian he wrote:
>> On Tue, Jul 30, 2024 at 12:59 PM Amit Langote
>> wrote:
>> > On Fri, Jul 26, 2024 at 11:19 PM jian he
>> > wrote:
>> > > {
>> > > ...
>> > > /*
>> > > * For expression nodes that su
On 28.08.24 05:31, Thomas Munro wrote:
On Wed, Jun 19, 2024 at 3:02 AM Andres Freund wrote:
-const char *EAN13_range[][2] = {
+static const char *EAN13_range[][2] = {
{"000", "019"}, /* GS1 US */
{"020", "029"}, /* Restricted distrib
Hi,
While looking at formatting.c file, I noticed a TODO about "add support for
roman number to standard number conversion" (
https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/formatting.c#L52
)
I have attached the patch that adds support for this and converts roman
numerals
52 matches
Mail list logo
