At Mon, 25 Dec 2023 15:42:41 +0900, Michael Paquier wrote
in
> On Mon, Dec 25, 2023 at 02:39:16PM +0900, Kyotaro Horiguchi wrote:
> > The attached patch contains both of the above fixes.
>
> Good catches, let's fix them. You have noticed that while translating
> these new messages, I guess?
Y
On 25.12.2023 02:38, Alexander Korotkov wrote:
Pushed!
Thanks a lot!
With the best regards!
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 22.12.2023 14:39, Laurenz Albe wrote:
Yes, that is better - shorter and avoids passive mode. Changed.
Thanks.
Also I don't really like "This is not considered a bug" part, since it
looks like an excuse.
In a way, it is an excuse, so why not be honest about it.
I still think that the "t
Hi PostgreSQL Community,
Recently I have been working on pg_dump regarding my project and wanted to
exclude an extension from the dump generated. I wonder why it doesn't have
--exclude-extension type of support whereas --extension exists!
Since I needed that support, I took the initiative to contri
Added a CF entry for the same https://commitfest.postgresql.org/46/4721/
Regards
Ayush Vatsa
Amazon Web Services (AWS)
On Mon, 25 Dec 2023 at 15:48, Ayush Vatsa wrote:
> Hi PostgreSQL Community,
> Recently I have been working on pg_dump regarding my project and wanted to
> exclude an extension
Hi
On Mon, Dec 25, 2023 at 6:22 PM Ayush Vatsa wrote:
>
> Added a CF entry for the same https://commitfest.postgresql.org/46/4721/
>
> Regards
> Ayush Vatsa
> Amazon Web Services (AWS)
>
> On Mon, 25 Dec 2023 at 15:48, Ayush Vatsa wrote:
>>
>> Hi PostgreSQL Community,
>> Recently I have been wor
On Sat, Dec 23, 2023 at 1:32 AM Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 22/12/2023 17:24, Tom Lane wrote:
> >> How much of your patchset still makes sense if we assume that we
> >> can always extract the ORDER BY column values from the index?
>
> > That would make it much less intere
On Fri, Dec 22, 2023 at 7:24 PM Andrei Lepikhov
wrote:
> On 22/12/2023 11:48, Alexander Korotkov wrote:
> > > Because we must trust all predictions made by the planner, we just
> > > choose the most trustworthy path. According to the planner logic, it is
> > > a path with a smaller selectivity.
Hi,
> long options should not mess with short options, does the following
> make sense to you?
Yes that makes sense, a reason to keep them together is that they are of
the same kind
But I will update the patch accordingly.
One more thing I wanted to ask is, Should I separate them in the
pg_dump.sg
On Mon, Dec 18, 2023 at 3:01 PM Peter Eisentraut
wrote:
> On 11.12.23 13:22, Amul Sul wrote:
> >
> > create table t1 (a int, b int generated always as (a + 1) stored);
> > alter table t1 add column c int, alter column b set expression as (a
> > + c);
> > ERROR: 42703: column "c"
Hi,
Thanks for the review and feedback on your previous reply!
On Mon, 25 Dec 2023 at 09:40, Michael Paquier wrote:
>
> On Mon, Dec 25, 2023 at 03:20:58PM +0900, Michael Paquier wrote:
> > pgstat_tracks_io_bktype() does not look correct to me. Why is the WAL
> > receiver considered as something
Hello!
It seems like the idea of "old" snapshot is still a valid one.
> Should this deal with any potential XID wraparound, too?
As far as I understand in our case, we are not affected by this in any way.
Vacuum in our table is not possible because of locking, so, nothing
may be frozen (see belo
I wrote:
> Probably a better way is to invent a separate header "plpython_system.h"
> that just includes the Python headers, to scope the pragma precisely.
> (I guess it could have the fixup #defines we're wrapping those headers
> in, too.)
> The same idea would work in plperl.
After updating one
Since dc2123400, any "make" in src/bin/pg_combinebackup whines
cat: ./po/LINGUAS: No such file or directory
if you have selected --enable-nls. This is evidently from
AVAIL_LANGUAGES := $(shell cat $(srcdir)/po/LINGUAS)
I don't particularly care to see that warning until whenever
it is that the
Hi, Alexander!
On Mon, 25 Dec 2023 at 02:51, Alexander Korotkov
wrote:
> On Tue, Dec 12, 2023 at 3:22 PM Alexander Korotkov
> wrote:
> >
> > On Mon, Dec 11, 2023 at 6:16 PM Peter Geoghegan wrote:
> > > Will you be in Prague this week? If not this might have to wait.
> >
> > Sorry, I wouldn't b
On Mon, Dec 25, 2023 at 04:09:34PM +0300, Nazir Bilal Yavuz wrote:
> On Wed, 9 Aug 2023 at 21:52, Melanie Plageman
> wrote:
>> If there is any combination of BackendType and IOContext which will
>> always read XLOG_BLCKSZ bytes, we could use XLOG_BLCKSZ for that row's
>> op_bytes. For other cases
On Mon, Dec 25, 2023 at 7:09 AM Tom Lane wrote:
> Coverity whinged this morning about the following bit in
> the new pg_combinebackup code:
>
> 644 unsignedrb;
> 645
> 646 /* Read the block from the correct source, except if
> dry-run. */
> 647
Hi,
I finally had time to look at the last version of the patch, so here's a
couple thoughts and questions in somewhat random order. Please take this
as a bit of a brainstorming and push back if you disagree some of my
comments.
In general, I like the goal of this patch - not having statistics is
On Thu, Dec 21, 2023 at 8:21 PM Bertrand Drouvot
wrote:
>
> On Thu, Dec 21, 2023 at 07:55:51PM +0530, Amit Kapila wrote:
> > On Thu, Dec 21, 2023 at 5:05 PM Andres Freund wrote:
> > > I'm not entirely sure I understand the difference - just whether we add
> > > one
> > > new column or replace th
On Fri, Dec 22, 2023 at 2:38 AM Heikki Linnakangas wrote:
> v1-0004-Omit-columns-from-final-tlist-that-were-only-need.patch
>
> The main patch in this series.
This patch filters out the junk columns created for ORDER BY/GROUP BY,
and retains the junk columns created for RowLocks. I'm afraid th
On 25/12/2023 18:36, Alexander Korotkov wrote:
On Fri, Dec 22, 2023 at 7:24 PM Andrei Lepikhov
wrote:
On 22/12/2023 11:48, Alexander Korotkov wrote:
> Because we must trust all predictions made by the planner, we just
> choose the most trustworthy path. According to the planner logic, it i
On Thu, Dec 21, 2023 at 4:41 PM John Naylor wrote:
>
> On Thu, Dec 21, 2023 at 8:33 AM Masahiko Sawada wrote:
> >
> > I found the following comment and wanted to discuss:
> >
> > // this might be better as "iterate over nodes", plus a callback to
> > RT_DUMP_NODE,
> > // which should really only
22 matches
Mail list logo
