On Fri, Nov 22, 2024 at 2:37 PM Masahiko Sawada wrote:
>
> On Thu, Nov 21, 2024 at 1:22 PM Andrey M. Borodin
> wrote:
> >
> >
> >
> > > On 21 Nov 2024, at 02:24, Masahiko Sawada wrote:
> > >
> > > But does replacing the least significant 2 bits
> > > with random 2 bits really not affect monoto
On Tue, Nov 12, 2024 at 8:55 PM Kirill Reshke wrote:
>
> Patch obviously leaks doc & regression tests, but I'm posting it to
> see if this contribution is needed in PostgreSQL
the following two statement should fail:
CREATE SCHEMA regress_schema_2 AUTHORIZATION CURRENT_ROLE
CREATE table t(a ss)
On 22/11/2024 06:27, Giacchino, Luca wrote:
We’d appreciate feedback on this approach. In the meantime, we will
complete the patch to share. We also plan to extend SIMD-based sort to
tuple sort in the future.
Nice! I continually see performance reports when sorting and group order
impact perfor
On Fri, Nov 22, 2024 at 6:27 AM Giacchino, Luca
wrote:
> We’d appreciate feedback on this approach. In the meantime, we will complete
> the patch to share. We also plan to extend SIMD-based sort to tuple sort in
> the future.
Coincidentally, I'll be prototyping a tuple sort that will take bette
On Fri, Nov 22, 2024 at 06:13:16PM -0500, Andres Freund wrote:
>> -if (procStatus && procStatus->st_backendType ==
>> B_AUTOVAC_WORKER)
>> +if (pgstat_get_backend_type(pid) == B_AUTOVAC_WORKER)
>
> Because we already mapped the pid to a ProcNumber, it'd be cheaper to acces
On Fri, Nov 22, 2024 at 10:55 PM Jakub Wartak
wrote:
> but with attached _lseeki64 dirty patch I've got success and resulting
> tarball greater than 2^31 too:
>
> C:\compiledpg\bin>pg_basebackup.exe -U postgres -D "c:\backup7" -F t -P -X
> stream -c fast --compress=none --create-slot --slot=slot
Hi,
On 2024-11-22 13:21:53 -0600, Nathan Bossart wrote:
> Here is a draft-grade patch for this one. It seems pretty
> straightforward...
Thanks for looking into it quickly.
> diff --git a/src/backend/storage/ipc/signalfuncs.c
> b/src/backend/storage/ipc/signalfuncs.c
> index aa729a36e3..8e165
On Thu, Nov 21, 2024 at 1:22 PM Andrey M. Borodin wrote:
>
>
>
> > On 21 Nov 2024, at 02:24, Masahiko Sawada wrote:
> >
> > But does replacing the least significant 2 bits
> > with random 2 bits really not affect monotonicity?
>
> You are right. We have to take into account this when calculating
On 19/11/2024 23:02, Robert Haas wrote:
On Mon, Nov 18, 2024 at 11:09 PM Thomas Munro wrote:
Names don't match here. I prefer _CONTINUE. As for the general one,
I'm on the fence about INTERRUPT_GENERAL_WAKEUP, since wakeups aren't
necessarily involved, but I don't have a specific better idea
On 19/11/2024 06:09, Thomas Munro wrote:
It looks like maybeSleepingOnInterrupts replaces maybe_sleeping, and
SendInterrupt() would need to read it to suppress needless kill()
calls, but doesn't yet, or am I missing something?
Ah yes, you're right.
Hmm, I think there are two kinds of kill() s
On Thu, Nov 21, 2024 at 8:38 PM Peter Eisentraut wrote:
> On 20.11.24 10:00, Thomas Munro wrote:
> > OK, do you think these three patches tell the _configthreadlocale()
> > story properly? (Then after that we can get back to getting rid of
> > it...)
>
> Yes, this is very clear and helpful. Than
On 22/11/2024 19:49, Matthias van de Meent wrote:
Hi,
While working on the fix for [0] I noticed that bulk_write doens't use
any of the new vectorized IO features, which seemed like a waste.
After looking into it a bit deeper, I noticed the opportunity for
write vectorization was not very high,
On Fri, Nov 22, 2024 at 06:01:22PM +0200, Heikki Linnakangas wrote:
> On 22/11/2024 01:27, Giacchino, Luca wrote:
>> We´d appreciate feedback on this approach. In the meantime, we will
>> complete the patch to share. We also plan to extend SIMD-based sort to
>> tuple sort in the future.
>
> If you
I took another look at v32-0001 and v32-0002, and they look reasonable to
me. Unless additional feedback materializes, I'll plan on committing those
soon.
After that, it might be a good idea to take up the vacuumdb changes next,
since there's been quite a bit of recent discussion about those. I
On Tue, Nov 12, 2024 at 4:16 PM Ashutosh Bapat
wrote:
> On Mon, Nov 11, 2024 at 9:12 PM dinesh salve
> wrote:
> >
> >
> > Hi Hackers,
> >
> > I am working on a feature in postgres_fdw extension to show plans used
> by remote postgresql servers in the output of the EXPLAIN command.
> > I think th
On Wed, Nov 20, 2024 at 6:55 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 20 Nov 2024 14:14:27 -0800,
> Masahiko Sawada wrote:
>
> > I've extracted the changes to refactor COPY TO/FROM to use the format
> > callb
> I think we should still use the test program even when __SSE4_2__ is defined,
> but
> we can use that macro to determine whether to use a runtime check. I think
> that
> would keep autoconf and meson consistent.
Sure. Updated patch.
v5-0001-Use-__attribute__-target-sse4.2-for-SSE42-CRC32C.p
On Thu, Nov 21, 2024 at 2:41 AM Alvaro Herrera wrote:
>
> I ran `make headerscheck` after these patches and it reported a few
> problems:
>
> /pgsql/source/master/src/tools/pginclude/headerscheck /pgsql/source/master
> /pgsql/build/master
> In file included from /tmp/headerscheck.xdG40Y/test.c:2:
On Thu, Nov 21, 2024 at 11:07:59PM +, Devulapalli, Raghuveer wrote:
> Thanks for the review! We can actually leverage meson's built in option
> to check for a macro: cc.get_define('__SSE4_2__') != ''. This should keep
> the logic consistent across configure and meson.
I think we should still
On Fri, Nov 22, 2024 at 12:13:49PM -0500, Andres Freund wrote:
> I justed ended up looking at this code for some boring reason. One thing that
> has me worried a bit is that pg_signal_backend() now does
> pgstat_get_beentry_by_proc_number(), triggering a pgstat_read_current_status()
> further down.
On Fri, 2024-06-28 at 13:39 -0700, David G. Johnston wrote:
> The attached are complete and ready for review. I did some file
> structure reformatting at the end and left that as the second patch.
> The first contains all of the content.
I read through v4-0001. Thank you for working on this!
I
On Tue, Nov 19, 2024 at 05:00:43PM -0600, Nathan Bossart wrote:
> If there are no concerns, I plan on committing this soon.
Committed.
--
nathan
> On Mon, Nov 18, 2024 at 08:23:52AM GMT, Andy Fan wrote:
>
> >> > I imagined you'd the patch should create a SupportRequestSimplify
> >> > support function for jsonb_numeric() that checks if the input
> >> > expression is an OpExpr with funcid of jsonb_object_field(). All you
> >> > do then is di
On Fri, 22 Nov 2024 at 22:13, Andres Freund wrote:
>
> Hi,
>
> On 2024-07-09 13:12:59 -0500, Nathan Bossart wrote:
> > I've committed 0001.
>
> I justed ended up looking at this code for some boring reason. One thing that
> has me worried a bit is that pg_signal_backend() now does
> pgstat_get_bee
Hi,
While working on the fix for [0] I noticed that bulk_write doens't use
any of the new vectorized IO features, which seemed like a waste.
After looking into it a bit deeper, I noticed the opportunity for
write vectorization was not very high, as one would expect most
bulk_write IOs to be smgrex
Hi,
On 2024-11-21 14:24:26 +1300, Thomas Munro wrote:
> Oh, and yeah, we should include the branch name in the cache key.
> Something like the attached.
I think that'd be too granular - we'd end up with lots of copies of
effectively the same cache, but which won't exactly the same due to timestam
Hi,
On 2024-07-09 13:12:59 -0500, Nathan Bossart wrote:
> I've committed 0001.
I justed ended up looking at this code for some boring reason. One thing that
has me worried a bit is that pg_signal_backend() now does
pgstat_get_beentry_by_proc_number(), triggering a pgstat_read_current_status()
fur
On Thu, Nov 21, 2024 at 4:39 PM Joe Conway wrote:
> I mean, perhaps I am misreading and/or interpreting all of that
> differently to you, but from my reading of the entire thread there was
> clearly no consensus to using openssl to provide those two functions.
OK, I see the problem now. I don't i
Matthias van de Meent writes:
> On Thu, 21 Nov 2024 at 13:03, Toto guyoyg wrote:
>> It looks like this could be improved/fixed by either/all of:
>>
>> 1. Using a hashset (or sort + binary search) for recheck (past a certain
>> array length or even always) instead of always searching linearly
>
On Fri, Nov 22, 2024 at 8:06 AM Heikki Linnakangas wrote:
> Ok, committed the "placeholder" fields to master, and just comment fixes
> to REL_17_STABLE.
Thanks!
--Jacob
On 11/11/2024 21:43, Daniel Gustafsson wrote:
On 11 Nov 2024, at 20:17, Jacob Champion
wrote:
On Mon, Nov 11, 2024 at 11:13 AM Heikki Linnakangas wrote:
On REL_17_STABLE, we should probably adjust the comment to warn that
'raw_buf' and friends can move depending on USE_OPENSSL.
Yeah, make
On 22/11/2024 01:27, Giacchino, Luca wrote:
The existing list_sort takes a comparator function to compare pairs of
ListCell. On the other hand, x86-simd-sort requires an array of numeric
values to sort, and it returns an array of sorted indices. To enable
x86-simd-sort, we add new list_sort_sim
Some minor changes: I forgot to add the new pipeline meta-commands to
psql's help output, this is now added in 0002. I've also reworded the
doc a bit.
v04-0001-Reset-query-buffer-on-a-backslash-error.patch
Description: Binary data
v04-0002-Add-pipeline-support-in-psql.patch
Description: Binary
On Fri, Nov 22, 2024 at 3:53 PM Heikki Linnakangas wrote:
> On 22/11/2024 15:56, Erik Nordström wrote:
> > Yes, it solves the issue so it looks good.
> >
> > Just a minor nit: the code uses both blokno as local variable for
> > pending_writes[i].blkno and directly accessing pending_writes[i].blkn
On 22/11/2024 15:56, Erik Nordström wrote:
Yes, it solves the issue so it looks good.
Just a minor nit: the code uses both blokno as local variable for
pending_writes[i].blkno and directly accessing pending_writes[i].blkno.
Maybe it is better to just use the local variable. For example, change
FYI I've marked the CF entry as withdrawn.
I still think this (triggering prefetching in another exector node) has
a lot of potential, and not only in the context of a nested loop. But
the patch was just a quick & dirty experiment, I don't have time to work
on this right now. No point in keeping t
> On 21 Nov 2024, at 22:39, Joe Conway wrote:
> I mean, perhaps I am misreading and/or interpreting all of that differently
> to you, but from my reading of the entire thread there was clearly no
> consensus to using openssl to provide those two functions.
My interpretation (or perhaps, my opi
On Fri, Nov 22, 2024 at 2:26 PM Heikki Linnakangas wrote:
> On 22/11/2024 15:02, Matthias van de Meent wrote:
> > I think I'd go with a patch like attached, where the bulk writer
> > registers that it started with .relsize pages in the relfork, and use
> > that for smgrextend() decisions. It now
On 22.11.2024 05:52, Michael Paquier wrote:
On Thu, Nov 21, 2024 at 10:50:41PM +0300, Pavel Luzanov wrote:
I found that the help for \pset command missed xheader_width option.
Good catch. This is a mistake from a45388d6e098. The patch should
have used HELP0() as this is a single variable, and
On 22/11/2024 15:02, Matthias van de Meent wrote:
I think I'd go with a patch like attached, where the bulk writer
registers that it started with .relsize pages in the relfork, and use
that for smgrextend() decisions. It now also records pages_written as
a separate but accurate value.
Looks goo
On Thu, Sep 12, 2024 at 9:44 AM David Rowley wrote:
>
> On Sat, 30 Dec 2023 at 04:05, Zhang Mingli wrote:
> > So my patch make it easy: check unique index’s columns, it’s a valid
> > candidate if all of that have NOT NULL constraint.
> > And we choose a best one who has the least column numbers
Hi,
How does the process know that the client backend has finished reading
> stats and it can be refreshed? What happens, if the next request for
> memory context stats comes before first requester has consumed the
> statistics it requested?
>
> A process that's copying its statistics does not nee
On Fri, 22 Nov 2024 at 09:11, Erik Nordström wrote:
>
>
>
> On Fri, Nov 22, 2024 at 12:30 AM Matthias van de Meent
> wrote:
>>
>> On Thu, 21 Nov 2024, 17:18 Erik Nordström, wrote:
>>>
>>> Hello,
>>>
>>> I've noticed a change in behavior of the heap rewrite functionality in
>>> PostgreSQL 17, u
On Thu, 21 Nov 2024 at 17:35, Nisha Moond wrote:
>
> On Wed, Nov 20, 2024 at 1:29 PM vignesh C wrote:
> >
> > On Tue, 19 Nov 2024 at 12:43, Nisha Moond wrote:
> > >
> > > Attached is the v49 patch set:
> > > - Fixed the bug reported in [1].
> > > - Addressed comments in [2] and [3].
> > >
> > >
Hi Thomas!
On Thu, Nov 21, 2024 at 2:38 PM Thomas Munro wrote:
> On Thu, Nov 21, 2024 at 11:44 PM Jakub Wartak
> wrote:
> > This literally looks like something like off_t/size_t would be limited
> to 2^31 somewhere.
>
> off_t is 32 bits on Windows. I'd be quite suspicious of the
> arithmetic i
On 2024-11-21 17:47, Masahiro Ikeda wrote:
On 2024-11-21 04:40, Peter Geoghegan wrote:
diff --git a/src/backend/access/nbtree/nbtutils.c
b/src/backend/access/nbtree/nbtutils.c
index b70b58e0c..ddae5f2a1 100644
--- a/src/backend/access/nbtree/nbtutils.c
+++ b/src/backend/access/nbtree/nbtutils.c
@
On Fri, 22 Nov 2024 at 01:37, Tom Lane wrote:
> How would we do that? libpqsrv_cancel is not chartered to wait around
> for the results of the cancel, and I'm not even sure that it could
> know what to check for.
Ah yeah, you're right. I got confused by the two timeouts (the one to
wait for the
On 11/13/24 13:49, Richard Guo wrote:
On Mon, Oct 28, 2024 at 6:15 PM Andrei Lepikhov wrote:
On 6/7/24 16:46, Richard Guo wrote:
I'm not sure about merging these two 'reordering' GUCs into one.
While they may look similar, they apply to very different scenarios.
However, I'm open to other sugg
On Fri, Nov 22, 2024 at 12:30 AM Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
> On Thu, 21 Nov 2024, 17:18 Erik Nordström, wrote:
>
>> Hello,
>>
>> I've noticed a change in behavior of the heap rewrite functionality in
>> PostgreSQL 17, used by, e.g., CLUSTER. I've been experiment
49 matches
Mail list logo
