Hi Michael,
Thank you for your reply. I reviewed the thread you mentioned, and it seems
that the issue needing to be fixed is not the same as the one I previously
raised.
I am considering whether the 2PC file check logic in PrepareRedoAdd() can be
modified. Currently, each time a XLOG_XACT_PREPA
On Mon, Jul 14, 2025 at 02:35:31PM +0800, jian he wrote:
> here, "text_eq" should be "texteq"?
Yes, I think that you are right here.
--
Michael
signature.asc
Description: PGP signature
> On 14 Jul 2025, at 00:15, Melanie Plageman wrote:
>
>>
>> Also, I'd prefer "page is not marked all-visible but visibility map bit is
>> set in relation" to emit XX001 for monitoring reasons, but again, this is
>> small note, while I need a broader picture.
>
> Could you clarify what you
hi.
index_create comments:
/*
* Btree text_pattern_ops uses text_eq as the equality operator, which is
* fine as long as the collation is deterministic; text_eq then reduces to
* bitwise equality and so it is semantically compatible with the other
* operators and functions
On 14/07/2025 4:20 am, Zhijie Hou (Fujitsu) wrote:
Thank you for the proposal ! I find it to be a very interesting feature。
I tested the patch you shared in your original email and encountered potential
deadlocks when testing pgbench TPC-B like workload. Could you please provide an
updated patc
Hi!
On this -
> Non-FULL vacuum should already work. Only commands like VACUUM FULL
> and CLUSTER which move tuples around should be disabled on TOAST
> tables.
Cool, toast tables are subject to bloating in update-heavy scenarios
and it's a big problem in production systems, it seems there is a p
On Sun, Jul 13, 2025 at 4:34 PM Amit Kapila wrote:
>
> On Tue, Jul 1, 2025 at 7:35 PM Ashutosh Bapat
> wrote:
> >
> > On Tue, Jul 1, 2025 at 4:23 PM Amit Kapila wrote:
> > >
> > > On Mon, Jun 30, 2025 at 3:24 PM Ashutosh Bapat
> > > wrote:
> > > >
> > > > Hi All,
> > > > In a recent logical rep
On Mon, Jul 14, 2025 at 12:07 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Sun, Jul 06, 2025 at 03:21:08PM +0200, Dmitry Dolgov wrote:
> > > On Sun, Jul 06, 2025 at 03:01:34PM +0200, Dmitry Dolgov wrote:
> > > * This way any backend between the ProcSignalBarriers will be able
> > > pr
Thanks for the comments.
On Fri, Jul 11, 2025 at 11:09 PM Andrei Lepikhov wrote:
>
> On 11/7/2025 10:16, Amit Langote wrote:
> > Hi,
> >
> > I’ve been experimenting with an optimization that reduces executor
> > overhead by avoiding unnecessary attribute deformation. Specifically,
> > if the exec
On Wed, Mar 26, 2025 at 8:15 PM Tom Lane wrote:
> jian he writes:
> > the attached patch is to implement $subject.
>
> Why would this be a good idea? I don't see any principled fallback
> definition of the column. (No, "NULL" is not that.) Certainly we
> should support ALTER TABLE DROP COLUMN
On Fri, Jul 11, 2025 at 6:58 PM Japin Li wrote:
> On Fri, 11 Jul 2025 at 17:16, Amit Langote wrote:
> > Hi,
> >
> > I’ve been experimenting with an optimization that reduces executor
> > overhead by avoiding unnecessary attribute deformation. Specifically,
> > if the executor knows which attribut
On Tuesday, July 8, 2025 2:36 PM Konstantin Knizhnik wrote:
>
> There is well known Postgres problem that logical replication subscriber can
> not caught-up with publisher just because LR changes are applied by single
> worker and at publisher changes are made by multiple concurrent backends.
> T
I took another look and got it working, after something else I'm using
insisted on installing libpq. It's mostly no-brainer hunks like this:
- dependencies: [frontend_code, libpq],
+ dependencies: [libpq, frontend_code],
For the new src/test/modules/test_oat_hooks/meson.build, I copied what
I'
On Thu, Jul 10, 2025 at 02:21:38PM +0900, Michael Paquier wrote:
> After that, I have applied a few cosmetic tweaks here and there, and
> attached is what I have staged for commit, minus proper commit
> messages. The new TAP tests have some WIN32-specific things, and I
> won't be able to look at t
On Sun, Jul 13, 2025 at 5:57 PM Tomas Vondra wrote:
> Thank you! I'll take a look next week, but these numbers suggest you
> simplified it a lot..
Right.
I'm still not done removing code from nbtree here. I still haven't
done things like generalize _bt_killitems across all index AMs. That
can la
On 7/13/25 01:50, Peter Geoghegan wrote:
> On Thu, May 1, 2025 at 7:02 PM Tomas Vondra wrote:
>> There's two "fix" patches trying to make this work - it does not crash,
>> and almost all the "incorrect" query results are actually stats about
>> buffer hits etc. And that is expected to change wi
On 12/9/24 18:27, Eric Hanson wrote:
> On Thu, Dec 5, 2024 at 4:29 PM Jelte Fennema-Nio wrote:
>> When PgBouncer is in transaction mode, the server connection will only
>> be unlinked, when PgBouncer receives a ReadyForQuery with the "idle"
>> flag from the server **and** there are no messages fro
On 12/5/24 16:12, Robert Haas wrote:
> On Wed, Dec 4, 2024 at 5:54 PM Jelte Fennema-Nio wrote:
>> On Wed, 4 Dec 2024 at 22:05, Robert Haas wrote:
>>> I do think the protocol change is better.
>>
>> Fully agreed. But I now also know the herculean amount of effort
>> that's necessary for that to ha
"David E. Wheeler" writes:
> How bout we keep it a simple as possible to start with: make it either the
> last tag in the branch or else the first commit in the branch (the branch
> commit). Except for master, in which case perhaps since the last time a
> branch was created?
I do not think we
On Jul 13, 2025, at 15:43, Tom Lane wrote:
> I'm still liking the in-tree-file idea better. For one thing,
> it's not clear how expensive it'd be to search the git metadata
> for this other stuff.
How bout we keep it a simple as possible to start with: make it either the last
tag in the branch
"David E. Wheeler" writes:
> On Jul 13, 2025, at 15:02, Tom Lane wrote:
>> Alternatively, does git have any kind of metadata that isn't
>> a tag but acts sort of like one?
> Notes?
> https://git-scm.com/docs/git-notes
Hmm, maybe. I recall discussion about starting to use notes
to amend commi
On Tue, Jun 17, 2025 at 1:55 AM John Naylor wrote:
I took the minimal repro from [1] and took a look at the code generated
between clang 17 -O0 [2] and clang 17 -O3 [3]. I saw that -O3 (and
actually -O1 and -O2) generated the following code for:
castval = _mm512_castsi128_si512(_mm_cvtsi32_si128
On Sun, Jul 13, 2025 at 2:34 PM Andrey Borodin wrote:
>
> > On 12 Jul 2025, at 03:19, Melanie Plageman
> > wrote:
> >
> > remove the xl_heap_visible struct
>
> Same goes for VISIBILITYMAP_XLOG_CATALOG_REL and XLOG_HEAP2_VISIBLE. But
> please do not rush to remove it, perhaps I will have a more
On Jul 13, 2025, at 15:02, Tom Lane wrote:
> On reflection, assuming that this is being run by one or more
> buildfarm animals, there are not likely to be so many commits
> between runs that it'll be hard to assign blame after a breakage.
> So I'm not convinced that we need to build the logic you
Mankirat Singh writes:
> Here, I had a proposal: In case an ABI break is found, then loop
> through the commits after the last run to find the offending commit.
> We can also give the animal owner the option to decide whether they
> want to use their own machine to perform this search or not. Let
On Mon, 14 Jul 2025 at 00:07, David E. Wheeler wrote:
> Presumably you could work your way backwards until the ABI break disappears.
> That should minimize the number of commits you have to compile and test.
Makes sense. Thanks for the suggestion!
Regards,
Mankirat
On Jul 13, 2025, at 14:34, Mankirat Singh wrote:
> Here, I had a proposal: In case an ABI break is found, then loop
> through the commits after the last run to find the offending commit.
> We can also give the animal owner the option to decide whether they
> want to use their own machine to perfo
> On Sun, Jul 06, 2025 at 03:21:08PM +0200, Dmitry Dolgov wrote:
> > On Sun, Jul 06, 2025 at 03:01:34PM +0200, Dmitry Dolgov wrote:
> > * This way any backend between the ProcSignalBarriers will be able
> > proceed with whatever it's doing, and there is need to make sure it
> > will not access
On Sun, 13 Jul 2025 at 05:42, Tom Lane wrote:
> Nitpick: I think something is backwards about the labeling. AFAICS
> the described ABI change was made by 53cd0b71e not its predecessor
> 9dcc76414. It does look like a useful bit of information once
> correctly attributed, though.
Thanks for point
> On 12 Jul 2025, at 03:19, Melanie Plageman wrote:
>
> remove the xl_heap_visible struct
Same goes for VISIBILITYMAP_XLOG_CATALOG_REL and XLOG_HEAP2_VISIBLE. But please
do not rush to remove it, perhaps I will have a more exhaustive list later.
Currently the patch set is expected to be unp
On Mon, Jun 30, 2025 at 3:00 PM Masahiko Sawada wrote:
>
> On Wed, Jun 25, 2025 at 4:35 PM Sutou Kouhei wrote:
> >
> > Hi,
> >
> > In
> > "Re: Make COPY format extendable: Extract COPY TO format implementations"
> > on Wed, 25 Jun 2025 00:48:46 +0900,
> > Masahiko Sawada wrote:
> >
> > >>
On 7/11/25 23:03, Tomas Vondra wrote:
> ...
>
> e) indexscan regression (ryzen-indexscan-uniform-pg17-checksums.png)
>
> There's an interesting difference difference I noticed in the run with
> checksums on PG17. The full PDF is available here:
>
> https://github.com/tvondra/iomethod-tests/blob/r
Thank you!
--
Sergey
On 7/13/25 18:39, Tom Lane wrote:
Sergey Fukanchik writes:
I'm attaching v2 of the patch with "result" renamed to "week".
I pushed it already, actually.
regards, tom lane
Sergey Fukanchik writes:
> I'm attaching v2 of the patch with "result" renamed to "week".
I pushed it already, actually.
regards, tom lane
On Sunday, July 13, 2025, Marcos Pegoraro wrote:
> Em sáb., 12 de jul. de 2025 às 16:07, Tom Lane
> escreveu:
>
>> Indeed. If we put a restriction on this case then we'd just need to
>> invent a "REALLY CASCADE" option that did the more aggressive thing.
>>
>
> I understand that it's not possib
On Jul 11, 2025 at 23:57 +0800, Tom Lane , wrote:
> "David G. Johnston" writes:
> > On Friday, July 11, 2025, Zhang Mingli wrote:
> > > So, are both result sets technically correct given the absence of an ORDER
> > > BY clause?
>
> > The system is behaving within the requirements of the specific
Marcos Pegoraro writes:
> I understand that it's not possible to prevent DROP ... CASCADE from
> executing. However, the subsequent deletion of constraints, triggers, or
> functions will affect the behavior of other schemas, so I think it's
> reasonable to at least explicitly state in the log whic
> On 2 Jul 2025, at 10:11 PM, Nathan Bossart wrote:
>
> On Wed, Jul 02, 2025 at 12:37:37PM -0500, Nathan Bossart wrote:
>> Oops, it looks like renaming the test_dsm_registry functions wasn't a good
>> idea:
>>
>>
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2025-07
Em sáb., 12 de jul. de 2025 às 16:07, Tom Lane escreveu:
> Indeed. If we put a restriction on this case then we'd just need to
> invent a "REALLY CASCADE" option that did the more aggressive thing.
>
I understand that it's not possible to prevent DROP ... CASCADE from
executing. However, the su
Hi,
On 2025/07/10 18:17, Yugo Nagata wrote:
> On Wed, 9 Jul 2025 23:58:32 +0900
> Rintaro Ikeda wrote:
>
>> Hi,
>>
>> Thank you for the kind comments.
>>
>> I've updated the previous patch.
>
> Thank you for updating the patch!
>
>>> However, if a large number of errors occur, this could resul
Sure,
I'm attaching v2 of the patch with "result" renamed to "week".
--
Sergey
On 7/12/25 18:15, Tom Lane wrote:
=?utf-8?q?=D0=A4=D1=83=D0=BA=D0=B0=D0=BD=D1=87=D0=B8=D0=BA_=D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9?=
writes:
Hi PG hackers,
I found suspicious use of float8 in date2isoweek() and d
Hi!
Andres, thank you for the explanation about the locks.
I've already tried to pass scan keys and saw that it is
quite expensive.
--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
On 13/07/2025 1:28 pm, Amit Kapila wrote:
On Tue, Jul 8, 2025 at 12:06 PM Konstantin Knizhnik wrote:
There is well known Postgres problem that logical replication subscriber
can not caught-up with publisher just because LR changes are applied by
single worker and at publisher changes are made
On 13/07/2025 9:28 am, Amit Kapila wrote:
I didn't understand your scenario. pa_launch_parallel_worker() should
spawn a new worker only if all the workers in the pool are busy, and
then it will free the worker if the pool already has enough workers.
So, do you mean to say that the workers in th
On Fri, Jul 11, 2025 at 8:42 PM Fabrice Chapuis wrote:
>
> Hi Amit,
> Here is a proposed solution to handle the problem of creating the logical
> replication slot on standby after a switchover.
> Thank you for your comments and help on this issue
>
> Regards
>
> Fabrice
>
> diff --git a/src/backe
On Tue, Jul 1, 2025 at 7:35 PM Ashutosh Bapat
wrote:
>
> On Tue, Jul 1, 2025 at 4:23 PM Amit Kapila wrote:
> >
> > On Mon, Jun 30, 2025 at 3:24 PM Ashutosh Bapat
> > wrote:
> > >
> > > Hi All,
> > > In a recent logical replication issue, there were multiple replication
> > > slots involved, each
On Tue, Jul 8, 2025 at 12:06 PM Konstantin Knizhnik wrote:
>
> There is well known Postgres problem that logical replication subscriber
> can not caught-up with publisher just because LR changes are applied by
> single worker and at publisher changes are made by
> multiple concurrent backends.
>
With the functions GetNamedDSA and GetNamedDSHash added in fe07100
and the system view pg_dsm_registry_allocations (167ed8),
I think its time the DSM Registry get its own subsection in the documentation
that connects all these.
Here’s a patch that changes the title of xfunc-shared-addin-after-st
48 matches
Mail list logo
