On Fri, Jul 11, 2025 at 7:49 PM Konstantin Knizhnik wrote:
>
> On 08/07/2025 2:51 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 bec
"David E. Wheeler" writes:
> For those who didn’t click through, that post has a screenshot of an
> ABI diff report in the build farm server that I think is worth
> seeing:
Nitpick: I think something is backwards about the labeling. AFAICS
the described ABI change was made by 53cd0b71e not its p
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 with prefetching, not a
> bug. But then there are a
"Joel Jacobson" writes:
> The attached proof-of-concept patch proposes a straightforward
> optimization for the single-listener case. It introduces a shared-memory
> hash table mapping (dboid, channelname) to the ProcNumber of a single
> listener.
What does that do to the cost and parallelizabili
Hi hackers,
The current LISTEN/NOTIFY implementation is well-suited for use-cases like
cache invalidation where many backends listen on the same channel. However,
its scalability is limited when many backends listen on distinct
channels. The root of the problem is that Async_Notify must signal eve
On Jul 11, 2025, at 04:26, Florents Tselai wrote:
> Attached
Thank you! This looks great. The attached revision makes a a couple of minor
changes:
* Change the line wrap of the docs to be more like the rest of func.sgml
* Remove an unnecessary nested if statement
* Removed `==` from one of t
> On 11 Jul 2025, at 17:53, Bernd Helmle wrote:
> Since i wanted to dig a little deeper in this patch i took the
> opportunity and rebased it to current master, hopefully not having
> broken something seriously.
Thanks, much appreciated!
--
Daniel Gustafsson
On Sat, Jul 12, 2025 at 12:32:31AM +0300, Aleksander Alekseev wrote:
> Good catch. I don't see any reason why we might want to keep ckptFullXid.
> Also I checked if there are any references left to this field - there are
> none.
Thanks, committed.
--
nathan
After further study I've understood what was bothering me about
the logic in compareJsonbContainers (lines 280ff). Because
JsonbIteratorNext doesn't presently guarantee to set val->type
when returning WJB_DONE, the stanza appears to be at risk of
undefined behavior should one iterator return that
> On 10 Jul 2025, at 09:33, Daniel Gustafsson wrote:
>
>> On 5 Jul 2025, at 10:56, Peter Eisentraut wrote:
>
>> This patch version looks good to me.
>
> Thanks for review, I'll get it committed shortly.
This was committed yesterday ahead of the beta release.
--
Daniel Gustafsson
"David G. Johnston" writes:
> On Sat, Jul 12, 2025 at 11:31 AM Marcos Pegoraro wrote:
>> I don't know how to fix it, but I think it's a bug.
> You told it to cascade and it will happily remove anything within the
> database to comply. It is not a bug. The docs even make that point
> explicitly
On Sat, Jul 12, 2025 at 11:31 AM Marcos Pegoraro wrote:
> --If I use client_min_messages = notice I'll receive a hint that the
> exception is being dropped. But I didn't read that because I want to drop
> everything on that schema, but only on that schema.
>
> mydb=# set client_min_messages = war
Working with several schemas and the same structure, I created an extension
on one of those schemas, and it worked fine for all schemas. But then I
don't need that schema anymore, and when I drop it with cascade, it drops
that extension too, and doing that it drops all constraints related to it.
S
On Jul 12, 2025, at 00:07, Florents Tselai wrote:
> To recap so far;
>
> - I like your changes and renames on the parser/lexer; it indeed looks much
> cleaner now and will help with future improvements.
Thanks!
> - I also like the addition of executeStringInternalMethod ; it'll help us add
Andres Freund writes:
> On 2025-07-12 13:42:54 -0400, Tom Lane wrote:
>> I don't care for this patch: replacing an Assert with pg_assume just
>> seems like a very bad idea.
> That shouldn't be a problem - pg_assume() is defined to be an Assert() in
> USE_ASSERT_CHECKING builds.
Ah, my bad. But
Hi,
On 2025-07-12 13:42:54 -0400, Tom Lane wrote:
> Dmitry Mityugov writes:
> > When compiled with Assert() macro disabled, GCC 15 produces warnings
> > about possibly uninitialized variables in
> > src/backend/utils/adt/jsonb_util.c module. This problem was discussed in
> > detail in this thr
Dmitry Mityugov writes:
> When compiled with Assert() macro disabled, GCC 15 produces warnings
> about possibly uninitialized variables in
> src/backend/utils/adt/jsonb_util.c module. This problem was discussed in
> detail in this thread, in April 2025:
> https://www.postgresql.org/message-id/
Rebasing this for v19
0003-Add-new-server-config-cleartext_passwords_action.patch
Description: Binary data
Hi,
On 2025-07-10 09:52:45 +0900, Michael Paquier wrote:
> On Wed, Jul 09, 2025 at 03:46:43PM -0400, Tom Lane wrote:
> > Andres Freund writes:
> >> Seems like we should just remove TransactionIdIsActive()?
> >
> > +1. I wondered if any extensions might depend on it, but
> > could not find any t
=?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 date2isoyear(). In both
> cases float8 is only used for storing the value, while the entire calculation
> on the righ
Patch review
OVERALL:
I like the idea, especially the date variant. Unlike Tom, I'm not
particularly concerned about breakage of existing scripts, as
most already are working just fine with raw numbers and I don't see this
patch breaking them.
In a selfish vein, I would use the "date" and timest
On Wed, Jun 25, 2025 at 5:28 AM Dmitry Koval wrote:
>
> Hi!
> Thanks for notes!
>
hi.
+static void
+transformPartitionCmdForMerge(CreateStmtContext *cxt, PartitionCmd *partcmd)
+{
+
+ /* Is current partition a DEFAULT partition? */
+ defaultPartOid =
get_default_oid_from_partdesc(RelationGetParti
Hi PG hackers,
I found suspicious use of float8 in date2isoweek() and date2isoyear(). In both
cases float8 is only used for storing the value, while the entire calculation
on the right happens in integers:
float8 result = (dayn - (day4 - day0)) / 7 + 1;
At the end date2isoweek() returns `result
Hello Hackers,
I have been working on this project with David since last month.
I've written some blogs about the progress, the most recent one is here [1]
Here's the draft pull request for anyone interested in reviewing the code: [2]
On Wed, 9 Jul 2025 at 17:57, Álvaro Herrera wrote:
> Were you
Hi,
On Wed, 2025-07-09 at 13:53 +0700, John Naylor wrote:
> v3 still has direct-call and runtime-check paths. Let's keep only
> USE_S390X_CRC32C_WITH_RUNTIME_CHECK and discard the direct call
> configure checks. Once that's done I'll take a closer look and test
> as
> well. The rest should be sma
I ran following query sequences using extended query protocol + simple
query protocol. It seems they give inconsistent behavior.
(I ran the query sequences using pgproto. pgproto is a tool coming
with Pgpool-II which sends and receives low level F/B protocol
message).
There's a table called "t1"
26 matches
Mail list logo
