Andy Fan writes:
> Álvaro Herrera writes:
>
>> Hmm
>>
>> So these functions were created from macros in commit 34694ec888d6,
>> which themselves had been added for the first time in commit
>> 37484ad2aace. However, it appears that they were added only because
>> they were mirroring HeapTupleHea
On Fri, Jun 27, 2025 at 02:45:58PM +0500, Andrey Borodin wrote:
> I'm +1 on having full-fledged injection points in back branches
> where possible. Right now I'm debugging a PG-17(probably) problem
> where injection preloading would be handy (though functionality is
> available via hacks, just a li
> Thanks for taking interest in this proposal. There is no remaining
> work for this proposal. It’s now “waiting for review”. It would be
> great if you can provide a review report, so we can change the status
> to “ready for commit”.
> I’ve updated the patch against the latest HEAD.
Hi all,
Rev
On Thu, Jun 12, 2025 at 03:10:56PM -0500, Nathan Bossart wrote:
> Barring comments/objections, I'll plan on committing/back-patching this in
> the near future.
Here is what I have staged for commit. I ended up moving it to the
"Transaction ID and Snapshot Information Functions" table, which is wh
Hi Steven
thanks for the review!
> I have two comments:
> 1. Does table_beginscan_parallel_tidrange() need an assert of relid,
> like what table_beginscan_parallel() did?
> Assert(RelationGetRelid(relation) == pscan->phs_relid);
In the v6 rebased patch, the assert has become:
Assert(RelFile
On Wed, Jun 25, 2025 at 5:44 PM Peter Geoghegan wrote:
> Correction: there *is* a live bug like this on Postgres 18/HEAD, which
> involves simple scalar inequalities with an incomplete opfamily.
> Attached v3 fixes the bug in its new 0001-* patch.
Attached is v4, which is largely just a polished
> On 27 Jun 2025, at 11:41, Dmitry wrote:
>
> It seems that the hypothesis has not been confirmed.
Indeed.
For some reason your reproduction does not work for me.
I tried to create a test from your workload description. PFA patch with a very
dirty prototype.
to run test you can run:
cd con
On 2025-06-16 Mo 12:23 AM, Oleg Tselebrovskiy wrote:
I think we need to do something slightly earlier than that. Attached is
what I propose.
I agree, my patch could miss one case with undefined $$stderr.
Fixed my patch with your suggestion
I don't think we need your test script, and it l
Hi Nathan,
Thank you for submitting this patch.
Best regards,
Jianghua
Nathan Bossart 于2025年6月27日周五 11:44写道：
> Committed.
>
> --
> nathan
>
Committed.
--
nathan
Hi,
On Fri, Jun 27, 2025 at 04:52:08PM +0200, Tomas Vondra wrote:
> Here's three small patches, that should handle the issue
Thanks for the patches!
> 0001 - Adds the batching into pg_numa_query_pages, so that the callers
> don't need to do anything.
>
> The batching doesn't seem to cause any p
The OpenSSL code in libpq have two issues for multithreading: the verify_cb
callback use a global variable to pass back error detail state and there is one
use of strerror().
The attached fixes both, with no functional change, in order to pave the way
for multithreading:
* Rather than using a g
Hi,
I agree we should improve the behavior on NUMA systems. But I'm not sure
this patch does far enough, or perhaps the approach seems a bit too
blunt, ignoring some interesting stuff.
AFAICS the patch essentially does the same thing as
numactl --interleave=all
except that it only does that
On Fri, 27 Jun 2025 at 07:05, Michael Paquier wrote:
>
> On Thu, Jun 26, 2025 at 05:25:42PM +0530, vignesh C wrote:
> > On Thu, 26 Jun 2025 at 06:22, Michael Paquier wrote:
> >> So you are suggesting the addition of an extra ReadPageInternal() that
> >> forces a read of only the read, perform the
On 2025/06/27 13:09, Yugo Nagata wrote:
On Fri, 27 Jun 2025 12:22:17 +0900
Fujii Masao wrote:
However, your patch is clear, and it seems we don't need to worry about this
concern.
Your patch looks good to me.
Thanks for reviewing the patch! I've marked it as ready for committer.
I have
>> Making the index cleanup stable takes a certain amount of cycles,,
Thanks for your explanation!
Here's three small patches, that should handle the issue
0001 - Adds the batching into pg_numa_query_pages, so that the callers
don't need to do anything.
The batching doesn't seem to cause any performance regression. 32-bit
systems can't use that much memory anyway, and on 64-bit systems the
ba
On 2025/06/27 22:30, Álvaro Herrera wrote:
On 2025-06-27, Fujii Masao wrote:
To make this distinction, I just started thinking it's better to raise
the error
in ATExecAlterConstraint() rather than in gram.y. I've attached a draft
patch that
follows this approach.
Hmm I don't like this very
On Wed, 2025-06-25 at 12:22 +1000, Peter Smith wrote:
> Hi.
>
> Here are the latest v9* patches. These have following changes:
>
> 0001
> - fixes some of the minor quirks reported by Tomas [1].
>
> 0002
> - fixes to added address some of Timur's feedback/patches [2]
> - test code updated to rem
On 2025-06-27, Fujii Masao wrote:
> To make this distinction, I just started thinking it's better to raise
> the error
> in ATExecAlterConstraint() rather than in gram.y. I've attached a draft
> patch that
> follows this approach.
Hmm I don't like this very much, it feels very kludgy. I think i
> Let me rephrase what you are saying to be sure I understand it
> correctly: Since it's stated in the page that the page describes the
> 3.2 protocol specifically, arguably there's only one valid
> StartupMessage within that context, i.e. the one with 196610.
Your rephrasing is correct.
> I agre
Hi, Michael!
On Fri, Jun 27, 2025 at 3:26 AM Michael Paquier wrote:
> On Thu, Jun 26, 2025 at 08:54:55AM +0200, Andrei Lepikhov wrote:
> > Before diving into the pg_hint_plan code, I wonder why you don't have
> > similar issues with the remove_useless_joins. We intentionally designed SJE
> > coup
Hi Michael,
> I think that it would be nice to have some test coverage for such
> cases in pg_verifybackup for both the client side and the server side
> of backups compressed, relying on the backend to generate some random
> data dumped into a file at the root of a data folder.
Yes, good p
On Wed, Jun 18, 2025 at 12:23 PM Michael Paquier wrote:
> While testing the patch, I've bumped into this scenario which feels
> incomplete:
> - Rely on a default location of the service file, like
> $HOME/.pg_service.conf.
> - Define a service, with PGSERVICE or a connection parameter.
> In this c
Nathan Bossart writes:
> On Thu, Jun 26, 2025 at 01:46:10PM -0700, Jianghua Yang wrote:
>> These errors trace back to failures in `dsm_attach()`, where the
>> segment handle value was incorrectly interpreted due to sign extension
>> from `int32`.
> I think there might be something else going on.
Hi,
Recently I had to debug an issue with VACUUM's truncate stage taking
an AE lock for a long time, which caused an unpleasant outage due to
blocked queries on a replica. That, and remembering a thread about
this over at [0] got me looking at the code that truncates the
relation.
After looking a
Hi,
On Thu, Jun 5, 2025 at 5:21 PM Yugo Nagata wrote:
>
> I've attached updated patches.
>
I have some comments on v4-0001 patch :
1)
heap_freetuple should be called for every tuple that we get from
SearchSysCacheCopy3.
But if tuple is valid after the first SearchSysCacheCopy3, we
overwrite the
On Thu, 26 Jun 2025 at 18:04, Jelte Fennema-Nio wrote:
> On Fri, 30 May 2025 at 11:00, Jelte Fennema-Nio
> wrote:
> > If we decide to keep it I think it would be best to have all protocol
> > changes on a single page. I'd just put the changes from 2.0 to 3.0 at
> > the bottom of the page.
>
> At
Hi Nathan,
> Adding some tests here seems like a good idea.
>
> I'm not sure I see much point in testing both min-heaps and max-heaps. The
> only difference between the two is in the comparator, so IMHO the extra
> tests really only serve to test the test comparator.
Make sense. Here is the corr
Dear Nagata-san, Ikeda-san,
> > In my opinion, when the --continue-on-error option is enabled, pgbench
> > clients does not need to start new transactions after network errors and
> > other errors except for SQL-level errors.
>
> +1
>
> I agree that --continue-on-error prevents pgbench from term
On Fri, Jun 27, 2025 at 3:48 PM cca5507 wrote:
>
> Hi,
>
> I refactor the code and fix the git apply warning according to [1].
>
> Here are the new version patches.
>
> --
> Regards,
> ChangAo Chen
>
> [1]
> https://www.postgresql.org/message-id/Zrmh7X8jYCbFYXjH%40ip-10-97-1-34.eu-west-3.compute.
On Thu, 26 Jun 2025 at 15:27, shveta malik wrote:
>
> On Tue, Jun 24, 2025 at 9:48 AM Shlok Kyal wrote:
> >
> > I have included the changes for
> > it in v14-0003 patch.
> >
> Thanks for the patches. I have reviewed patch001 alone, please find
> few comments:
>
> 1)
> +
> + The RESET clause
On 6/2/2024 13:51, Ashutosh Bapat wrote:
On Fri, Dec 15, 2023 at 5:22 AM Ashutosh Bapat
wrote:
First patch is no longer required. Here's rebased set
The patches are raw. make check has some crashes that I need to fix. I
am waiting to hear whether this is useful and whether the design is on
the
> On 27 Jun 2025, at 14:25, Michael Paquier wrote:
>
> Thoughts or comments?
I'm +1 on having full-fledged injection points in back branches where possible.
Right now I'm debugging a PG-17(probably) problem where injection preloading
would be handy (though functionality is available via hac
Hi all,
As mentioned during my talk about injection points at the last
pgconf.dev, I think that we should be more aggressive with the
backpatching of the core APIs of this facility, to ease the porting of
tests across more branches and the maintenance of this stuff itself,
so as it evolves in a co
> On 26 Jun 2025, at 23:06, Daniel Gustafsson wrote:
> I'll propose changes for these comments in the morning when coffee has been
> had.
The attached moves to logging on stderr along with a test for this, and also
removes the WARNING prefix that was added to the other stderr loggings since
that
On Fri, Jun 27, 2025 at 2:11 PM Fujii Masao wrote:
>
> I had this concern because other commands, like ALTER SEQUENCE ALTER
> CONSTRAINT NOT VALID,
> can also hit this error, and seeing an error message that starts with ALTER
> TABLE ...
> in that context can be confusing. That's why I thought a
On Fri, Jun 27, 2025 at 7:58 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Thu, Jun 26, 2025 at 4:28 PM shveta malik wrote:
> >
> > On Thu, Jun 26, 2025 at 8:31 AM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > Thanks for the comments. All of them look good to me and
> > > have been addressed in V42.
> > >
Hackers,
I noticed in testing and usage that pg_createsubscriber doesn't check for
an existing replication slot before attempting to create one, whereas it
*does* check for existing publications.
If it were to check for an existing replication slot, then the --dry-run
mode would be able to detect
On Mon, 26 May 2025 19:17:53 +1200
David Rowley wrote:
> On Mon, 26 May 2025 at 18:08, Yugo Nagata wrote:
> > While building PostgreSQL 17 on Windows, I noticed bitcode files (.bc) are
> > not
> > generated with meson. Does this means that "inlining" of JIT doesn't
> > work when PostgreSQL is b
On Thu, Jun 26, 2025 at 9:43 AM torikoshia wrote:
>
> After applying the patch, blank lines exist between these statements as
> below. Do we really need these blank lines?
>
> ```
> scan_rel = table_open(scan_oid,
> AccessShareLock);
>
> CopyThis
41 matches
Mail list logo
