On Wed, Mar 12, 2025 at 12:46 AM Devulapalli, Raghuveer
wrote:
>
> I am happy to submit a patch with a C fallback version that leverages the
> specific algorithm/technique mentioned in the white paper to make it clear
> that Intel has contributed this specific technique to Postgres under Postgre
On Wed, Mar 12, 2025 at 10:42 AM David G. Johnston
wrote:
>
> On Tuesday, March 11, 2025, Amit Kapila wrote:
>>
>> On Wed, Mar 12, 2025 at 9:43 AM David G. Johnston
>> wrote:
>> >
>> > I’m honestly question how much value this provides - no improvement here
>> > seems like a viable choice. Let
Hi Nathan,
On Mon, Mar 10, 2025 at 8:31 PM Nathan Bossart wrote:
>
> On Mon, Mar 10, 2025 at 11:15:04AM +0530, Ashutosh Sharma wrote:
> > On Fri, Mar 7, 2025 at 10:55 PM Nathan Bossart
> > wrote:
> >> I noticed that much of this code is lifted from DropRole(), and the new
> >> check_drop_role_d
On Wed, Mar 12, 2025 at 3:17 AM Masahiko Sawada wrote:
>
> On Tue, Mar 11, 2025 at 5:51 AM Amit Kapila wrote:
> >
Some thoughts/questions on the idea
I notice that we are always considering block-level parallelism for
heaps and object-level parallelism for indexes. I'm wondering, when
multiple
On Wed, Mar 12, 2025 at 11:24 AM Dilip Kumar wrote:
>
> On Wed, Mar 12, 2025 at 3:17 AM Masahiko Sawada wrote:
> >
Some more specific comments on the patch set
-- v11-0001
1. This introduces functions like parallel_vacuum_estimate(),
parallel_vacuum_initialize(), etc., but these functions have
> On 11 Mar 2025, at 14:12, Evgeny wrote:
>
Hi!
Some nits:
Patch adds whitespace errors
.git/rebase-apply/patch:64: trailing whitespace.
* Nullify the page (pageno = 0), don't insert an XLog record,
.git/rebase-apply/patch:212: trailing whitespace.
/* .git/rebase-apply/patch:213: traili
On Tuesday, March 11, 2025, vignesh C wrote:
>
>
> Apart from the database, I believe the target file also needs to be
> specified. Should we include this option also along with dbname:
> +
> +
> + -d
> + --dbname
> +
> +dbname
> +
>
> pg_recvlogical -U postgres --start -
Dear David,
> And they will see empty strings (or blanks or whatever the defaults are) for
> everything except LSN, like they always do, and not realize or care that our
> code
> generated file actually contained lines for them. (I haven't actually
> experimented
> here though.)
It is OK for me
On Monday, February 24, 2025, Hayato Kuroda (Fujitsu) <
kuroda.hay...@fujitsu.com> wrote:
>
>
> OK, so I will exclude the point in the thread. The patch I've posted
> contains all of fixes
> which is required.
>
The patch fixes the synopsis and the mention of the default value. Only
the later is
Hi,
On Tue, Mar 11, 2025 at 11:14:24PM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > And I guess that we're OK here, so applied. That should be the last
> > one.
>
> Quite a few buildfarm members are not happy about the initialization
> that 9a8dd2c5a added to PendingBackendStats. For i
On Fri, 21 Feb 2025 at 14:25, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Ashutosh,
>
> Thanks for the reply.
>
> > > ISTM the inconsistency is introduced since the initial commit. I think
> > > they should
> > be unified either
> > > 1) update the doc or 2) accept when -d is not specified. Personall
Hi Nathan,
Thanks for the review comment.
On Mon, Mar 10, 2025 at 8:31 PM Nathan Bossart wrote:
>
> On Mon, Mar 10, 2025 at 11:15:04AM +0530, Ashutosh Sharma wrote:
> > On Fri, Mar 7, 2025 at 10:55 PM Nathan Bossart
> > wrote:
> >> I noticed that much of this code is lifted from DropRole(), an
On Tuesday, March 11, 2025, Amit Kapila wrote:
> On Wed, Mar 12, 2025 at 9:43 AM David G. Johnston
> wrote:
> >
> > I’m honestly question how much value this provides - no improvement here
> seems like a viable choice. Let them issue the drop commands they desire
> manually. This doesn’t feel
On Tue, Mar 11, 2025 at 2:28 PM Nisha Moond wrote:
>
> On Tue, Mar 11, 2025 at 11:10 AM Dilip Kumar wrote:
> The goal of introducing a new conflict type is to handle multiple-key
> conflicts separately. It will not only allow users to apply different
> resolution methods for single-key vs multi-
On Wed, Mar 12, 2025 at 9:43 AM David G. Johnston
wrote:
>
> I’m honestly question how much value this provides - no improvement here
> seems like a viable choice. Let them issue the drop commands they desire
> manually. This doesn’t feel like something one should/would automate.
>
There is a
Thanks
On Tue, Mar 11, 2025 at 7:51 PM Junwang Zhao wrote:
>
> Here is a new version with Amit's fix and my trivial refactors.
>
> 0001-0010 is the same as Ashutosh's last email
> 0011 is Amit's fix of the crash in ExecCheckPermissions
I think that fix is correct and it fixes the crash. I need
On Tuesday, March 11, 2025, Amit Kapila wrote:
> On Tue, Mar 11, 2025 at 6:02 AM David G. Johnston
> wrote:
> >
> > Can you briefly recap how this is different than the automatic behavior
> described in the existing Step 6?
> > "Drop publications on the target server that were replicated because
On Tuesday, March 11, 2025, Amit Kapila wrote:
> On Tue, Mar 11, 2025 at 8:21 PM David G. Johnston
> wrote:
> >
> > On Tue, Mar 11, 2025 at 12:20 AM Peter Smith
> wrote:
> >>
> >>
> >> Unfortunately, we are spinning in circles a bit trying to come up with
> >> a good way to represent the option
On Tue, Mar 11, 2025 at 6:02 AM David G. Johnston
wrote:
>
> Can you briefly recap how this is different than the automatic behavior
> described in the existing Step 6?
> "Drop publications on the target server that were replicated because they
> were created before the replication start locatio
On Tue, Mar 11, 2025 at 8:21 PM David G. Johnston
wrote:
>
> On Tue, Mar 11, 2025 at 12:20 AM Peter Smith wrote:
>>
>>
>> Unfortunately, we are spinning in circles a bit trying to come up with
>> a good way to represent the option needed for this, while at the same
>> time trying to be future-pro
On Wed, Mar 12, 2025 at 10:00 AM Tender Wang wrote:
> Maciek Sakrejda 于2025年3月11日周二 08:12写道：
>> While exploring the jsonb code, I noticed that in
>> datum_to_jsonb_internal, the tcategory checks compares against
>> JSONTYPE_JSON twice. There's no reason for that, right?
>
> Yeah, the second JSONT
On Tue, 11 Mar 2025 at 23:28, Michael Paquier wrote:
> > Can you share your thoughts on Ivan's NULL jumble idea?
>
> This is an incomplete solution, I am afraid. The origin of the
> problem comes from the fact that a Node (here, Query) stores two times
> successively equivalent Nodes that are use
Hi Jeff, Corey,
After fixing the statistics difference in dumps of tables with
indexes, I now see difference in statistics of materialized view dump
in the test I am developing at [1] (see the latest patches there).
I see following difference in the dump from the original regression
database and t
On Thu, Mar 06, 2025 at 01:47:34PM -0500, Tom Lane wrote:
> 1. pg_upgrade has made a policy judgement to apply parallelism across
> databases not within a database, ie it will launch concurrent dump/
> restore tasks in different DBs but not authorize any one of them to
> eat multiple CPUs. That ne
On Wed, Mar 12, 2025 at 09:46:27AM +0900, Michael Paquier wrote:
> On Tue, Mar 11, 2025 at 01:57:49PM -0700, Noah Misch wrote:
> > Thanks for crafting back-branch versions. I've queued a task to confirm I
> > get
> > the same result.
>
> Thanks for that. That helps a lot.
I'll let you know whe
Maciek Sakrejda 于2025年3月11日周二 08:12写道：
> While exploring the jsonb code, I noticed that in
> datum_to_jsonb_internal, the tcategory checks compares against
> JSONTYPE_JSON twice. There's no reason for that, right?
>
Yeah, the second JSONTYPE_JSON seems redundant.
>
> ...
>
> Ok, so, to try to
Hello, everyone and Peter!
Peter, I have added you because you may be interested in (or already know
about) this btree-related issue.
Short description of the problem:
I noticed a concurrency issue in btree index scans that affects
SnapshotDirty and SnapshotSelf scan types.
When using these non-
Hi Nisha,
Thanks for addressing some of my v1 comments. I confirmed they are all
ok. But, I haven't reviewed the v2 again because I still had doubts
about the "stats" question and am waiting to see how that pans out.
Meanwhile, I had a couple more replies below.
On Tue, Feb 25, 2025 at 8:37 PM N
On Tue, Mar 11, 2025 at 05:35:10PM -0500, Sami Imseih wrote:
> I have not benchmarked the overhead, so maybe there is not much to
> be concerned about. However, it just seems to me that tracking the extra
> data for all cases just to only deal with corner cases does not seem like the
> correct appr
On Tue, Mar 11, 2025 at 01:57:49PM -0700, Noah Misch wrote:
> Thanks for crafting back-branch versions. I've queued a task to confirm I get
> the same result.
Thanks for that. That helps a lot.
> There's a test case I'll polish, too.
Are you considering the addition of a TAP test in 17~ based
I'm adding the author/committer and reviewer of 3c152a2, since I think
this may be a bug (my apologies if I'm misunderstanding this). See my
previous e-mail quoted below:
On Mon, Mar 10, 2025 at 5:11 PM Maciek Sakrejda wrote:
>
> While exploring the jsonb code, I noticed that in
> datum_to_jsonb_
Hi,
On 2025-03-10 19:45:38 -0400, Melanie Plageman wrote:
> From 7b35b1144bddf202fb4d56a9b783751a0945ba0e Mon Sep 17 00:00:00 2001
> From: Melanie Plageman
> Date: Mon, 10 Mar 2025 17:17:38 -0400
> Subject: [PATCH v35 1/5] Increase default effective_io_concurrency to 16
>
> The default effective
Hi,
On 2025-03-11 12:41:08 -0700, Noah Misch wrote:
> On Mon, Sep 16, 2024 at 01:51:42PM -0400, Andres Freund wrote:
> > On 2024-09-16 07:43:49 -0700, Noah Misch wrote:
> > > For non-sync IO methods, I gather it's essential that a process other
> > > than the
> > > IO definer be scanning for inco
On Thu, Mar 06, 2025 at 02:57:01PM +0100, Andreas Karlsson wrote:
> On 11/22/23 2:29 AM, Noah Misch wrote:
> > Something as simple as the following doesn't respond to cancellation. In
> > v15+, any DROP DATABASE will hang as long as it's running:
> One of our customers ran into this bug when upgr
On Tue, Feb 11, 2025 at 9:36 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Sawada-san,
>
> Thanks for updating the patch!
>
> > I've attached the updated patch. I address all comments I got so far
> > and added a small regression test.
> >
> > It makes sense to me that we move GetDbnameFromConnection
On Tue, 11 Mar 2025 at 18:37, Andrew Dunstan wrote:
Well, JSON is supposed to be UTF8. What should we do about database
> names that are not UTF8?
>
How can you have a database name that isn't encodeable in UTF-8? At this
point I'm pretty sure Unicode has subsumed essentially every character eve
On Wed, 2025-03-05 at 23:04 -0500, Corey Huinker wrote:
>
> Anyway, here's a rebased set of the existing up-for-consideration
> patches, plus the optimization of avoiding querying on non-expression
> indexes.
Comments on 0003:
* All the argument names for pg_restore_attribute_stats match pg_stat
On Tue, Mar 11, 2025 at 6:24 PM Alena Rybakina
wrote:
> Hi, reviewing the code I noticed that you removed the
> parallel_aware check for DSM initialization for BitmapIndexScan,
> IndexScan, IndexOnlyScan,
> but you didn't do the same in the ExecParallelReInitializeDSM function
> and I can't figure
On 2025-03-11 Tu 5:03 PM, Álvaro Herrera wrote:
On 2025-Mar-11, Andrew Dunstan wrote:
I'm not sure everyone thinks that was a good idea for backup manifests (in
fact I know some don't), and it seems somewhat like overkill for a simple
map of oids to database names.
If such a simple system ca
On Mon, Mar 10, 2025 at 3:08 AM Steven Niu wrote:
>
>
>
> Hi, Masahiko
>
> Thanks for your comments! I understand your concern as you stated.
> However, my initial patch was split into two parts as Kirill suggested.
> This thread is about the first part. Another part is here:
> https://commitfes
On Tue, 2025-03-11 at 11:26 -0400, Tom Lane wrote:
> Right, that was what I was thinking, but hadn't had time to look in
> detail. The postDataBound dependency isn't real helpful here, we
> could lose that if we had the data dependency.
Attached a patch.
It's a bit messier than I expected, so I'
> and simple. However, Sami seems to have concerns about the overhead of
> doing this. Is that warranted at all? Potentially, there could be a
> decent number of NULL fields. It'll probably be much cheaper than the
> offsetof idea I came up with.
I have not benchmarked the overhead, so maybe there
On Fri, Mar 7, 2025 at 11:58 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Fri, Mar 07, 2025 at 12:09:35PM -0800, Masahiko Sawada wrote:
> > Thank you for updating the patch. It looks mostly good to me. I've
> > made some cosmetic changes and attached the updated version.
>
> LGTM, thanks!
Pushed.
R
On Mon, Mar 10, 2025 at 5:03 PM Daniel Gustafsson wrote:
>
> > On 7 Mar 2025, at 23:08, Melanie Plageman wrote:
>
> Sorry for being late to the party. I like this functionality and would
> definitely like to see it in v18.
Thanks so much for the review!
> + /* For backwards compatibility, we
On 11.03.2025 18:52, Peter Geoghegan wrote:
On Sat, Mar 8, 2025 at 11:43 AM Peter Geoghegan wrote:
I plan on committing this one soon. It's obviously pretty pointless to
make the BTMaxItemSize operate off of a page header, and not requiring
it is more flexible.
Committed. And committed a revis
On 02.03.25 22:08, Thomas Munro wrote:
On Mon, Mar 3, 2025 at 6:21 AM Peter Eisentraut wrote:
On 05.12.24 23:18, Thomas Munro wrote:
Old: errmsg("hello %llu", (unsigned long long) x)
New: errmsg("hello %" PRIu64, x)
I have committed the subset of this patch for pg_checksums.c so
On Tue, Mar 11, 2025 at 5:51 AM Amit Kapila wrote:
>
> On Tue, Mar 11, 2025 at 5:00 AM Masahiko Sawada wrote:
> >
> > On Sun, Mar 9, 2025 at 11:28 PM Amit Kapila wrote:
> > >
> > >
> > > Does phase 3 also use parallelism? If so, can we try to divide the
> > > ring buffers among workers or at lea
On Tue, Mar 11, 2025 at 6:00 AM Amit Kapila wrote:
>
> On Mon, Mar 10, 2025 at 11:57 PM Masahiko Sawada
> wrote:
> >
> > On Sun, Mar 9, 2025 at 11:12 PM Amit Kapila wrote:
> > >
> > >
> > > > However, in the heap vacuum phase, the leader process needed
> > > > to process all blocks, resulting i
On Mon, Mar 10, 2025 at 1:12 PM Álvaro Herrera wrote:
> On 2025-Mar-09, Alexander Korotkov wrote:
>
> > After second thought it's not so hard to fix. The attached patch does
> > it by putting REINDEX commands related to the same table into a single
> > SQL statement. Possibly, that could be bett
On Mon, Mar 10, 2025 at 5:03 PM Melanie Plageman
wrote:
>
> On Sat, Mar 8, 2025 at 1:42 AM Masahiko Sawada wrote:
> >
> >
> > I've attached the updated version patches.
>
> I've started trying to review this and realized that, while I'm
> familiar with heap vacuuming code, I'm not familiar enough
On Mon, Mar 10, 2025 at 2:53 AM David Rowley wrote:
>
> On Mon, 10 Mar 2025 at 17:22, Masahiko Sawada wrote:
> > Regarding that patch, we need to note that the lpdead_items is a
> > counter that is not reset in the entire vacuum. Therefore, with
> > maintenance_work_mem = 64kB, once we collect at
On Mon, Mar 10, 2025 at 03:48:31PM +0700, John Naylor wrote:
> On Tue, Mar 4, 2025 at 2:11 AM Nathan Bossart
> wrote:
>> Overall, I wish we could avoid splitting things into separate files and
>> adding more header file gymnastics, but maybe there isn't much better we
>> can do without overhaulin
On Fri, Mar 07, 2025 at 03:20:07AM +, chiranmoy.bhattacha...@fujitsu.com
wrote:
> Sounds good. Let us know your findings.
Alright, here's what I saw on an R8g for drive_popcount(100, N):
8-byte words master v5-no-svev5-sve v5-4reg
1 2.540 ms 2.170
> transformation. For these reasons, variant A where we put the
> LimitOption between the two int8 expression nodes feels like the
> "okay" approach here. But we must document this expectation in the
> structure, and check for more grammar variants of LIMIT and OFFSET
> clauses in pgss.
Please s
On 2025-Mar-11, Andrew Dunstan wrote:
> I'm not sure everyone thinks that was a good idea for backup manifests (in
> fact I know some don't), and it seems somewhat like overkill for a simple
> map of oids to database names.
If such a simple system can be made to work for all possible valid
databa
> I've gone ahead and added the generated AVX-512 algorithm in v14-0005
+ pg_attribute_target("avx512vl,vpclmulqdq")
+ pg_crc32c
+ pg_comp_crc32c_pclmul(pg_crc32c crc, const void *data, size_t length)
I'm a little confused. Why is v14 missing the earlier versions of pclmul
implementation that wo
On Mon, Mar 10, 2025 at 02:25:28PM +0900, Michael Paquier wrote:
> On Thu, Mar 06, 2025 at 01:44:30PM -0600, Nathan Bossart wrote:
> > On Thu, Mar 06, 2025 at 11:30:13AM -0800, Noah Misch wrote:
> >> 1. Make v14 and v13 skip WAL recycling and preallocation during archive
> >>recovery, like newe
On Tue, Mar 4, 2025 at 8:00 PM Andres Freund wrote:
> Attached is v2.5 of the AIO patchset.
[..]
Hi, Thanks for working on this!
> Questions:
>
> - My current thinking is that we'd set io_method = worker initially - so we
> actually get some coverage - and then decide whether to switch to
>
"David G. Johnston" writes:
> On Tue, Mar 11, 2025 at 1:19 PM Marcos Pegoraro wrote:
>> I understand that this page we have more NULL values than everywhere else
>> combined, but it's a good opportunity to set a standard for all
>> documentation
> If someone writes a patch to make everywhere an
On 2025-Mar-04, Tom Lane wrote:
> Hmm. I agree that "ALTER CONSTRAINT statement" is off the
> mark here, but I'm not convinced that "FOREIGN KEY" is entirely
> on-point either. The grammar has no way of knowing what kind of
> constraint is being targeted. I do see that ATExecAlterConstraint
> c
On Tue, Mar 11, 2025 at 1:19 PM Marcos Pegoraro wrote:
> Em ter., 11 de mar. de 2025 às 16:47, David G. Johnston <
> david.g.johns...@gmail.com> escreveu:
>
>> Since COPY uses \N I figured it was a decent choice. or
>>> came to mind too, but there were long compared to 1, 2, and 4 that appear
>
Em ter., 11 de mar. de 2025 às 16:47, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> Since COPY uses \N I figured it was a decent choice. or came
>> to mind too, but there were long compared to 1, 2, and 4 that appear along
>> side it.
>>
> Well, I would use , it doesn't need any ex
On 2025-03-11 Tu 1:52 PM, Dagfinn Ilmari Mannsåker wrote:
Álvaro Herrera writes:
Hello,
On 2025-Mar-11, Mahendra Singh Thalor wrote:
In map.dat file, I tried to fix this issue by adding number of characters
in dbname but as per code comments, as of now, we are not supporting \n\r
in dbnam
On Mon, Mar 10, 2025 at 10:15 AM Dilip Kumar wrote:
>
> On Mon, Mar 10, 2025 at 9:33 AM Amit Kapila wrote:
>>
>> On Tue, Mar 4, 2025 at 6:54 PM vignesh C wrote:
>> >
>> > On further thinking, I felt the use of publications_updated variable
>> > is not required we can use publications_valid itsel
On Tue, Mar 11, 2025 at 12:44 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Mar 11, 2025 at 12:39 PM Marcos Pegoraro
> wrote:
>
>> Em ter., 11 de mar. de 2025 às 12:52, David G. Johnston <
>> david.g.johns...@gmail.com> escreveu:
>>
>>> The markup surrounding the examples is
On Tue, Mar 11, 2025 at 12:39 PM Marcos Pegoraro wrote:
> Em ter., 11 de mar. de 2025 às 12:52, David G. Johnston <
> david.g.johns...@gmail.com> escreveu:
>
>> The markup surrounding the examples is correct now and I decided \N was
>> the most useful representation of NULL given that the query d
On Mon, Sep 16, 2024 at 01:51:42PM -0400, Andres Freund wrote:
> On 2024-09-16 07:43:49 -0700, Noah Misch wrote:
> > For non-sync IO methods, I gather it's essential that a process other than
> > the
> > IO definer be scanning for incomplete IOs and completing them.
> > Otherwise, deadlocks like
Em ter., 11 de mar. de 2025 às 12:52, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> The markup surrounding the examples is correct now and I decided \N was
> the most useful representation of NULL given that the query data is single
> digit numbers. I really hate the non-readability
>
> I don't follow. We already have the tablenames, schemanames and oids of the
> to-be-dumped tables/indexes collected in pg_dump, all that's needed is to
> send
> a list of those to the server to filter there?
>
Do we have something that currently does that? All of the collect functions
(collect
Hi,
On 2025-03-12 07:35:46 +1300, Thomas Munro wrote:
> On Thu, Feb 27, 2025 at 11:20 PM Andres Freund wrote:
> > On 2025-02-27 11:19:55 +1300, Thomas Munro wrote:
> > > On Wed, Feb 26, 2025 at 10:55 PM Andres Freund wrote:
> > > > I was working on expanding tests for AIO and as part of that wro
Hi Jian
On 07.03.25 04:48, jian he wrote:
> hi.
> rebase only.
I revisited this patch today. It applies and builds cleanly, and it
works as expected.
Some tests and minor comments:
1) WARNING might be a better fit than NOTICE here.
postgres=# \pset null NULL
Null display is "NULL".
post
Hi,
On 2025-03-06 14:13:40 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Mar 6, 2025 at 1:07 PM Tom Lane wrote:
> >> Maybe invent a build-farm.conf option like "newest_branch_to_build"?
>
> > Yes, that would be nice. I also think we should mandate the use of
> > that option for OS ver
On Tue, Mar 11, 2025 at 05:23:14PM +0100, Frits Hoogland wrote:
> The usecase that I think might be useful is to have a database client send
> metadata along with a query.
> This partially is possible today by setting application_name, but that is a
> separate request, it would be great if that c
Dave Cramer
www.postgres.rocks
On Tue, 11 Mar 2025 at 12:23, Frits Hoogland
wrote:
> The usecase that I think might be useful is to have a database client send
> metadata along with a query.
> This partially is possible today by setting application_name, but that is
> a separate request, it wou
On Wed, Mar 5, 2025 at 9:37 AM Peter Geoghegan wrote:
> Committed just now. Thanks again.
I had to revert this for now, due to issues with debug_parallel_query.
Apologies for the inconvenience.
The immediate problem is that when the parallel leader doesn't
participate, there is no valid IndexSca
On Tue, Mar 11, 2025 at 1:56 PM Andres Freund wrote:
>
> Hi,
>
> On 2025-03-11 11:31:18 -0400, Melanie Plageman wrote:
> > Commit messages for 0017-0020 are thin. I assume you will beef them up
> > a bit before committing.
>
> Yea. I wanted to get some feedback on whether these refactorings are a
On Thu, Feb 27, 2025 at 11:20 PM Andres Freund wrote:
> On 2025-02-27 11:19:55 +1300, Thomas Munro wrote:
> > On Wed, Feb 26, 2025 at 10:55 PM Andres Freund wrote:
> > > I was working on expanding tests for AIO and as part of that wrote a test
> > > for
> > > temp tables -- our coverage is fairl
Hi,
Am Montag, dem 09.12.2024 um 18:10 +0100 schrieb Bernd Helmle:
> > I think we have two options:
> > 1. Just do not commit tests. We ran it manually, saw that paths are
> > taken, we are happy.
>
> So here's a version with the original, unchanged regression tests and
> injection point removed
> On Mar 5, 2025, at 5:56 PM, Matthias van de Meent
> wrote:
>
> Hi,
>
> Sorry for the delay. This is a reply for the mail thread up to 17 Feb,
> so it might be very out-of-date by now, in which case sorry for the
> noise.
Never noise, always helpful.
> On Mon, 17 Feb 2025 at 20:54, Burd, Gr
Hi,
On 2025-03-11 11:31:18 -0400, Melanie Plageman wrote:
> On Mon, Mar 10, 2025 at 2:23 PM Andres Freund wrote:
> >
> > - 0016 to 0020 - cleanups for temp buffers code - I just wrote these to
> > clean
> > up the code before making larger changes, needs review
>
> This is a review of 0016-00
Álvaro Herrera writes:
> Hello,
>
> On 2025-Mar-11, Mahendra Singh Thalor wrote:
>
>> In map.dat file, I tried to fix this issue by adding number of characters
>> in dbname but as per code comments, as of now, we are not supporting \n\r
>> in dbnames so i removed handling.
>> I will do some more
Hi John,
I am happy to submit a patch with a C fallback version that leverages the
specific algorithm/technique mentioned in the white paper to make it clear that
Intel has contributed this specific technique to Postgres under Postgres
license terms. That should hopefully address any lingerin
I have committed the first three refactoring patches (v16-0001,
v16-0002, v16-0003). (I guess Álvaro didn't like the first one, so I
suppose I'll revert that one, but it's a simple one, so you can proceed
either way.)
I think the next step here is that you work to fix Álvaro's concerns
about
Hi,
On 2025-02-16 17:52:36 -0800, Noah Misch wrote:
> On Sun, Feb 16, 2025 at 08:42:50PM -0500, Andres Freund wrote:
> > On February 16, 2025 7:50:18 PM EST, Tom Lane wrote:
> > >Noah Misch writes:
> > >> On Sun, Feb 16, 2025 at 06:18:44PM -0500, Tom Lane wrote:
> > >>> I think that
> > >>> IPC:
Here is bug description from
https://www.postgresql.org/message-id/flat/ca447b72d15745b9a877fad7e258407a%40localhost.localdomain
Problem
===
In some cases, we could have same IDs for not identical query trees.
For two structurally similar query subnodes, we may have query
trees that look like
Hi,
On Fri, Mar 07, 2025 at 03:29:14PM -0500, Melanie Plageman wrote:
> On Fri, Mar 7, 2025 at 6:16 AM Bertrand Drouvot
> wrote:
> > But at the end, what we're "really" interested in this thread, given its
> > $SUBJECT,
> > is to actually log the timings.
>
> I'm not sure that people would enab
Hi,
Thanks for taking a look at the patch, and for your feedback.
On Wed, 5 Mar 2025 at 03:22, Fujii Masao
wrote:
> On 2025/02/16 16:05, Robins Tharakan wrote:
> > This patch introduces a new function pg_accept_connections_start_time().
>
Shouldn't this function also handle the time when the p
On Thu, Mar 6, 2025 at 4:16 PM Tom Lane wrote:
> I find a good deal of attraction in getting rid of the IDs and
> just using names. Nor do I believe we need a hash table.
> (1) Surely there will not be so many extensions using this within a
> single EXPLAIN that a simple loop with strcmp()'s isn'
> On 8 Mar 2025, at 17:15, Andreas Karlsson wrote:
>
> On 2/5/25 11:00 AM, Daniel Gustafsson wrote:
>> This fell off the ever-growing TODO again. Re-reading it I still think it's
>> a
>> good idea, it applied almost cleanly still and still gives a slight
>> performance
>> improvement along wit
Hi,
On Mon, Mar 10, 2025 at 09:23:50AM +0900, Michael Paquier wrote:
> On Mon, Mar 03, 2025 at 11:54:39AM +, Bertrand Drouvot wrote:
> > So it does not look like what we're adding here can be seen as a primary
> > bottleneck
> > but that is probably worth implementing the "have_iostats" optim
On Mon, Mar 10, 2025 at 5:02 PM Nisha Moond wrote:
>
> On Mon, Mar 10, 2025 at 4:31 PM Shubham Khanna
> wrote:
> >
> > > 2) This part of code has another bug:
> > > "dbinfos.dbinfo->made_publication = false;" incorrectly modifies
> > > dbinfo[0], even if the failure occurs in other databases (db
On Mon, Mar 10, 2025 at 11:29 PM Álvaro Herrera wrote:
>
> Hello,
>
> I fleshed this out more fully and I think 0001 is good enough to commit.
>
The approach looks good to me, but instead of adding a CAS_flags struct, could
we use macros like SEEN_DEFERRABILITY(bits), SEEN_ENFORCEABILITY(bits),
e
On Thu, Dec 19, 2024 at 02:44:53PM +0900, Michael Paquier wrote:
> On Wed, Dec 18, 2024 at 08:51:20PM -0500, Andres Freund wrote:
> > I don't think the issue is actually quite as unlikely to be hit as reasoned
> > in
> > the commit message. The crash has indeed to happen between the link() and
>
On 10/03/2025 18:20, Ranier Vilela wrote:
Just for curiosity.
*RelationFindReplTupleSeq* on the same source, does not suffer
from the same issue?
PushActiveSnapshot(GetLatestSnapshot());
res = table_tuple_lock(rel, &(outslot->tts_tid), GetLatestSnapshot(),
:facepalm: yep, it sure does, and Fi
Masahiko Sawada 于2025年3月8日周六 12:04写道：
> Hi,
>
> On Sun, Oct 27, 2024 at 12:05 PM Kirill Reshke
> wrote:
> >
> > On Wed, 14 Aug 2024 at 11:35, Steven Niu wrote:
> > >
> > > Junwang, Kirill,
> > >
> > > The split work has been done. I created a new patch for removing
> redundant smgrclose() funct
> Oh well - you're probably right.
> I guess I was blinded by my convenience.
> Adding a 'base64url' option there is more appropriate.
I agree with it too. It is neater to add "base64url" as a new option for
encode() and decode() SQL functions in encode.c.
In addition, you may also want to add th
Robert Haas writes:
> If there is, maybe we should discard the integer IDs and just use
> strings directly. I could make GetExplainExtensionState() and
> SetExplainExtensionState() take const char *extension_name arguments
> instead of int extension_id, and just get rid of GetExplainExtensionId
>
Em seg., 10 de mar. de 2025 às 12:22, Heikki Linnakangas
escreveu:
> On 21/01/2025 12:05, Alexander Korotkov wrote:
> > On Tue, Jan 21, 2025 at 12:03 PM Alexander Korotkov
> > wrote:
> >> On Sun, Dec 29, 2024 at 3:59 PM Heikki Linnakangas
> wrote:
> >>> However, I think GetLatestSnapshot() is w
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> On 2025-Mar-09, Tom Lane wrote:
>> David Rowley writes:
>>> What are your thoughts on being a bit more brief with the naming and
>>> just prefix with "w" instead of "window"?
>> OK by me, any objections elsewhere?
> WFM.
Here's a hopefully-final v3 tha
hi.
in RememberAllDependentForRebuilding
while (HeapTupleIsValid(depTup = systable_getnext(scan)))
{
if(subtype == AT_SetExpression)
elog(INFO, "foundObject.classId:%d", foundObject.classId);
}
Then do the regress test on generated_stored.sql
I found out only constraints and in
1 - 100 of 189 matches
Mail list logo
