On Wed, Jan 24, 2024 at 12:04 PM Ashutosh Bapat
wrote:
> >
> > Ok. Maybe just rephrase that comment somehow then?
>
> Please see refactoring patches attached to [1]. Refactoring that way
> makes it unnecessary to mention "regular inheritance" in each comment.
> Yet I have included a modified
On Tue, Jan 23, 2024 at 10:58 AM Masahiko Sawada wrote:
>
> The new patches probably need to be polished but the VacDeadItemInfo
> idea looks good to me.
That idea looks good to me, too. Since you already likely know what
you'd like to polish, I don't have much to say except for a few
questions
On Tue, Jan 23, 2024 at 12:29 AM Peter Eisentraut wrote:
>
> On 22.01.24 13:23, Ashutosh Bapat wrote:
> >> if (newdef->identity)
> >> {
> >> Assert(!is_partioning);
> >> /*
> >>* Identity is never inherited. The new column can have an
> >>*
Hi Peter,
On Mon, Jan 22, 2024 at 6:13 PM Peter Eisentraut wrote:
>
> On 06.12.23 09:23, Peter Eisentraut wrote:
> > The (now) second patch is also still of interest to me, but I have since
> > noticed that I think [0] should be fixed first, but to make that fix
> > simpler, I would like the
On Tue, Jan 23, 2024 at 7:41 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear hackers,
>
> > We fixed some of the comments posted in the thread. We have created it
> > as top-up patch 0002 and 0003.
>
> I found that the CFbot raised an ERROR. Also, it may not work well in case
> of production build.
>
On Wed, Jan 24, 2024 at 2:43 PM Amit Kapila wrote:
>
> On Wed, Jan 24, 2024 at 10:41 AM Masahiko Sawada
> wrote:
> >
> > On Mon, Jan 22, 2024 at 3:58 PM Amit Kapila wrote:
> > >
> > > Can we think of using GetStandbyFlushRecPtr()? We probably need to
> > > expose this function, if this works
Hi,
I've implemented custom COPY format feature based on the
current design discussion. See the attached patches for
details.
I also implemented a PoC COPY format handler for Apache
Arrow with this implementation and it worked.
https://github.com/kou/pg-copy-arrow
The patches implement not only
On Wed, Jan 24, 2024 at 10:41 AM Masahiko Sawada wrote:
>
> On Mon, Jan 22, 2024 at 3:58 PM Amit Kapila wrote:
> >
> > Can we think of using GetStandbyFlushRecPtr()? We probably need to
> > expose this function, if this works for the required purpose.
>
> GetStandbyFlushRecPtr() seems good. But
On Mon, 15 Jan 2024 at 14:39, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Vignesh,
>
> Thanks for updating the patch!
>
> > > 7.
> > > ```
> > > +
> > > +dba@node1:/opt/PostgreSQL/postgres//bin$ pg_ctl -D
> > /opt/PostgreSQL/pub_data stop -l logfile
> > > +
> > > ```
> > >
> > > Hmm. I thought you
On Mon, 15 Jan 2024 at 09:01, Peter Smith wrote:
>
> Hi Vignesh, here are some review comments for patch v2-0001.
>
> ==
> doc/src/sgml/ref/pgupgrade.sgml
>
> 1.
> +
> +Upgrade logical replication clusters
> +
> +
> + Refer logical
> replication upgrade section
> + for
On Mon, Jan 22, 2024 at 3:58 PM Amit Kapila wrote:
>
> On Fri, Jan 19, 2024 at 3:55 PM shveta malik wrote:
> >
> > On Fri, Jan 19, 2024 at 10:35 AM Masahiko Sawada
> > wrote:
> > >
> > >
> > > Thank you for updating the patch. I have some comments:
> > >
> > > ---
> > > +latestWalEnd =
On Wed, Jan 24, 2024 at 8:52 AM Peter Smith wrote:
>
> Here are some comments for patch v66-0001.
>
> ==
> doc/src/sgml/catalogs.sgml
>
> 1.
> +
> + If true, the associated replication slots (i.e. the main slot and the
> + table sync slots) in the upstream database are
Here are some comments for patch v66-0001.
==
doc/src/sgml/catalogs.sgml
1.
+
+ If true, the associated replication slots (i.e. the main slot and the
+ table sync slots) in the upstream database are enabled to be
+ synchronized to the physical standbys
+
On Mon, Jan 22, 2024 at 8:48 PM Andrew Dunstan wrote:
>
>
> On 2024-01-21 Su 22:19, Peter Smith wrote:
> > 2024-01 Commitfest.
> >
> > Hi, This patch has a CF status of "Needs Review" [1], but it seems
> > like there was some CFbot test failure last time it was run [2].
> > Please have a look and
Came across this while looking for patches to review. IMO this thread has
been hijacked to the point of being not useful for the subject. I suggest
this discussion regarding prefetch move to its own thread and this thread
and commitfest entry be ended/returned with feedback.
Also IMO, the
On Mon, Jan 22, 2024, at 6:30 AM, Shlok Kyal wrote:
> We fixed some of the comments posted in the thread. We have created it
> as top-up patch 0002 and 0003.
Cool.
> 0002 patch contains the following changes:
> * Add a timeout option for the recovery option, per [1]. The code was
> basically
On Tue, Jan 23, 2024 at 12:43 PM Tomas Vondra
wrote:
>
> On 1/19/24 22:43, Melanie Plageman wrote:
>
> > We fill a queue with blocks from TIDs that we fetched from the index.
> > The queue is saved in a scan descriptor that is made available to the
> > streaming read callback. Once the queue is
Hi,
On 2024-01-23 22:00:01 +0300, Alexander Lakhin wrote:
> 23.01.2024 20:30, Andres Freund wrote:
> > I don't think that's viable and would cause more problems than it solves,
> > it'd
> > make us think that we might have an old postgres process hanging around that
> > needs to be terminted
Hi,
On 2024-01-23 17:26:19 -0600, Tristan Partin wrote:
> On Tue Jan 23, 2024 at 4:23 PM CST, Andres Freund wrote:
> > Hi,
> >
> > On 2024-01-23 15:50:11 -0600, Tristan Partin wrote:
> > > What is keeping us from using pthread_sigmask(3) instead of
> > > sigprocmask(2)?
> >
> > We would need
On Mon, Jan 22, 2024, at 4:06 AM, Hayato Kuroda (Fujitsu) wrote:
> I analyzed and found a reason. This is because publications are invisible for
> some transactions.
>
> As the first place, below operations were executed in this case.
> Tuples were inserted after getting consistent_lsn, but
On Mon, Jan 22, 2024, at 6:22 AM, Amit Kapila wrote:
> On Mon, Jan 22, 2024 at 2:38 PM Hayato Kuroda (Fujitsu)
> wrote:
> > >
> > > > Yet other options could be
> > > > pg_buildsubscriber, pg_makesubscriber as 'build' or 'make' in the name
> > > > sounds like we are doing some work to create the
> On 23 Jan 2024, at 23:33, Tom Lane wrote:
> Anyway, v2-0001 below is the previous patch rebased up to current
> (only line numbers change), and then v2-0002 responds to your
> and Daniel's review comments.
LGTM.
--
Daniel Gustafsson
On Tue, Jan 23, 2024 at 04:13:05PM -0500, Dave Cramer wrote:
> On Tue, 23 Jan 2024 at 08:46, Dave Cramer wrote:
>> The attached patch works with v17. I will work on getting a buildfarm
>> animal up shortly
Thanks for doing that!
> I can build using meson manually, but for some reason building
On Tue Jan 23, 2024 at 4:23 PM CST, Andres Freund wrote:
Hi,
On 2024-01-23 15:50:11 -0600, Tristan Partin wrote:
> What is keeping us from using pthread_sigmask(3) instead of sigprocmask(2)?
We would need to make sure to compile with threading support everywhere. One
issue is that on some
Aleksander Alekseev writes:
> I reviewed the patch and tested it on MacOS and generally concur with
> stated above. The only nitpick I have is the apparent lack of negative
> tests for to_timestamp(), e.g. when the string doesn't match the
> specified format.
That's an excellent suggestion
Hi,
On 2024-01-23 15:50:11 -0600, Tristan Partin wrote:
> What is keeping us from using pthread_sigmask(3) instead of sigprocmask(2)?
We would need to make sure to compile with threading support everywhere. One
issue is that on some platforms things get slower once you actually start
using
On Tue, Jan 23, 2024 at 8:00 PM Alexander Lakhin wrote:
> Please look at the following query, which triggers an assertion failure on
> updating the field dathasloginevt for an entry in pg_database:
> SELECT format('CREATE DATABASE db1 LOCALE_PROVIDER icu ICU_LOCALE en ENCODING
> utf8
> ICU_RULES
On Mon, Jan 22, 2024 at 11:43 PM Heikki Linnakangas wrote:
> On 22/01/2024 21:58, Vladimir Churyukin wrote:
> > A question about protocol design - would it be possible to extend the
> > protocol, so it can handle multiple startup / authentication messages
> > over a single connection? Are there
On Tue Jan 23, 2024 at 2:10 PM CST, Tristan Partin wrote:
On Tue Jan 23, 2024 at 1:47 PM CST, Andres Freund wrote:
> Hi,
> On 2024-01-23 13:20:15 -0600, Tristan Partin wrote:
> > These checks are not effective for what they are trying to prevent. A recent
> > commit[0] in libcurl when used on
On Tue, 23 Jan 2024 at 08:46, Dave Cramer wrote:
>
>
> On Tue, 19 Sept 2023 at 23:48, Michael Paquier
> wrote:
>
>> On Tue, Sep 19, 2023 at 01:35:17PM +0100, Anthony Roberts wrote:
>> > Was there an explicit request for something there? I was under the
>> > impression that this was all just
On Wed, 24 Jan 2024 at 08:15, Alvaro Herrera wrote:
> (Similarly, allowing GROUP BY to ignore columns not in the GROUP BY,
> when a UNIQUE constraint exists and all columns are NOT NULL; currently
> we allow that for PRIMARY KEY, but if you have the NOT NULL constraint
> OIDs to cue the plan
On Thu, Jan 11, 2024 at 11:27 AM Tomas Vondra
wrote:
> 1) desirability: We want a built-in way to handle sequences in logical
> replication. I think everyone agrees this is not a way to do distributed
> sequences in an active-active setups, but that there are other use cases
> that need this
This patch may be better, which only track catalog modified transactions.
--
Regards,
ChangAo Chen
--Original--
From:
"cca5507"
On Tue, Jan 23, 2024 at 06:33:25PM +0100, Alvaro Herrera wrote:
> On 2024-Jan-22, Nathan Bossart wrote:
>
>> Here is a patch.
>
> Looks reasonable.
Committed. Thank you for the report and the reviews.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Jan 22, 2024 at 4:13 PM Matthias van de Meent
wrote:
> On Fri, 19 Jan 2024 at 23:42, Peter Geoghegan wrote:
> And this is where I disagree with your (percieved) implicit argument
> that this should be and always stay this way.
I never said that, and didn't intend to imply it. As I
On Tue, Jan 23, 2024 at 9:34 AM Akshat Jaimini wrote:
> Hello!
> I was going through the previous conversations for this particular patch and
> it seems that this patch failed some tests previously?
> Imo we should move it to the next CF so that the remaining issues can be
> resolved
Hi,
On 2024-01-22 15:18:35 +0800, Andy Fan wrote:
> I used sigismember(, SIGQUIT) to detect if a process is doing a
> quickdie, however this is bad not only because it doesn't work on
> Windows, but also it has too poor performance even it impacts on
> USE_ASSERT_CHECKING build only. In v8, I
On Tue Jan 23, 2024 at 1:47 PM CST, Andres Freund wrote:
Hi,
On 2024-01-23 13:20:15 -0600, Tristan Partin wrote:
> These checks are not effective for what they are trying to prevent. A recent
> commit[0] in libcurl when used on macOS has been tripping the
> pthread_is_threaded_np() check in
Hi,
On 2024-01-18 14:00:58 -0500, Robert Haas wrote:
> > The LockBufHdr also used init_local_spin_delay / perform_spin_delay
> > infrastruce and then it has the same issue like ${subject}, it is pretty
> > like the code in s_lock; Based on my current knowledge, I think we
> > should add the check
Hi,
On 2024-01-23 21:07:08 +0200, Heikki Linnakangas wrote:
> On 22/01/2024 23:07, Andres Freund wrote:
> > > diff --git a/src/backend/utils/activity/backend_status.c
> > > b/src/backend/utils/activity/backend_status.c
> > > index 1a1050c8da1..92f24db4e18 100644
> > > ---
Hi,
On 2024-01-23 13:20:15 -0600, Tristan Partin wrote:
> These checks are not effective for what they are trying to prevent. A recent
> commit[0] in libcurl when used on macOS has been tripping the
> pthread_is_threaded_np() check in postmaster.c for shared_preload_libraries
> entries which use
On 19.01.24 18:12, Matthias Kuhn wrote:
Thanks,
This patch brought it further and indeed, the resulting libpq.so file is
unversioned when built for Android while it's versioned when built for
linux.
Ok, I have committed all of this now:
- Fix for correct order of host_system and portname
Alvaro Herrera writes:
> On 2024-Jan-23, David Rowley wrote:
>> Until now PostgreSQL has not been very smart about optimizing away IS
>> NOT NULL base quals on columns defined as NOT NULL.
> Hmm, what happens if a NOT NULL constraint is dropped and you have such
> a plan in plancache? As I
Michael Zhilin writes:
> Hi Andy,
>
> It looks like v5 is missing in your mail. Could you please check and resend
> it?
ha, yes.. v5 is really attached this time.
commit eee0b2058f912d0d56282711c5d88bc0b1b75c2f (HEAD ->
shared_detoast_value_v3)
Author: yizhi.fzh
Date: Tue Jan 23 13:38:34
These checks are not effective for what they are trying to prevent.
A recent commit[0] in libcurl when used on macOS has been tripping the
pthread_is_threaded_np() check in postmaster.c for
shared_preload_libraries entries which use libcurl (like Neon). Under
the hood, libcurl calls
On 2024-Jan-23, David Rowley wrote:
> Add better handling of redundant IS [NOT] NULL quals
>
> Until now PostgreSQL has not been very smart about optimizing away IS
> NOT NULL base quals on columns defined as NOT NULL.
Hmm, what happens if a NOT NULL constraint is dropped and you have such
a
On 22/01/2024 23:07, Andres Freund wrote:
On 2024-01-10 14:35:52 +0200, Heikki Linnakangas wrote:
@@ -5344,31 +5344,31 @@ StartChildProcess(AuxProcType type)
errno = save_errno;
switch (type)
{
- case StartupProcess:
+
23.01.2024 20:30, Andres Freund wrote:
I don't think that's viable and would cause more problems than it solves, it'd
make us think that we might have an old postgres process hanging around that
needs to be terminted before we can start up. And I simply don't see the point
- we already record
On 22.01.24 01:33, John Naylor wrote:
On Fri, Jan 19, 2024 at 9:03 PM Peter Eisentraut wrote:
The DECLARE_* macros map to actual BKI commands ("declare toast",
"declare index"). So I wanted to use a different verb to distinguish
"generate code for this" from those BKI commands.
That makes
On Tue, Jan 23, 2024 at 12:22:58PM -0600, Nathan Bossart wrote:
> On Tue, Jan 23, 2024 at 06:33:25PM +0100, Alvaro Herrera wrote:
>> Does this actually detect a problem if you take out the fix? I think
>> what's going to happen is that postmaster is going to crash, then do the
>> recovery cycle,
On Tue, Jan 23, 2024 at 10:10:27AM -0800, Andres Freund wrote:
> Hi,
>
> On 2024-01-23 13:09:22 +0100, Thomas Kellerer wrote:
> > Yoni Sade schrieb am 21.01.2024 um 19:07:
> > > It would be useful to have the ability to define for a role default
> > > vCPU affinity limits/thread priority settings
On Tue, Jan 23, 2024 at 06:33:25PM +0100, Alvaro Herrera wrote:
> On 2024-Jan-22, Nathan Bossart wrote:
>> This might be a topic for another thread, but I do wonder whether we could
>> put a generic pg_controldata check in node->stop that would at least make
>> sure that the state is some sort of
Hi,
On 2024-01-23 13:09:22 +0100, Thomas Kellerer wrote:
> Yoni Sade schrieb am 21.01.2024 um 19:07:
> > It would be useful to have the ability to define for a role default
> > vCPU affinity limits/thread priority settings so that more active
> > sessions could coexist similar to MySQL resource
Hello Alexander and Daniel,
Please look at the following query, which triggers an assertion failure on
updating the field dathasloginevt for an entry in pg_database:
SELECT format('CREATE DATABASE db1 LOCALE_PROVIDER icu ICU_LOCALE en ENCODING
utf8
ICU_RULES ''' || repeat(' ', 20) || '''
On 1/19/24 22:43, Melanie Plageman wrote:
> On Fri, Jan 12, 2024 at 11:42 AM Tomas Vondra
> wrote:
>>
>> On 1/9/24 21:31, Robert Haas wrote:
>>> On Thu, Jan 4, 2024 at 9:55 AM Tomas Vondra
>>> wrote:
Here's a somewhat reworked version of the patch. My initial goal was to
see if it
On 2024-Jan-22, Nathan Bossart wrote:
> Here is a patch.
Looks reasonable.
> This might be a topic for another thread, but I do wonder whether we could
> put a generic pg_controldata check in node->stop that would at least make
> sure that the state is some sort of expected shut-down state. My
Hi,
On 2024-01-23 08:00:00 +0300, Alexander Lakhin wrote:
> 22.01.2024 23:41, Andres Freund wrote:
> > ISTM that we shouldn't basically silently overlook shutdowns due to crashes
> > in
> > the tests. How to not do so is unfortunately not immediately obvious to
> > me...
> >
>
> FWIW, I
Hi,
On 2024-01-22 16:27:43 -0600, Nathan Bossart wrote:
> Here is a patch.
LGTM.
> This might be a topic for another thread, but I do wonder whether we could
> put a generic pg_controldata check in node->stop that would at least make
> sure that the state is some sort of expected shut-down
út 23. 1. 2024 v 11:38 odesílatel Christoph Berg napsal:
> Re: Pavel Stehule
> > It looks great for simple queries, but if somebody uses it like SELECT *
> > FROM pg_proc \gedit
>
> What's wrong with that? If the pager can handle the amount of data,
> the editor can do that as well. (If not, the
Re: Laurenz Albe
> > I'd just stop the flood right before it starts...
>
> I'd stop the flood right after json/jsonb.
Nod. I do see a point here, given it's "json in json", and not
"something else in json". Will try to make it work with \gedit.
> Arrays as database columns are probably too rare
On Mon, Jan 22, 2024 at 04:27:43PM -0600, Nathan Bossart wrote:
> Here is a patch.
I'd like to fix these crashes sooner than later, so I will plan on
committing this tonight (barring objections or feedback). If this needs to
be revisited later for some reason, I'm happy to do so.
--
Nathan
On Tue, 2024-01-23 at 16:36 +0100, Christoph Berg wrote:
> Re: Laurenz Albe
> > I am kind of unhappy about this change. It seems awkward and undesirable
> > so have JSON values decorated with weird quoting in JSON output.
> > I understand the motivation, but I bet it's not what will make users
>
Re: Laurenz Albe
> If you import the data into an existing structure, you don't need the
> metadata.
Also, since you were running the query yourself, you should know what
columns you were expecting.
Christoph
On Tue, 2024-01-23 at 08:01 -0700, David G. Johnston wrote:
> I do think that the output should include a metadata section that lists all of
> the actual columns in the result, the column position, and since we have the
> info available, the data type name and possibly OID. Then any column name
>
Re: Laurenz Albe
> I am kind of unhappy about this change. It seems awkward and undesirable
> so have JSON values decorated with weird quoting in JSON output.
> I understand the motivation, but I bet it's not what will make users
> happy.
Well, why stop at JSON, and not represent any array type
On Tue, Jan 23, 2024 at 7:35 AM Stefan Keller wrote:
> Am Di., 23. Jan. 2024 um 15:15 Uhr schrieb Laurenz Albe
> :
> > I understand the motivation, but I bet it's not what will make users
> > happy.
> >
> > If you need to disambiguate between SQL NULL and JSON null, my
> > preferred solution
On 2024-Jan-23, Alvaro Herrera wrote:
> ... oh, actually FreeBSD failed with this strange problem while linking:
I figured this out. For dtrace support, we need to run dtrace on all
the objects produced by the compilation step, but because I took
lwlock.o out of the objects used to produce the
Am Di., 23. Jan. 2024 um 15:15 Uhr schrieb Laurenz Albe
:
> I understand the motivation, but I bet it's not what will make users
> happy.
>
> If you need to disambiguate between SQL NULL and JSON null, my
> preferred solution would be to omit SQL NULL columns from the output
> altogether.
I fully
Hello!
I was going through the previous conversations for this particular patch and it
seems that this patch failed some tests previously?
Imo we should move it to the next CF so that the remaining issues can be
resolved accordingly.
On Mon, 2024-01-22 at 16:19 +0100, Christoph Berg wrote:
> What I did now in v3 of this patch is to print boolean and numeric
> values (ints, floats, numeric) without quotes, while adding the quotes
> back to json. This solves the NULL vs 'null'::json problem.
The patch is working as advertised.
On Tue, 19 Sept 2023 at 23:48, Michael Paquier wrote:
> On Tue, Sep 19, 2023 at 01:35:17PM +0100, Anthony Roberts wrote:
> > Was there an explicit request for something there? I was under the
> > impression that this was all just suggestion/theory at the moment.
>
> Yes. The addition of a
Hi,
> Since I had this on my (ever-growing) TODO I re-prioritized today and took a
> look at it since I think it's something we should support.
>
> Nothing really sticks out and I was unable to poke any holes so I don't have
> too much more to offer than a LGTM.
>
> + while (len > 0)
> + {
>
Hi,
> Well, I'm not a developer, I just wanted to pitch this idea as a DBA who
> would make use of this feature.
I don't think one shouldn't be a developer in order to write an RFC
and drive its discussion within the community. On top of that I'm
pretty confident as a DBA you can contribute
On 2024-Jan-23, Alvaro Herrera wrote:
> This is what I came up with.
Hm, I forgot the attachment, thanks Heikki for the reminder.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Las mujeres son como hondas: mientras más resistencia tienen,
más lejos puedes
On 2024-Jan-23, Alvaro Herrera wrote:
> ... oh, actually FreeBSD failed with this strange problem while linking:
> [11:39:43.550] ld: error: undefined symbol:
> __dtraceenabled_postgresql___lwlock__wait__start
> [11:39:43.551] >>> referenced by lwlock.c:1277
>
On Sat, Jan 20, 2024 at 7:55 AM vignesh C wrote:
> On Fri, 22 Sept 2023 at 18:45, Amul Sul wrote:
> >
> >
> >
> > On Wed, Sep 20, 2023 at 8:29 PM Alvaro Herrera
> wrote:
> >>
> >> On 2023-Sep-20, Amul Sul wrote:
> >>
> >> > On the latest master head, I can see a $subject bug that seems to be
>
Yoni Sade schrieb am 21.01.2024 um 19:07:
> It would be useful to have the ability to define for a role default
> vCPU affinity limits/thread priority settings so that more active
> sessions could coexist similar to MySQL resource groups
>
Well, I'm not a developer, I just wanted to pitch this idea as a DBA who
would make use of this feature.
Best Regards,
Yoni Sade
בתאריך יום ב׳, 22 בינו׳ 2024 ב-12:43 מאת Aleksander Alekseev <
aleksan...@timescale.com>:
> Hi Yoni,
>
> > It would be useful to have the ability to define
On Tue, Jan 23, 2024 at 9:45 AM Peter Smith wrote:
>
> Here are some review comments for v65-0002
Thanks Peter for the feedback. I have addressed these in v66.
>
> 4. GetStandbyFlushRecPtr
>
> /*
> - * Returns the latest point in WAL that has been safely flushed to disk, and
> - * can be sent
On 2024-Jan-23, Heikki Linnakangas wrote:
> On 23/01/2024 12:25, Alvaro Herrera wrote:
> > 2. More invasively, rework generate-lwlocknames.pl so that both lwlocks
> > and these builtin tranche names appear in a single array. (We could do
> > so by #include'ing lwlocknames.c at the top of the
On Fri, Jan 19, 2024 at 1:05 PM feichanghong wrote:
>
> This issue has been reported in the list at the below link, but
> received almost no response:
> https://www.postgresql.org/message-id/18280-4c8060178cb41750%40postgresql.org
> Hoping for some feedback from kernel hackers, thanks!
>
Thanks
Hi Aleksander,
[ I'm writing this off-list to minimize noise, but we can continue the
discussion in -hackers, if you wish ]
22.01.2024 14:00, Aleksander Alekseev wrote:
Hi,
But node1 knows that it's a standby now and it's expected to get all the
WAL records from the primary, doesn't it?
Re: Pavel Stehule
> It looks great for simple queries, but if somebody uses it like SELECT *
> FROM pg_proc \gedit
What's wrong with that? If the pager can handle the amount of data,
the editor can do that as well. (If not, the fix is to just not run
the command, and not blame the feature.)
> I
On 23/01/2024 12:25, Alvaro Herrera wrote:
This array of tranche names is looking pretty ugly these days, and it'll
get worse as we add more members to it. I propose to use C99 designated
initializers, like we've done for other arrays. Patch attached.
The way I've coded in this patch, it
This array of tranche names is looking pretty ugly these days, and it'll
get worse as we add more members to it. I propose to use C99 designated
initializers, like we've done for other arrays. Patch attached.
The way I've coded in this patch, it means the array will now have 52
NULL pointers at
On 18.01.24 16:54, Matthias van de Meent wrote:
At $prevjob we had a use case for PRNG to generate small,
non-sequential "random" numbers without the birthday problem occurring
in sqrt(option space) because that'd increase the printed length of
the numbers beyond a set limit. The sequence API
On Tue, Jan 23, 2024 at 12:33 AM Jeff Davis wrote:
>
> On Mon, 2024-01-22 at 18:41 +0530, Ashutosh Bapat wrote:
> > 0002 adds a prefix "regress_" to almost every object that is created
> > in foreign_data.sql.
>
> psql \dew outputs the owner, which in the case of a built-in FDW is the
> bootstrap
On 23/01/2024 10:24, Kyotaro Horiguchi wrote:
Thank you for looking this!
At Tue, 23 Jan 2024 15:07:10 +0900, Fujii Masao wrote in
Regarding the patch, here are the review comments.
+/*
+ * Is current process a wal receiver?
+ */
+bool
+IsWalReceiver(void)
+{
+ return WalRcv != NULL;
+}
On 22.01.24 21:04, Tristan Partin wrote:
I am not really following why we can't use the builtin Meson dist
command. The only difference from my testing is it doesn't use a
--prefix argument.
Here are some problems I have identified:
1. meson dist internally runs gzip without the -n option.
On Mon, Jan 22, 2024 at 10:30 PM shveta malik
wrote:
>
> On Mon, Jan 22, 2024 at 3:10 PM Amit Kapila
wrote:
> >
> > minor comments on the patch:
> > ===
>
> PFA v65 addressing the comments.
>
> Addressed comments by Peter in [1], comments by Hou-San in [2],
> comments by Amit
On Tue, 23 Jan 2024 at 18:56, Richard Guo wrote:
>
> Similar to what we did to GROUP BY keys in 0452b461bc, I think we can do
> the same to DISTINCT keys, i.e. reordering DISTINCT keys to match input
> path's pathkeys, which can help reduce cost by avoiding unnecessary
> re-sort, or allowing us
Hi Andy,
It looks like v5 is missing in your mail. Could you please check and
resend it?
Thanks,
Michael.
On 1/23/24 08:44, Andy Fan wrote:
Hi,
Peter Smith writes:
2024-01 Commitfest.
Hi, This patch has a CF status of "Needs Review" [1], but it seems
there were CFbot test failures
On 23/01/2024 06:23, Kyotaro Horiguchi wrote:
At Mon, 22 Jan 2024 13:29:10 -0800, Andres Freund wrote in
Hi,
On 2024-01-19 12:28:05 +0900, Michael Paquier wrote:
On Thu, Jan 18, 2024 at 03:42:28PM +0200, Heikki Linnakangas wrote:
Given that commit 728f86fec6 that introduced this issue was
On Mon, Jan 22, 2024 at 11:46 PM jian he wrote:
>
> On Mon, Jan 22, 2024 at 10:28 PM Amit Langote wrote:
> >
> > > based on v35.
> > > Now I only applied from 0001 to 0007.
> > > For {DEFAULT expression ON EMPTY} | {DEFAULT expression ON ERROR}
> > > restrict DEFAULT expression be either Const
Thank you for looking this!
At Tue, 23 Jan 2024 15:07:10 +0900, Fujii Masao wrote
in
> Regarding the patch, here are the review comments.
>
> +/*
> + * Is current process a wal receiver?
> + */
> +bool
> +IsWalReceiver(void)
> +{
> + return WalRcv != NULL;
> +}
>
> This looks wrong because
Hi Peter,
On Mon, 22 Jan 2024 at 00:38, Peter Smith wrote:
> 2024-01 Commitfest.
>
> Hi, This patch has a CF status of "Ready for Committer", but it is
> currently failing some CFbot tests [1]. Please have a look and post an
> updated version..
>
> ==
> [1]
>
Hi vignesh C
Many thanks, I have marked it to "ready for committer"
Best wish
vignesh C 于2024年1月23日周二 10:56写道：
> On Mon, 22 Jan 2024 at 11:27, wenhui qiu wrote:
> >
> > Hi vignesh CI saw this path has been passed (
> https://cirrus-ci.com/build/6109321080078336),can we push it?
>
>
Hi,
On Tue, Jan 23, 2024 at 02:50:06PM +0900, Michael Paquier wrote:
> On Mon, Jan 22, 2024 at 09:07:45AM +, Bertrand Drouvot wrote:
>
> I've rewritten some of that, and applied the patch down to v16.
Thanks!
> > Yeah, I can clearly see how this patch helps from a theoritical perspective
On Tue, 2024-01-23 at 13:55 +0800, Richard Guo wrote:
> Similar to what we did to GROUP BY keys in 0452b461bc, I think we can do
> the same to DISTINCT keys, i.e. reordering DISTINCT keys to match input
> path's pathkeys, which can help reduce cost by avoiding unnecessary
> re-sort, or allowing us
99 matches
Mail list logo
