On Mon, Mar 4, 2024 at 2:12 PM Andrey M. Borodin wrote:
>
> > On 12 Jan 2024, at 05:51, jian he wrote:
> >
> > another big difference compare to HEAD:
>
> Hi Jian,
>
> thanks for looking into this. Would you be willing to review the next version
> of the patch?
I just applied
Hi,
On Mon, Mar 04, 2024 at 10:44:34AM +0900, Michael Paquier wrote:
> On Fri, Mar 01, 2024 at 06:52:45AM +, Bertrand Drouvot wrote:
> > + if (defined($backend_type))
> > + {
> > + $backend_type = qq('$backend_type');
> > + $die_message = "the backend type
On Mon, 4 Mar 2024 at 19:20, Andrei Lepikhov wrote:
> Could we use the trick with the get_actual_variable_range() to find some
> reason and extrapolate histogram data out of the boundaries when an
> index shows us that we have min/max outside known statistics?
> Because it would be used for the
> On 17 Feb 2024, at 00:38, Tom Lane wrote:
>
> Here's a rebase over 9f1337639 --- no code changes, but this affects
> some of the new or changed expected outputs from that commit.
Aleksander, as long as your was reviewing this previously, I’ve added you to
reviewers of this CF entry [0].
> On 18 Feb 2024, at 05:29, Tomas Vondra wrote:
>
> I'm not very familiar with date_bin(), but is this issue inherent or
> could we maybe fix date_bin() to handle DST better?
>
> In particular, isn't part of the problem that date_bin() is defined only
> for timestamp and not for timestamptz?
> On 6 Feb 2024, at 11:21, Michael Paquier wrote:
>
> The problem may be actually trickier than that, no? Could there be
> other factors to take into account for their classification, like
> their sizes (typically, we'd want to process the biggest one first, I
> guess)?
Maxim, what do you
On 4/3/2024 12:33, David Rowley wrote:
[1]
https://www.postgresql.org/message-id/CAApHDvo2sMPF9m%3Di%2BYPPUssfTV1GB%3DZ8nMVa%2B9Uq4RZJ8sULeQ%40mail.gmail.com
Thanks for the link!
Could we use the trick with the get_actual_variable_range() to find some
reason and extrapolate histogram data out
> On 14 Jan 2024, at 18:55, John Naylor wrote:
>
> On Sat, Jan 13, 2024 at 9:36 PM Ranier Vilela wrote:
>>
>> Em ter., 9 de jan. de 2024 às 06:31, John Naylor
>> escreveu:
>
>>> This just moves an operation from one place to the other, while
>>> obliterating the explanatory comment, so I
On Mon, Mar 4, 2024 at 1:56 AM Alvaro Herrera wrote:
>
> On 2024-Feb-28, Alvaro Herrera wrote:
>
> > Improve performance of subsystems on top of SLRU
>
> Coverity had the following complaint about this commit:
>
>
> On 12 Jan 2024, at 05:51, jian he wrote:
>
> another big difference compare to HEAD:
Hi Jian,
thanks for looking into this. Would you be willing to review the next version
of the patch?
As long as you are looking into this, you might be interested in registering
yourself in a CF entry
Dear Tom,
Thanks for replying!
> "Hayato Kuroda (Fujitsu)" writes:
> > While reading codes, I found that ApplyLauncherShmemInit() and
> AutoVacuumShmemInit()
> > are always called even if they would not be launched.
> > It may be able to reduce the start time to avoid the unnecessary
On Sun, Mar 3, 2024 at 2:43 PM John Naylor wrote:
>
> On Fri, Mar 1, 2024 at 3:01 PM Masahiko Sawada wrote:
> >
> > On Thu, Feb 29, 2024 at 8:43 PM John Naylor wrote:
>
> > > + ts->rt_context = AllocSetContextCreate(CurrentMemoryContext,
> > > +"tidstore storage",
> > >
> > > "tidstore
> On 23 Jan 2024, at 09:42, Arne Roland wrote:
>
> <0001-fuzzy_underscore_permutation_v5.patch>
Mikhail, there’s a new patch version. May I ask you to review it?
Best regards, Andrey Borodin.
On Fri, Mar 1, 2024 at 11:28 AM Michael Paquier wrote:
> On Mon, Feb 19, 2024 at 12:06:19PM +0530, Amul Sul wrote:
> > Agreed, now they will have an error as _could not read file "":
> Is
> > a directory_. But, IIUC, that what usually happens with the dev version,
> and
> > the extension needs
"Hayato Kuroda (Fujitsu)" writes:
> While reading codes, I found that ApplyLauncherShmemInit() and
> AutoVacuumShmemInit()
> are always called even if they would not be launched.
> It may be able to reduce the start time to avoid the unnecessary allocation.
Why would this be a good idea? It
On Wed, Feb 21, 2024 at 10:01 AM Michael Paquier
wrote:
> On Mon, Feb 19, 2024 at 12:06:19PM +0530, Amul Sul wrote:
> > On Mon, Feb 19, 2024 at 4:22 AM Michael Paquier
> wrote:
> >> And the new option should be documented at the top of the init()
> >> routine for perldoc.
> >
> > Added in the
On Sun, 3 Mar 2024 at 20:08, Andy Fan wrote:
> The issue can be reproduced with the following steps:
>
> create table x_events (.., created_at timestamp, a int, b int);
>
> create index idx_1 on t(created_at, a);
> create index idx_2 on t(created_at, b);
>
> query:
> select * from t where
On Sun, Mar 03, 2024 at 10:57:04AM -0500, Joe Conway wrote:
> New PostgreSQL Contributors:
>
> * Bertrand Drouvot
> * Gabriele Bartolini
> * Richard Guo
>
> New PostgreSQL Major Contributors:
>
> * Alexander Lakhin
> * Daniel Gustafsson
> * Dean Rasheed
> * John Naylor
> * Melanie Plageman
> *
On Mon, Mar 04, 2024 at 05:17:52AM +0100, Jelte Fennema-Nio wrote:
> I noticed this was committed, and took a quick look. It sounds very
> useful for testing Citus to be able to use injection points too, but I
> noticed this code is included in src/test/modules. It sounds like that
> location will
Dear hackers,
While reading codes, I found that ApplyLauncherShmemInit() and
AutoVacuumShmemInit()
are always called even if they would not be launched.
It may be able to reduce the start time to avoid the unnecessary allocation.
However, I know this improvement would be quite small because the
On Sun, Mar 3, 2024 at 9:28 PM Joe Conway wrote:
> All,
>
> The PostgreSQL Contributor Page
> (https://www.postgresql.org/community/contributors/) includes people who
> have made substantial, long-term contributions of time and effort to the
> PostgreSQL project. The PostgreSQL Contributors Team
> On 3 Mar 2024, at 20:57, Joe Conway wrote:
>
> New PostgreSQL Contributors:
>
> * Bertrand Drouvot
> * Gabriele Bartolini
> * Richard Guo
>
> New PostgreSQL Major Contributors:
>
> * Alexander Lakhin
> * Daniel Gustafsson
> * Dean Rasheed
> * John Naylor
> * Melanie Plageman
> * Nathan
> On 4 Mar 2024, at 06:44, Michael Paquier wrote:
> so I have applied it
Great! Thank you! A really useful stuff for an asynchronous testing!
> On 4 Mar 2024, at 09:17, Jelte Fennema-Nio wrote:
>
> this code is included in src/test/modules. It sounds like that
> location will make it
Hi,
In <20240301.154443.618034282613922707@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 01 Mar 2024 15:44:43 +0900 (JST),
Sutou Kouhei wrote:
>> I guess so. It does not make much of a difference, though. The thing
>> is that the
On 3/3/2024 14:01, Andy Fan wrote:
1. We can let the user define the column as the value is increased day by
day. the syntax may be:
ALTER TABLE x_events ALTER COLUMN created_at ALWAYS_INCREASED.
then when a query like 'create_at op const', the statistics module can
treat it as
On Thu, 29 Feb 2024 at 00:29, David Rowley wrote:
> I switched over to working on doing what you did in 0002 for
> generation.c and slab.c.
>
> See the attached patch which runs the same test as in [1] (aset.c is
> just there for comparisons between slab and generation)
>
> The attached includes
On 1/3/2024 22:33, Alexander Korotkov wrote:
I'm going to review and revise the patch.
Nice!
One question I have yet.
> /*
> * Transformation only works with both side type is not
> * { array | composite | domain | record }.
Why do we limit transformation for these
I noticed this was committed, and took a quick look. It sounds very
useful for testing Citus to be able to use injection points too, but I
noticed this code is included in src/test/modules. It sounds like that
location will make it somewhat hard to install. If that's indeed the
case, would it be
On Mon, Mar 4, 2024 at 2:38 PM Amit Kapila wrote:
>
> On Mon, Mar 4, 2024 at 6:57 AM Peter Smith wrote:
> >
> > On Sun, Mar 3, 2024 at 2:56 PM Amit Kapila wrote:
> > >
> > > On Sun, Mar 3, 2024 at 5:17 AM Peter Smith wrote:
> > > >
> > ...
> > > > 9. NeedToWaitForWal
> > > >
> > > > + /*
> > >
On Mon, Mar 4, 2024 at 2:49 PM Amit Kapila wrote:
>
> On Mon, Mar 4, 2024 at 7:25 AM Peter Smith wrote:
> >
> >
> > ==
> > doc/src/sgml/config.sgml
> >
> > 2.
> > +pg_logical_slot_peek_changes,
> > +when used with failover enabled logical slots, will block until all
> > +
On Mon, Mar 4, 2024 at 7:25 AM Peter Smith wrote:
>
>
> ==
> doc/src/sgml/config.sgml
>
> 2.
> +pg_logical_slot_peek_changes,
> +when used with failover enabled logical slots, will block until all
> +physical slots specified in standby_slot_names
> have
> +
On Mon, Mar 4, 2024 at 6:57 AM Peter Smith wrote:
>
> On Sun, Mar 3, 2024 at 2:56 PM Amit Kapila wrote:
> >
> > On Sun, Mar 3, 2024 at 5:17 AM Peter Smith wrote:
> > >
> ...
> > > 9. NeedToWaitForWal
> > >
> > > + /*
> > > + * Check if the standby slots have caught up to the flushed position.
On Sun, Mar 3, 2024 at 9:28 PM Joe Conway wrote:
>
> The PostgreSQL Contributor Page
> (https://www.postgresql.org/community/contributors/) includes people who
> have made substantial, long-term contributions of time and effort to the
> PostgreSQL project. The PostgreSQL Contributors Team
On Mon, 4 Sep 2023 16:48:02 +0800
jian he wrote:
> other ideas based on v29.
>
> src/include/utils/rel.h
> 680: #define RelationIsIVM(relation) ((relation)->rd_rel->relisivm)
> I guess it would be better to add some comments to address the usage.
> Since all peer macros all have some comments.
On Fri, 1 Sep 2023 15:42:17 +0800
jian he wrote:
I apologize for this late reply.
> I added a new function append_update_set_caluse, and deleted
> functions: {append_set_clause_for_count, append_set_clause_for_sum,
> append_set_clause_for_avg, append_set_clause_for_minmax}
>
> I guess this
HI Richard
Now it is starting the last commitfest for v17, can you respond to
Alena Rybakina points?
Regards
On Thu, 8 Feb 2024 at 13:50, wenhui qiu wrote:
> Hi Alena Rybakina
> I saw this code snippet also disable mergejoin ,I think it same effect
> + /*
> + * For now we do not
On Thu, Feb 29, 2024 at 4:59 PM Andrei Lepikhov
wrote:
>
> On 28/2/2024 17:27, Alena Rybakina wrote:
> > Maybe like that:
> >
> > It also considers the way to generate a path using BitmapScan indexes,
> > converting the transformed expression into expressions separated by "OR"
> > operations, and
On Sun, Mar 3, 2024 at 6:51 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Sunday, March 3, 2024 7:47 AM Peter Smith wrote:
> >
> > 3.
> > +
> > +
> > + Value * is not accepted as it is inappropriate
> > to
> > + block logical replication for physical slots that either
On Tue, 20 Feb 2024 at 15:38, David Rowley wrote:
> While working on 4c2369ac5, I noticed there's close to as much code to
> disallow BooleanTests in the form of "IS UNKNOWN" and "IS NOT UNKNOWN"
> in partition pruning as it would take to allow pruning to work for
> these.
I looked at this again
On Fri, Mar 01, 2024 at 06:52:45AM +, Bertrand Drouvot wrote:
> + if (defined($backend_type))
> + {
> + $backend_type = qq('$backend_type');
> + $die_message = "the backend type $backend_type";
> + }
> + else
> + {
> + $backend_type =
Tomas Vondra writes:
> On 3/3/24 07:10, Andy Fan wrote:
>>
>> Hi,
>>
>> Here is a updated version, the main changes are:
>>
>> 1. an shared_detoast_datum.org file which shows the latest desgin and
>> pending items during discussion.
>> 2. I removed the slot->pre_detoast_attrs totally.
>>
On Sun, Mar 03, 2024 at 03:44:34PM -0600, Nathan Bossart wrote:
> On Sun, Mar 03, 2024 at 11:40:00PM +0530, Bharath Rupireddy wrote:
>> Do you have any thoughts on reverting 007693f and introducing
>> invalidation_reason?
>
> Unless I am misinterpreting some details, ISTM we could rename this
Tomas Vondra writes:
> On 2/26/24 16:29, Andy Fan wrote:
>>
>> ...>
>> I can understand the benefits of the TOAST cache, but the following
>> issues looks not good to me IIUC:
>>
>> 1). we can't put the result to tts_values[*] since without the planner
>> decision, we don't know if this will
On Fri, Mar 1, 2024 at 5:26 PM Peter Eisentraut wrote:
>
> Oops, there was a second commit in my branch that I neglected to send
> in. Here is my complete patch set.
there is a `OCLASS` at the end of getObjectIdentityParts.
there is a `ObjectClass` in typedefs.list
On Sun, Mar 3, 2024 at 2:56 PM Amit Kapila wrote:
>
> On Sun, Mar 3, 2024 at 5:17 AM Peter Smith wrote:
> >
...
> > 9. NeedToWaitForWal
> >
> > + /*
> > + * Check if the standby slots have caught up to the flushed position. It
> > + * is good to wait up to flushed position and then let it send
Tomas Vondra writes:
> On 3/3/24 02:52, Andy Fan wrote:
>>
>> Hi Nikita,
>>
>>>
>>> Have you considered another one - to alter pg_detoast_datum
>>> (actually, it would be detoast_attr function) and save
>>> detoasted datums in the detoast context derived
>>> from the query context?
>>>
>>>
Daniel Gustafsson writes:
> I took the liberty to add this to the upcoming CF to make sure we don't lose
> track of it.
Thanks for doing that, because the cfbot pointed out a problem:
I should have written pg_strncasecmp not strncasecmp. If this
version tests cleanly, I'll push it.
On Mon, Feb 26, 2024 at 08:24:04AM +, Bertrand Drouvot wrote:
> I'll try to submit the POC patch in [1] before beginning of next week now that
> we're "just waiting" if there is more comments on this current thread.
I'll look at what you have there in more details.
> [1]:
>
On Fri, Mar 01, 2024 at 06:30:10AM +0100, Jelte Fennema-Nio wrote:
> On Fri, 1 Mar 2024 at 06:08, Michael Paquier wrote:
>> Mostly OK to me. Just note that this comment is incorrect because
>> pg_enc2gettext_tbl[] includes elements in the range
>> [PG_SJIS,_PG_LAST_ENCODING_[ ;)
>
> fixed
On Fri, Mar 1, 2024 at 10:22 AM Michael Paquier wrote:
>
> > Nice catch. When COPY_ON_ERROR_STOP is specified, we use ereport's
> > soft error mechanism. An assertion seems a good choice to validate the
> > state is what we expect. Done that way.
>
> Hmm. I am not really on board with this
On Sun, Mar 03, 2024 at 11:40:00PM +0530, Bharath Rupireddy wrote:
> On Sat, Mar 2, 2024 at 3:41 AM Nathan Bossart
> wrote:
>> Would you ever see "conflict" as false and "invalidation_reason" as
>> non-null for a logical slot?
>
> No. Because both conflict and invalidation_reason are decided
Alvaro Herrera writes:
> And I think it's correct that this is somewhat bogus, or at least
> confusing: the only way to have control back here on line 1371 after
> having executed once is via the "goto retry" line below; and there we
> release "prevlock" and set it to NULL beforehand, so it's
On 3/3/24 07:10, Andy Fan wrote:
>
> Hi,
>
> Here is a updated version, the main changes are:
>
> 1. an shared_detoast_datum.org file which shows the latest desgin and
> pending items during discussion.
> 2. I removed the slot->pre_detoast_attrs totally.
> 3. handle some pg_detoast_datum_slice
On 2/26/24 16:29, Andy Fan wrote:
>
> ...>
> I can understand the benefits of the TOAST cache, but the following
> issues looks not good to me IIUC:
>
> 1). we can't put the result to tts_values[*] since without the planner
> decision, we don't know if this will break small_tlist logic. But
On 2024-Feb-28, Alvaro Herrera wrote:
> Improve performance of subsystems on top of SLRU
Coverity had the following complaint about this commit:
*** CID NNN: Control flow issues
On 2024-Feb-29, Alvaro Herrera wrote:
> On 2024-Feb-29, Kyotaro Horiguchi wrote:
> > Some of them, commit_timestamp_buffers, transaction_buffers,
> > subtransaction_buffers use 0 to mean auto-tuning based on
> > shared-buffer size. I think it's worth adding an extra_desc such as "0
> > to
On 3/3/24 02:52, Andy Fan wrote:
>
> Hi Nikita,
>
>>
>> Have you considered another one - to alter pg_detoast_datum
>> (actually, it would be detoast_attr function) and save
>> detoasted datums in the detoast context derived
>> from the query context?
>>
>> We have just enough information at
On Sat, Mar 2, 2024 at 3:41 AM Nathan Bossart wrote:
>
> > [] how about we revert
> > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=007693f2a3ac2ac19affcb03ad43cdb36ccff5b5,
>
> Would you ever see "conflict" as false and "invalidation_reason" as
> non-null for a logical
On 22/02/2024 02:37, Heikki Linnakangas wrote:
On 15/02/2024 07:09, Robert Haas wrote:
On Thu, Feb 15, 2024 at 3:07 AM Andres Freund wrote:
I think the last remaining question here is about the 0- vs 1-based indexing
of BackendIds. Is it a good idea to switch to 0-based indexing? And if we do
On Sun, 3 Mar 2024 at 15:27, Jelte Fennema-Nio wrote:
> + case EOF:
> + /* We'll come back when there is more data */
> + return PGRES_POLLING_READING;
>
> Nice catch, I'll go steal this for my patchset which adds all the
> necessary changes to be able to do a protocol bump[1].
Actually, it
All,
The PostgreSQL Contributor Page
(https://www.postgresql.org/community/contributors/) includes people who
have made substantial, long-term contributions of time and effort to the
PostgreSQL project. The PostgreSQL Contributors Team recognizes the
following people for their contributions.
On 2024-03-03 03:00 +0100, Steve Chavez wrote:
> psql has the :{?name} syntax for testing a psql variable existence.
>
> But currently doing \echo :{?VERB doesn't trigger tab completion.
>
> This patch fixes it. I've also included a TAP test.
Thanks. The code looks good, all tests pass, and
On Fri, 1 Mar 2024 at 06:19, Jelte Fennema-Nio wrote:
> This is a preliminary review. I'll look at this more closely soon.
Some more thoughts after looking some more at the proposed changes
+#define EXTENDED_CANCEL_REQUEST_CODE PG_PROTOCOL(1234,5677)
nit: I think the code should be 1234,5679
On Mon, Nov 27, 2023 at 10:18 PM Mark Dilger
wrote:
>
> > On Nov 25, 2023, at 9:47 AM, Alexander Korotkov
> > wrote:
> >
> >> Should the patch at least document which parts of the EState are expected
> >> to be in which states, and which parts should be viewed as undefined? If
> >> the
Hi, Matthias!
On Fri, Nov 24, 2023 at 1:07 AM Matthias van de Meent
wrote:
> On Thu, 23 Nov 2023 at 13:43, Alexander Korotkov wrote:
> >
> > Hello PostgreSQL Hackers,
> >
> > I am pleased to submit a series of patches related to the Table Access
> > Method (AM) interface, which I initially
On 29.02.24 19:14, Tom Lane wrote:
Peter Eisentraut writes:
In nodes/parsenodes.h, it says both
This *must* be false for RTEs other than RTE_RELATION entries.
Well, that's true in the parser ...
and also puts it under
Fields valid in all RTEs:
which are both wrong on opposite
Sorry, I found explanation -
https://www.postgresql.org/message-id/CACJufxFS-xcjaWq2Du2OyJUjRAyqCk12Q_zGOPxv61sgrdpw9w%40mail.gmail.com
On 03.03.2024 12:26, Alena Rybakina wrote:
I found that it was mentioned here -
I found that it was mentioned here -
https://www.postgresql.org/message-id/CACJufxFrZS07oBHMk1_c8P3A84VZ3ysXiZV8NeU6gAnvu%2BHsVA%40mail.gmail.com.
To be honest, I couldn't find any explanation for that.
On 01.03.2024 18:33, Alexander Korotkov wrote:
Hi, Andrei,
Hi, Alena!
On Thu, Feb 29,
68 matches
Mail list logo
