Hi Yura san,
> I just don't get, why it should be "in-memory"? All the same things you
> describe further, but storing in paged index on-disk with caching
> through shared_buffers - why this way it wouldn't work?
We make the columnar store resident in memory for maximum search performance.
But I
Business Scenario:
The BI department requires real-time data from the operational database. In our
current approach (on platform 14), we create a separate database within our
department's real-time backup instance, set up a logical replication account,
replicate required tables to this isolated
On Fri, 4 Apr 2025 19:18:11 +0900
Fujii Masao wrote:
>
>
> On 2025/04/04 0:21, Fujii Masao wrote:
> > Thanks for updating the patch!
> >
> > If there are no objections, I'll proceed with committing it using the
> > following commit log.
>
> I've pushed the patch. Thanks!
Thank you!
> Whi
On Tue, Apr 8, 2025 at 10:49 AM Michael Paquier wrote:
>
> On Tue, Apr 08, 2025 at 08:47:53AM +0530, Ashutosh Bapat wrote:
> > Thanks for addressing the comment.
> >
> > In PG code, we start a multiline comment with just /* on the first
> > line and end with just */ on the last line. All the lines
On Sun, Apr 6, 2025 at 10:15 PM Andres Freund wrote:
>
> Hi,
[..]
> The obvious solution to that would be to increase BAS_BULKREAD substantially
> above 256kB.
>
> For quite a while was worried about increasing the size, because somewhere (I
> couldn't find it while writing this email, will add th
After the introduction of pg_overexplain extension and Robert's comment
[0], I'm starting to have doubts about whether it's still appropriate to
add this information to EXPLAIN itself. If there are compelling reasons
that showing the plan type would be broadly useful to users in EXPLAIN,
I’m ha
On 4/2/25 15:26, Richard Guo wrote:
While working on another patch, I looked at ChangeVarNodes() and found
some issues introduced by the self-join elimination commit. I think
it'd better to fix or improve them.
* ChangeVarNodes_walker includes special handling for RestrictInfo
nodes. And it ad
On Wed, Mar 26, 2025 at 12:47 AM Nazir Bilal Yavuz wrote:
> Rebased version of the patch is attached.
I noticed that it wasn't working on a Mac I tested because
guc_tables.c needed to include and fixed that. I also
did some minor editig of the docs, mostly removing the mention of
specific file
On 08/04/2025 04:59, Tom Lane wrote:
The attached patch removes test cases concerned with contrib/spi/
from the core regression tests and instead puts them into new
test files in contrib/spi/ itself.
+1
My original motivation for looking at this was the discussion in
[1] about whether to remo
Looked like a bit illogical order on re-reading it so I want to make
clear that the pg_upgrade-like test showing 100min for 100 million LOs
is at the end of last message and the proposed solution is at the
beginning
On Tue, Apr 8, 2025 at 9:15 AM Hannu Krosing wrote:
>
> I was testing on version
Hi Alvaro san,
I am sorry for my late reply. I continue to work on proposing VCI feature to
the community.
> I think this is definitely an important and welcome development.
> I'm looking forward to patches in this area.
Thank you!
I am currently preparing to share VCI designs with PGConf.dev.
On Tue, Apr 8, 2025 at 12:17 AM Nathan Bossart wrote:
>
> On Mon, Apr 07, 2025 at 10:33:47PM +0200, Hannu Krosing wrote:
> > The obvious solution would be to handle the table
> > `pg_largeobject_metadata` the same way as we currently handle
> > `pg_largeobject `by not doing anything with it in `pg
Hi,
On 2025-04-08 02:00:35 +, Hayato Kuroda (Fujitsu) wrote:
> > I have changed quite a few comments and commit message for the PG17
> > patch in the attached. Can you update PG16 patch based on this and
> > also use the same commit message as used in attached for all the three
> > patches?
>
On Tue, Apr 8, 2025 at 12:08 AM Steve Chavez wrote:
>
> I haven't found a similar style of comment on any other function call.
>
> I've attached a new patch using the style you suggest.
>
> That being said, I do find the first form much more readable, but I
> understand this is a debatable subjec
On Mon, Apr 7, 2025 at 3:28 PM Zhijie Hou (Fujitsu)
wrote:
>
> > What is the
> > behavior of conflict reporting code in case of exclusion constraints?
>
> Under logical replication context, since we do not detect conflicts for
> exclusion
> constraints, it would simply report the original constra
Hi, all
When I read the libpq source code, I found unnecessary static type qualifiers
in PQsetClientEncoding().
diff --git a/src/interfaces/libpq/fe-connect.c
b/src/interfaces/libpq/fe-connect.c
index 0258d9ace3c..300ddfffd55 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/
On Tue, 8 Apr 2025 at 12:21, Ryohei Takahashi (Fujitsu)
wrote:
> By using Statistics Import and Export feature, is it possible to achieve the
> above request by following procedure?
> (1) Export the statistics from production environment by using pg_dump
> --statistics-only.
> (2) On the staging
I was testing on version 17
On Tue, Apr 8, 2025 at 6:52 AM Michael Paquier wrote:
>
> On Mon, Apr 07, 2025 at 05:25:32PM -0400, Tom Lane wrote:
> > What version are you testing? We did some work in that area in the
> > v17 cycle (a45c78e32).
>
> I am puzzled by the target version used here, as
On 4/8/25 01:26, Shinoda, Noriyoshi (SXD Japan FSI) wrote:
> Hi,
>
> Thanks for developing this great feature.
> The manual says that the 'size' column of the pg_shmem_allocations_numa view
> is 'int4', but the implementation is 'int8'.
> The attached small patch fixes the manual.
>
Thank
Hi,
On 2025-04-08 18:11:04 +1200, Thomas Munro wrote:
> On Tue, Apr 8, 2025 at 2:20 PM Andres Freund wrote:
> > In the attached I implemented the above idea, with some small additional
> > refinements:
>
> LGTM.
Thanks for checking.
> How I wish EXPLAIN would show some clues about strategies.
> On 8 Apr 2025, at 10:03, Daniel Gustafsson wrote:
> There was a bug in the shmem init function which caused it to fail on Windows,
> the attached fixes that.
With this building green in CI over several re-builds, and another pass over
the docs and code with pgindent etc done, I pushed this ear
Hi,
Thank you for your reply.
I understand that the access plans are not guaranteed to be the same.
Can we add these notes to the pg_dump page in the PostgreSQL Documentation
in order to prevent users from asking the same question?
Regards,
Ryohei Takahashi
On Tue, Apr 8, 2025 at 08:04:22AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 7:32 AM Bruce Momjian wrote:
> > Uh, where are we on the inclusion of curl in our build? Maybe it was
> > explained but I have not seen it.
>
> The above is discussing a patch to split this into its own load
Daniel Gustafsson writes:
> On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
>> Frankly, I think the name "anywhere on Earth" is confusing, since it
>> really is "everywhere on Earth":
> I find both of the above needlessly confusing when we instead could use UTC
> which is a more universally unders
Hi,
On 2025-04-08 17:44:19 +0500, Kirill Reshke wrote:
> On Mon, 7 Apr 2025 at 23:00, Tomas Vondra wrote:
> > I'll let the CI run the tests on it, and
> > then will push, unless someone has more comments.
> >
>
>
> Hi! I noticed strange failure after this commit[0]
>
> Looks like it is related
On 2025-04-08 Tu 5:21 AM, Heikki Linnakangas wrote:
This is too late for v18 of course, so I'll park it in the next CF.
In my opinion this would still be totally OK for v18. It's just test
changes. I would rather commit cleanups like this sooner than later.
Yeah, that was my reaction t
On Tue, 8 Apr 2025 at 12:31, Andrei Lepikhov wrote:
>
> On 4/4/25 09:37, Richard Guo wrote:
> > On Wed, Apr 2, 2025 at 10:26 PM Richard Guo wrote:
> > With more exposure to the changes in ChangeVarNodes(), I have some
> > more concerns. As I understand it, ChangeVarNodes() is designed to
> > upd
Andrew Dunstan writes:
> On 2025-04-07 Mo 7:41 PM, Michael Paquier wrote:
>> delete_old_cluster.sh would be left around even if not using a VPATH
>> build with ./configure (your commit message does not mention that).
>> Even if .gitignore discards it, the file is here.
> I don't think that matter
On Tue, Apr 8, 2025 at 9:30 PM Peter Eisentraut wrote:
>
> On 08.04.25 16:59, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> >> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> >> Earth):
> >>
> >>
> >> https://wiki.postgres
On 2025/04/08 18:46, Daniel Gustafsson wrote:
On 8 Apr 2025, at 10:03, Daniel Gustafsson wrote:
There was a bug in the shmem init function which caused it to fail on Windows,
the attached fixes that.
With this building green in CI over several re-builds, and another pass over
the docs and
> On 8 Apr 2025, at 18:33, Bruce Momjian wrote:
> Would we have to put out minor releases for curl CVEs? I don't think we
> have to for OpenSSL so would curl be the same?
Why do you envision this being different from all other dependencies we have?
For OpenSSL we also happily build against a ve
On Tue, Apr 8, 2025 at 9:33 AM Bruce Momjian wrote:
> On Tue, Apr 8, 2025 at 09:17:03AM -0700, Jacob Champion wrote:
> > It allows packagers to ship the OAuth library separately, so end users
> > that don't want the additional exposure don't have to install it at
> > all.
>
> Okay, so how would t
On Tue, Apr 8, 2025 at 12:29 PM Andrew Dunstan wrote:
> The fact that there is this confusion is an indication that the AoE
> experiment is a failure. If it's not obvious, and people have to think
> about it, then it's not working. And I bet there is a huge number of
> people who have never even h
> On 8 Apr 2025, at 18:41, Fujii Masao wrote:
> On 2025/04/08 18:46, Daniel Gustafsson wrote:
>>> On 8 Apr 2025, at 10:03, Daniel Gustafsson wrote:
>>> There was a bug in the shmem init function which caused it to fail on
>>> Windows,
>>> the attached fixes that.
>> With this building green in C
Hi,
Over the course of the last two releases, we have added many read
stream users. Each user specifies any number of flags (defined at the
top of read_stream.h) which govern different aspects of the read
stream behavior.
There are a few inconsistencies (many caused by me) that I want to
iron out
On Tue, Apr 8, 2025 at 09:43:01AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 9:33 AM Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 09:17:03AM -0700, Jacob Champion wrote:
> > > It allows packagers to ship the OAuth library separately, so end users
> > > that don't want the additiona
Hi,
Thanks a lot to all the members who participated in the commitfest.
Here are the final numbers at the end of the commitfest:
status | End of Commitfest
+---
Needs review: |54
Waiting on Author: |
Hi,
meson version is upgraded 1.7.0 in NetBSD and that causes ecpg tests
to fail with [1]:
'Could not open file
/home/postgres/postgres/build/src/interfaces/ecpg/test/compat_informix/dec_test.c
for reading'
This is already fixed on b2bdb972c0, attached patch just adds
$MBUILD_TARGET to the NetBS
On 2025-04-07 Mo 7:41 PM, Michael Paquier wrote:
On Mon, Apr 07, 2025 at 04:45:52PM -0500, Nathan Bossart wrote:
The other pg_upgrade tests chdir to tmp_check prior to running pg_upgrade
to avoid leaving behind delete_old_cluster.{sh,bat}. 006_transfer_modes.pl
should, too. However, this tes
On Tue, Apr 08, 2025 at 06:19:02AM +, Bertrand Drouvot wrote:
> - A new injection_points_wakeup_detach() function that is holding the spinlock
> during the whole duration to ensure that no process can wait in between the
> wakeup and the detach.
That would not a correct spinlock use. injectio
Hi,
On April 8, 2025 9:21:57 AM EDT, Tomas Vondra wrote:
>On 4/8/25 15:06, Andres Freund wrote:
>> Hi,
>>
>> On 2025-04-08 17:44:19 +0500, Kirill Reshke wrote:
>>> On Mon, 7 Apr 2025 at 23:00, Tomas Vondra wrote:
I'll let the CI run the tests on it, and
then will push, unless someone
On Tue, Apr 08, 2025 at 01:36:58PM -0400, Tom Lane wrote:
> Hmm ... one annoying thing for this project is that AFAICS pg_upgrade
> does *not* preserve database OIDs, which is problematic for using
> COPY to load pg_shdepend rows.
I think it does; see commit aa01051.
--
nathan
Nathan Bossart writes:
> Unless I'm missing something, we don't seem to have had any dependency
> handling before commit 12a53c7. Was that broken before we moved to SQL
> commands?
Sounds like it :-(
regards, tom lane
On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther wrote:
> This means that shipping another .so file will not happen with this approach.
> Assuming OAuth will be picked up by some of the bigger providers, that
> would... make me feel quite bad about it, actually.
It occurs to me that I didn't res
On Tue, Apr 08, 2025 at 05:13:15PM +0200, Daniel Gustafsson wrote:
>> On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
>> Frankly, I think the name "anywhere on Earth" is confusing, since it
>> really is "everywhere on Earth":
>
> I find both of the above needlessly confusing when we instead could u
Nathan Bossart writes:
> On Tue, Apr 08, 2025 at 01:36:58PM -0400, Tom Lane wrote:
>> Hmm ... one annoying thing for this project is that AFAICS pg_upgrade
>> does *not* preserve database OIDs, which is problematic for using
>> COPY to load pg_shdepend rows.
> I think it does; see commit aa01051.
On Tue, Apr 8, 2025 at 10:10 AM Wolfgang Walther
wrote:
> And if that means making libpq modular at run-time, then this should be
> planned and built with all deps, and other use-cases (like static linking) in
> mind - and not like it is right now.
I think that'd be neat in concept, but specifi
Hi,
On 2025-04-08 13:02:11 -0400, Bruce Momjian wrote:
> On Tue, Apr 8, 2025 at 06:57:18PM +0200, Wolfgang Walther wrote:
> > Jacob Champion:
> > > On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther
> > > wrote:
> > > > And that should also not be a problem for distributions - they could
> > > >
On Tue, Mar 18, 2025 at 3:25 PM Amit Kapila wrote:
>
> On Mon, Mar 17, 2025 at 4:56 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > > Regarding the PG13, it cannot be
> > > applied
> > > as-is thus some adjustments are needed. I will share it in upcoming posts.
> >
> > Here is a patch set for PG13. A
On Fri, Apr 4, 2025 at 7:58 PM Nathan Bossart wrote:
>
> On Fri, Apr 04, 2025 at 05:16:43PM +0530, Amit Kapila wrote:
> > Can we dodge adding this push call if we restrict the length of the
> > origin name to some reasonable limit like 256 or 512 and avoid the
> > need of toast altogether?
>
> We
On Tue, Apr 8, 2025 at 6:42 AM Masahiko Sawada wrote:
>
>
> BTW have you measured the overheads of calling InputFunctionCallSafe
> twice? If it's significant, we might want to find other ways to
> achieve it as it would not be good to incur overhead just for
> relatively rare cases.
>
Please chec
On 4/8/25 08:32, Richard Guo wrote:
On Mon, Apr 7, 2025 at 9:54 PM Andrei Lepikhov wrote:
On 4/7/25 09:50, Richard Guo wrote:
Consider the join to t3. It is a unique join, and not all of its
restriction clauses are parameterized. Despite this, the check still
passes.
At the same time I th
> On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
>
> On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
>> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
>> Earth):
>>
>> https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
>> https://www.
On Tue, Apr 8, 2025 at 11:20:11AM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 11:13:51 -0400, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 08:04:22AM -0700, Jacob Champion wrote:
> > > On Tue, Apr 8, 2025 at 7:32 AM Bruce Momjian wrote:
> > > > Uh, where are we on the inclusion of cu
On 08/04/2025 16:55, Tom Lane wrote:
Well, I don't mind pushing it, but does anyone want to review
it first? It sounded like Heikki had at least eyeballed the
patch, but I'm not sure if he's ready to sign off on it.
It looks good to me.
diff --git a/doc/src/sgml/contrib-spi.sgml b/doc/src/sg
On Tue, Apr 08, 2025 at 04:44:02PM +0530, Amit Kapila wrote:
> On Fri, Apr 4, 2025 at 7:58 PM Nathan Bossart
> wrote:
>> On Fri, Apr 04, 2025 at 05:16:43PM +0530, Amit Kapila wrote:
>> > Can we dodge adding this push call if we restrict the length of the
>> > origin name to some reasonable limit
On Tue, Apr 8, 2025 at 06:42:19PM +0200, Daniel Gustafsson wrote:
> > On 8 Apr 2025, at 18:33, Bruce Momjian wrote:
>
> > Would we have to put out minor releases for curl CVEs? I don't think we
> > have to for OpenSSL so would curl be the same?
>
> Why do you envision this being different from
On Wed, 9 Apr 2025 at 02:24, Tom Lane wrote:
>
> David Rowley writes:
> > I've pushed the patch now. Thanks for all the reviews of my adjustments.
>
> Shouldn't the CF entry be marked committed?
I've done that now.
88f55bc97 added code to do faster lookups of ec_derives clauses, so I
think that
On Wed, 9 Apr 2025 at 03:54, Bruce Momjian wrote:
> We did have this discussion when AoE was chosen for PG 18 and the idea
> was that as long as it is before April 18 midnight wherever you are, it
> is not feature freeze yet.
I think it maybe once made sense for the moment to stop accepting new
p
Jacob Champion:
On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther wrote:
And that should also not be a problem for distributions - they could offer a
libpq and a libpq_oauth package, where only one of them can be installed at the
same time, I guess? *
My outsider understanding is that maintain
Andrew Dunstan writes:
> On 2025-04-08 Tu 5:21 AM, Heikki Linnakangas wrote:
>>> This is too late for v18 of course, so I'll park it in the next CF.
>> In my opinion this would still be totally OK for v18. It's just test
>> changes. I would rather commit cleanups like this sooner than later.
>
On Tue, Apr 8, 2025 at 9:14 AM Bruce Momjian wrote:
> How does this patch help us avoid having to handle curl CVEs and its
> curl's additional dependencies? As I understand the patch, it makes
> libpq _not_ have additional dependencies but moves the dependencies to a
> special loadable library th
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
> On 08.04.25 16:59, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> > > Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> > > Earth):
> > >
> > >
> > > https://wi
On 08/04/2025 19:11, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
On 08.04.25 16:59, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Earth):
On 08.04.25 14:22, Junwang Zhao wrote:
When I read the libpq source code, I found unnecessary static type qualifiers
in PQsetClientEncoding().
diff --git a/src/interfaces/libpq/fe-connect.c
b/src/interfaces/libpq/fe-connect.c
index 0258d9ace3c..300ddfffd55 100644
--- a/src/interfaces/libpq/fe-c
On Tue, Apr 08, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
> On 08.04.25 16:59, Bruce Momjian wrote:
>> Anywhere on Earth (AoE) is a calendar designation that indicates
>> that a period expires when the date passes everywhere on Earth.
>
> Yes, that works intuitively when you spec
On 2025-04-08 Tu 12:11 PM, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
On 08.04.25 16:59, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Ear
Jacob Champion:
The currently proposed patch would have you package and install a
separate .so module implementing OAuth, which the staticlib would load
once when needed. Similarly to how you still have to somehow
dynamically link your static app against Curl.
As a staticlib user, how do you fee
On Tue, Apr 8, 2025 at 11:45:09AM -0400, Peter Geoghegan wrote:
> On Tue, Apr 8, 2025 at 11:20 AM Nathan Bossart
> wrote:
> > +1 for UTC.
>
> +1, I think that AoE is needlessly obscure
We did have this discussion when AoE was chosen for PG 18 and the idea
was that as long as it is before April
> On 8 Apr 2025, at 18:41, Fujii Masao wrote:
> I noticed that the third argument of pg_get_process_memory_contexts() is named
> "retries" in pg_proc.dat, while the documentation refers to it as "timeout".
I've committed this patch as it was obviously correct, thanks!
> Also, as I mentioned ear
On 4/8/25 15:41, Hannu Krosing wrote:
On Tue, Apr 8, 2025 at 8:39 PM Nathan Bossart wrote:
...
I've also verified that the dependency information is carried over in
upgrades to later versions (AFAICT all the supported ones).
If I remember correctly the change to not copying
pg_largeobject
On Mon, Apr 7, 2025 at 9:41 AM Jacob Champion
wrote:
> > Not sure, the code looks correct at first glance. However, you could
> > also just keep the libpq-oauth strings in the libpq catalog. There
> > isn't really a need to make a separate one, since the versions you end
> > up installing are lo
hi,
On 2025-04-08 12:06:47 -0400, Melanie Plageman wrote:
> And a somewhat related point, with buffered IO, READ_STREAM_SEQUENTIAL
> disables prefetching to encourage OS readahead. I don't know if any
> other users than sequential scan should do this.
Worth adding that prefetches are only issued
On 4/8/25 16:59, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 09:35:37 -0400, Andres Freund wrote:
>> On April 8, 2025 9:21:57 AM EDT, Tomas Vondra wrote:
>>> On 4/8/25 15:06, Andres Freund wrote:
On 2025-04-08 17:44:19 +0500, Kirill Reshke wrote:
I think it's not right that something
On Mon, Apr 7, 2025 at 7:34 PM Thomas Munro wrote:
>
> On Thu, Feb 13, 2025 at 1:40 PM Melanie Plageman
> wrote:
> > Thomas mentioned this to me off-list, and I think he's right. We
> > likely need to rethink the way parallel bitmap heap scan workers get
> > block assignments for reading and pref
On Tue, Apr 8, 2025 at 11:12 PM Dean Rasheed wrote:
> On Tue, 8 Apr 2025 at 12:31, Andrei Lepikhov wrote:
> > On 4/4/25 09:37, Richard Guo wrote:
> > > With more exposure to the changes in ChangeVarNodes(), I have some
> > > more concerns. As I understand it, ChangeVarNodes() is designed to
> >
Hi,
I was looking at the recent push for the pg_createsubscription "--all"
option [1], because I was absent for several weeks prior.
I found some minor non-functional issues as follows:
==
doc/src/sgml/ref/pg_createsubscriber.sgml
1.
+ If the database name is not specified in publish
On Tue, Apr 8, 2025, at 5:25 PM, Nathan Bossart wrote:
> On Tue, Apr 08, 2025 at 04:44:02PM +0530, Amit Kapila wrote:
> > On Fri, Apr 4, 2025 at 7:58 PM Nathan Bossart
> > wrote:
> >> On Fri, Apr 04, 2025 at 05:16:43PM +0530, Amit Kapila wrote:
> >> > Can we dodge adding this push call if we rest
Hi,
In another thread I had previously suggested adding a 2nd synopsis to
the pg_createsubscriber docs. See [1, comment #5].
--
CURRENT
pg_createsubscriber [option...] { -d | --database }dbname { -D |
--pgdata }datadir { -P | --publisher-server }connstr
SUGGESTION
pg_createsubscriber [option
On Tue, Apr 08, 2025 at 06:42:53AM +, Bertrand Drouvot wrote:
> Fully agree. Will need to find another way to prevent a process to wait
> between the
> wakeup and the detach. I'll open a dedicated thread.
By the way, there is a small thing that's itching me a bit about the
change done in LogS
On Wed, Mar 26, 2025 at 3:54 PM Amit Kapila wrote:
>
> On Tue, Mar 25, 2025 at 5:30 PM Ashutosh Bapat
> wrote:
> >
> > On Thu, Mar 20, 2025 at 5:54 PM Amit Kapila wrote:
> > >
> > > *
> > > +
> > > + pg_createsubscriber
> > > + option
> > > +
> > > +
> > > + -a
> > > + --a
On Thu, Apr 3, 2025 at 3:16 PM Zhijie Hou (Fujitsu) wrote:
>
> On Thu, Apr 3, 2025 at 1:38 PM Masahiko Sawada wrote:
>
> >
> > On Wed, Apr 2, 2025 at 7:58 PM Amit Kapila
> > wrote:
> > >
> > > On Thu, Apr 3, 2025 at 7:50 AM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > On Thu, Apr 3, 2025 a
hi.
attached patch is for address pg_dump inconsistency
when parent is "not null not valid" while child is "not null".
The following query before/after pg_dump should return the same result.
select conrelid::regclass::text, conname, convalidated, coninhcount,
conislocal, conparentid, contype
fro
On Wed, 9 Apr 2025 at 17:09, Amit Langote wrote:
> Should the following paragraph in src/backend/optimizer/README be
> updated to reflect the new reality after recent changes?
>
> An EquivalenceClass can contain "em_is_child" members, which are copies
> of members that contain appendrel pa
On Wed, Apr 9, 2025 at 10:51 AM David Rowley wrote:
>
> On Wed, 9 Apr 2025 at 17:09, Amit Langote wrote:
> > Should the following paragraph in src/backend/optimizer/README be
> > updated to reflect the new reality after recent changes?
> >
> > An EquivalenceClass can contain "em_is_child" mem
On Mon, Apr 7, 2025 at 2:13 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> In the new v4 version
> of the patch the first option is implemented.
>
The patches don't apply cleanly using git am but patch -p1 applies
them cleanly. However I see following compilation errors
RuntimeError: command
Amit Langote writes:
> Should the following paragraph in src/backend/optimizer/README be
> updated to reflect the new reality after recent changes?
> An EquivalenceClass can contain "em_is_child" members, which are copies
> of members that contain appendrel parent relation Vars, transpose
On Thu, Mar 20, 2025 at 3:02 PM David Rowley wrote:
> For making this work, I think the attached should be about the guts of
> the code changes. I didn't look at the comments. Right now I can't
> think of any reason why this can't be done, but some experimentation
> might reveal some reason that i
On Tue, Apr 8, 2025 at 06:57:18PM +0200, Wolfgang Walther wrote:
> Jacob Champion:
> > On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther
> > wrote:
> > > And that should also not be a problem for distributions - they could
> > > offer a libpq and a libpq_oauth package, where only one of them can
On Tue, Apr 8, 2025 at 09:17:03AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 9:14 AM Bruce Momjian wrote:
> > How does this patch help us avoid having to handle curl CVEs and its
> > curl's additional dependencies? As I understand the patch, it makes
> > libpq _not_ have additional de
Hi,
On 2025-04-08 01:17:17 +0200, Daniel Gustafsson wrote:
> > On 7 Apr 2025, at 17:43, Andres Freund wrote:
>
> >> + /*
> >> + * Hold the process lock to protect writes to process specific memory. Two
> >> + * processes publishing statistics do not block each other.
> >> + */
> >
> > s/specifi
Hi,
On 2025-04-07 09:09:39 +0200, Bernd Helmle wrote:
> Am Sonntag, dem 06.04.2025 um 23:02 -0400 schrieb Andres Freund:
> > On 2025-04-05 19:22:58 +0200, Alvaro Herrera wrote:
> > > I have pushed this now, hoping it won't explode.
> >
> > I have a WIP patch that adds gcc specific allocator attri
On 4/8/25 15:06, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 17:44:19 +0500, Kirill Reshke wrote:
>> On Mon, 7 Apr 2025 at 23:00, Tomas Vondra wrote:
>>> I'll let the CI run the tests on it, and
>>> then will push, unless someone has more comments.
>>>
>>
>>
>> Hi! I noticed strange failure afte
On Tue, Apr 08, 2025 at 11:21:31PM -0300, Euler Taveira wrote:
> The logical replication creates origin names as pg_SUBOID_RELID or pg_SUBOID.
> It means the maximum origin name is 24. This limited origin name also applies
> to pglogical that limits the name to 54 IIRC. I think that covers the majo
On Wed, 09 Apr 2025 at 10:34, Junwang Zhao wrote:
> On Wed, Apr 9, 2025 at 5:22 AM David Rowley wrote:
>>
>> On Wed, 9 Apr 2025 at 03:46, Peter Eisentraut wrote:
>> > To avoid creating an array on the stack, you could maybe write it with a
>> > pointer instead, like:
>> >
>> > const char * const
Junwang Zhao writes:
> On Tue, Apr 8, 2025 at 4:29 PM Japin Li wrote:
>> - static const char query[] = "set client_encoding to '%s'";
>> + const char query[] = "set client_encoding to '%s'";
> I doubt that, if you remove the *static*, it will allocate more memory
> on stack and
On Tue, Apr 08, 2025 at 12:37:43PM -0400, Tom Lane wrote:
> Hannu Krosing writes:
>> I think we do preserve role oids
>
> Oh ... I'd been looking for mentions of "role" in
> pg_upgrade_support.c, but what I should have looked for was
> "pg_authid". So yeah, we do preserve role OIDs, and maybe th
On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther wrote:
> And that should also not be a problem for distributions - they could offer a
> libpq and a libpq_oauth package, where only one of them can be installed at
> the same time, I guess? *
My outsider understanding is that maintaining this sort
Nathan Bossart writes:
> I do think it's worth considering going back to copying
> pg_largobject_metadata's files for upgrades from v16 and newer.
(If we do this) I don't see why we'd need to stop at v16. I'm
envisioning that we'd use COPY, which will be dealing in the
text representation of acl
Hannu Krosing writes:
> In copy case I would expect the presence of grants to not make much
> difference.
aclitemin is slower than a lot of other datatype input functions,
but it's still got to be faster than a GRANT.
regards, tom lane
1 - 100 of 149 matches
Mail list logo
