Dear Shveta,
> PFA v25 patch set. The changes are:
Thanks for making the patch! It seems that there are lots of comments, so
I can put some high-level comments for 0001.
Sorry if there are duplicated comments.
1.
The patch seemed not to consider the case that failover option between
replication
Hi All,
We observed the behavioral difference when query(with custom GUC) using
the PARALLEL plan vs the Non-PARALLEL plan.
Consider the below test:
I understand the given testcase doesn't make much sense, but this is the
simplest
version of the test - to demonstrate the problem.
create table p
On Wed, 25 Oct, 2023 at 10:43:25 -0500, Nathan Bossart wrote:
>+pg_crc32c
>+pg_comp_crc32c_with_vmull_armv8(pg_crc32c crc, const void *data, size_t len)
>It looks like most of this function is duplicated from
>pg_comp_crc32c_armv8(). I understand that we probably need a separate
>function becau
On Wed, Oct 25, 2023 at 10:06:23PM -0700, Jeff Davis wrote:
> Thank you for the report! I was able to reproduce and observe that the
> buffer is not marked dirty.
>
> The call (hashovfl.c:671):
>
> XLogRegisterBuffer(1, wbuf, REGBUF_STANDARD)
>
> is followed unconditionally by:
>
> PageSetL
On Fri, Sep 29, 2023 at 05:32:52PM +0530, Amit Kapila wrote:
> Such a use case is possible to achieve even without this patch.
> Sawada-San has already given an alternative to slightly tweak the
> steps mentioned by Julien to achieve it. Also, there are other ways to
> achieve it by slightly changi
On Thu, 26 Oct 2023 at 03:31, Daniele Varrazzo
wrote:
> The goal here was only non-blocking name resolution. Ahaini understand we
> should do is to split on the hosts for sync connections too, shuffle if
> requested, and make separate connection attempts.
If you pack the resolved addresses in
Hi,
On 3/27/23 8:35 AM, Michael Paquier wrote:
On Fri, Mar 24, 2023 at 08:00:44PM -0700, Andres Freund wrote:
I don't understand what we're optimizing for here. These functions are very
very very far from being a hot path. The xact functions are barely ever
used. Compared to the cost of query e
Hi,
On Wed, Oct 25, 2023 at 04:36:41PM +0200, Peter Eisentraut wrote:
> On 19.10.23 11:39, Michael Banck wrote:
> > Hi,
> >
> > I believed that spread (not fast) checkpoints are the default in
> > pg_basebackup, but noticed that --help does not specify which is which -
> > contrary to the referen
On Thursday, October 26, 2023 12:42 PM Amit Kapila
wrote:
>
> On Tue, Oct 24, 2023 at 5:27 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > While reviewing the test_decoding code, I noticed that when
> > skip_empty_xacts option is specified, it doesn't open the streaming
> block( e.g.
> > pg_output_str
On Wed, Oct 25, 2023 at 8:49 PM Drouvot, Bertrand
wrote:
>
> On 10/9/23 12:30 PM, shveta malik wrote:
> > PFA v22 patch-set. It has below changes:
> >
> > patch 001:
> > 1) Now physical walsender wakes up logical walsender(s) by using a new
> > CV as suggested in [1]
>
> Thanks!
>
> I think that w
On 25/10/2023 20:00, Andrei Zubkov wrote:
Hi Andrei,
On Wed, 2023-10-25 at 13:59 +0700, Andrei Lepikhov wrote:
But minmax_stats_since and changes in the UI of the reset routine
look like syntactic sugar here.
I can't convince myself that it is really needed. Do you have some
set of cases that c
On Tue, 24 Oct, 2023 20:45:39PM -0500, Nathan Bossart wrote:
>I tried this. pg_waldump on 2 million ~8kB records took around 8.1 seconds
>without the patch and around 7.4 seconds with it (an 8% improvement).
>pg_waldump on 1 million ~16kB records took around 3.2 seconds without the
>patch and a
On Thu, Oct 26, 2023 at 2:23 PM Xiang Gao wrote:
>
> On Tue, 24 Oct, 2023 20:45:39PM -0500, Nathan Bossart wrote:
> >I tried this. pg_waldump on 2 million ~8kB records took around 8.1 seconds
> >without the patch and around 7.4 seconds with it (an 8% improvement).
> >pg_waldump on 1 million ~1
> ALTER TABLE ADD CONSTRAINT would certainly have taken
> AccessExclusiveLock on the "example" table, which should be sufficient
> to prevent anything else from touching its pg_class row. The only
> mechanism I can think of that might bypass that is a manual UPDATE on
> pg_class, which would just
On Thu, 2023-10-26 at 15:49 +0700, Andrei Lepikhov wrote:
> It is the gist of my question. If needed, You can remove the record
> by
> (userid, dbOid, queryId). As I understand, this extension is usually
> used by an administrator. Who can reset these parameters except you
> and
> the DBMS?
This
On 2023-10-25 We 15:19, Robert Haas wrote:
On Wed, Oct 25, 2023 at 3:17 PM Andrew Dunstan wrote:
OK, I'll go with that. It will actually be a bit less invasive than the
patch I posted.
Why's that?
Because we won't be removing the RD parser.
cheers
andrew
--
Andrew Dunstan
EDB: https:
On 23.10.23 22:34, Nathan Bossart wrote:
On Mon, Oct 23, 2023 at 05:55:32PM +0800, Junwang Zhao wrote:
On Mon, Oct 23, 2023 at 2:37 PM Peter Eisentraut wrote:
Since C99, there can be a trailing comma after the last value in an enum
C99 allows us to do this doesn't mean we must do this, this
Hi,
Aleksander, previous discussion was not a discussion actually, we proposed
a set of big and complex core changes without any discussion preceding it.
That was not very good approach although the overall idea behind the patch
set is very progressive and is ready to solve some old and painful is
On Mon, Oct 23, 2023 at 9:34 AM Euler Taveira wrote:
>
> It is still a WIP but I would like to share it and get some feedback.
>
>
I have started reviewing the patch. I have just read through all the
code. It's well documented and clear. Next I will review the design in
detail. Here are a couple
Hi,
> Aleksander, previous discussion was not a discussion actually, we proposed
> a set of big and complex core changes without any discussion preceding it.
> That was not very good approach although the overall idea behind the patch
> set is very progressive and is ready to solve some old and pa
Hi,
On 10/26/23 10:40 AM, Amit Kapila wrote:
On Wed, Oct 25, 2023 at 8:49 PM Drouvot, Bertrand
wrote:
Good point, I think we should enhance the WalSndWait() logic to
address this case.
Agree. I think it would need to take care of the new CV and probably
provide a way for the caller to de
On Thu, Oct 26, 2023 at 5:38 PM Drouvot, Bertrand
wrote:
>
> On 10/26/23 10:40 AM, Amit Kapila wrote:
> > On Wed, Oct 25, 2023 at 8:49 PM Drouvot, Bertrand
> > wrote:
> >>
> >
> > Good point, I think we should enhance the WalSndWait() logic to
> > address this case.
>
> Agree. I think it would ne
Hi,
The main goal was to correctly process invalid queries (as in examples
above).
I'm not sure this could be done in type input functions. I thought that some
coercions could be checked before evaluating expressions for saving reasons.
--
Regards,
Nikita Malakhov
Postgres Professional
The Russia
On Thu, Oct 26, 2023 at 12:38 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > PFA v25 patch set. The changes are:
>
> Thanks for making the patch! It seems that there are lots of comments, so
> I can put some high-level comments for 0001.
> Sorry if there are duplicated comments.
>
> 1.
> The patch seemed
Hi,
On Thu, Oct 26, 2023 at 9:20 PM Nikita Malakhov wrote:
>
> Hi,
>
> The main goal was to correctly process invalid queries (as in examples above).
> I'm not sure this could be done in type input functions. I thought that some
> coercions could be checked before evaluating expressions for savin
Hi,
I meant discussion preceding the patch set - there was no any.
And the goal of *THIS* topic is to gather a picture on how the community
sees
improvements in TOAST mechanics if it doesn't want it the way we proposed
before, to understand which way to go with JSON advanced storage and other
enh
Hi,
> And the goal of *THIS* topic is to gather a picture on how the community sees
> improvements in TOAST mechanics if it doesn't want it the way we proposed
> before, to understand which way to go with JSON advanced storage and other
> enhancements we already have. Previous topic was not of any
Hi,
Agreed on the latter, that must not be the part of it for sure.
Would think on how to make this part correct.
--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
On Thu, Oct 26, 2023 at 6:59 AM Andrew Dunstan wrote:
> Because we won't be removing the RD parser.
Ah, OK.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, 24 Oct 2023 at 22:38, Nikita Malakhov wrote:
>
> Hi hackers!
>
> We need community feedback on previously discussed topic [1].
> There are some long-live issues in Postgres related to the TOAST mechanics,
> like [2].
> Some time ago we already proposed a set of patches with an API allowin
On Thu, Oct 26, 2023 at 3:31 AM Michael Paquier wrote:
> Hmm. Looking at hash_xlog_squeeze_page(), it looks like wbuf is
> expected to always be registered. So, you're right here: it should be
> OK to be less aggressive with setting the page LSN on wbuf if ntups is
> 0, but there's more to it?
On Thu, 26 Oct 2023 at 15:18, Aleksander Alekseev
wrote:
>
> Hi,
>
> > And the goal of *THIS* topic is to gather a picture on how the community
> > sees
> > improvements in TOAST mechanics if it doesn't want it the way we proposed
> > before, to understand which way to go with JSON advanced stora
Hi,
On Thu, 2023-10-19 at 08:13 +1300, Thomas Munro wrote:
> If we used Debian as a yardstick, PostgreSQL 17 wouldn't need anything
> older than LLVM 14 AFAICS. Who else do we need to ask?
LLVM 15 is the minimum one for the platforms that I build the packages
on. So LLVM >= 14 is great for HEAD
Hi,
The BF animal fairywren[1] failed when testing
003_upgrade_logical_replication_slots.pl.
From the log, I can see pg_upgrade failed to open the
invalid_logical_replication_slots.txt:
# Checking for valid logical replication slots
# could not open file
"C:/tools/nmsys64/hom
On 25.10.23 20:32, Jeff Davis wrote:
But what should the result of UPPER('á' COLLATE UCS_BASIC) be? In
Postgres, the answer is 'á', but intuitively, one could reasonably
expect the answer to be 'Á'.
I think that's right. But what would you put into ctype to make that
happen?
That seems to
Keeping things up to date. Here is a rebased patch with no changes from
previous one.
* John Morris
atomic-lsn.patch
Description: atomic-lsn.patch
On Thu, Oct 26, 2023 at 8:11 PM Zhijie Hou (Fujitsu)
wrote:
>
> The BF animal fairywren[1] failed when testing
> 003_upgrade_logical_replication_slots.pl.
>
> From the log, I can see pg_upgrade failed to open the
> invalid_logical_replication_slots.txt:
>
> # Checking for valid logical replication
Hi,
I've seen situations a few times now where somebody has sessions that
are "idle in transaction" for a long time but they feel like it should
be harmless because the transaction has no XID. However, the fact that
the transaction is idle doesn't mean it isn't running a query, because
there could
On Thu, 2023-10-26 at 16:49 +0200, Peter Eisentraut wrote:
> On 25.10.23 20:32, Jeff Davis wrote:
> > But what should the result of UPPER('á' COLLATE UCS_BASIC) be? In
> > Postgres, the answer is 'á', but intuitively, one could reasonably
> > expect the answer to be 'Á'.
>
> I think that's right.
On Thu, Oct 26, 2023 at 07:28:35AM +, Xiang Gao wrote:
> On Wed, 25 Oct, 2023 at 10:43:25 -0500, Nathan Bossart wrote:
>>+# Use ARM VMULL if available and ARM CRC32C intrinsic is avaliable too.
>>+if test x"$USE_ARMV8_VMULL" = x"" && (test x"$USE_ARMV8_CRC32C" = x"1" ||
>>test x"$USE_ARMV8_
On Thu, Oct 26, 2023 at 7:30 AM Michael Paquier wrote:
>
> I was looking at this patch, and got a few comments.
Thanks.
> The view for the bgwriter does not do that. I'd suggest to use
> functions that are named as pg_stat_get_checkpoint_$att with shorter
> $atts. It is true that "timed" is a
Hi,
On 2023-10-26 11:47:32 -0400, Robert Haas wrote:
> I've seen situations a few times now where somebody has sessions that
> are "idle in transaction" for a long time but they feel like it should
> be harmless because the transaction has no XID. However, the fact that
> the transaction is idle d
On Thu, 2023-10-26 at 09:21 -0700, Jeff Davis wrote:
> Our initcap() is not defined in the standard, and we document that it
> only differentiates between alphanumeric and non-alphanumeric
> characters, so we could get that behavior pretty easily as well. If
> we
> wanted to do it the Unicode way i
On Thu, Oct 26, 2023 at 11:11:09AM +,
fujii.y...@df.mitsubishielectric.co.jp wrote:
> >and checks if the remote server version is older than the local
> > server version.
> >If so,
> >postgres_fdw
> > -->assumes that for each built-in aggregate function, the partia
Hi! Thank you for your feedback!
On 25.10.2023 22:54, Robert Haas wrote:
On Sat, Oct 14, 2023 at 6:37 PM Alexander Korotkov wrote:
Regarding the GUC parameter, I don't see we need a limit. It's not
yet clear whether a small number or a large number of OR clauses are
more favorable for transfo
On Thu, Oct 26, 2023 at 1:41 PM Andres Freund wrote:
> Does it really matter on that level for the user whether a snapshot exists
> because of repeatable read or because of a cursor? If users don't understand
> backend_xmin - likely largely true - then the consequences of holding a
> snapshot ope
On Thu, Oct 26, 2023 at 3:47 PM Alena Rybakina
wrote:
> With small amounts of "OR" elements, the cost of orexpr is lower than with
> "ANY", on the contrary, higher.
Alexander's example seems to show that it's not that simple. If I'm
reading his example correctly, with things like aid = 1, the
tr
On Thu, Oct 26, 2023 at 08:53:31AM +, Xiang Gao wrote:
> On Tue, 24 Oct, 2023 20:45:39PM -0500, Nathan Bossart wrote:
>>I tried this. pg_waldump on 2 million ~8kB records took around 8.1 seconds
>>without the patch and around 7.4 seconds with it (an 8% improvement).
>>pg_waldump on 1 millio
On Thu, Oct 26, 2023 at 03:00:58PM +, John Morris wrote:
> Keeping things up to date. Here is a rebased patch with no changes from
> previous one.
This patch looks a little different than the last version I see posted [0].
That last version of the patch (which appears to be just about commit
On 26.10.2023 22:58, Robert Haas wrote:
On Thu, Oct 26, 2023 at 3:47 PM Alena Rybakina
wrote:
With small amounts of "OR" elements, the cost of orexpr is lower than with
"ANY", on the contrary, higher.
Alexander's example seems to show that it's not that simple. If I'm
reading his example corr
In bug #18163 [1], Alexander proved the misgivings I had in [2]
about catcache detoasting being possibly unsafe:
>> BTW, while nosing around I found what seems like a very nasty related
>> bug. Suppose that a catalog tuple being loaded into syscache contains
>> some toasted fields. CatalogCacheC
Hi!
Matthias, thank you for your patience and explanation. I'd wish I had it
much earlier, it would save a lot of time.
You've asked a lot of good questions, and the answers we have for some
seem to be not very satisfactory, and pointed out some topics that were not
mentioned before. I have to ret
Hackers,
This was originally proposed in [1] but that thread went through a
number of different proposals so it seems better to start anew.
The basic idea here is to simplify and harden recovery by getting rid of
backup_label and storing recovery information directly in pg_control.
Instead o
On Thu, Oct 26, 2023 at 12:59 PM Robert Haas wrote:
> Alexander's example seems to show that it's not that simple. If I'm
> reading his example correctly, with things like aid = 1, the
> transformation usually wins even if the number of things in the OR
> expression is large, but with things like
On 25.10.2023 18:35, Andrei Zubkov wrote:
Hi Alena,
On Wed, 2023-10-25 at 16:25 +0300, Alena Rybakina wrote:
Hi! Thank you for your work on the subject.
1. I didn't understand why we first try to find pgssEntry with a
false top_level value, and later find it with a true top_level value.
In c
Peter Eisentraut wrote:
> > That seems to suggest the standard answer should be 'Á' regardless of
> > any COLLATE clause (though I could be misreading). I'm a bit confused
> > by that... what's the standard-compatible way to specify the locale for
> > UPPER()/LOWER()? If there is none, the
On Thu, Oct 26, 2023 at 2:02 PM David Steele wrote:
> Hackers,
>
> This was originally proposed in [1] but that thread went through a
> number of different proposals so it seems better to start anew.
>
> The basic idea here is to simplify and harden recovery by getting rid of
> backup_label and s
On Fri, Aug 18, 2023 at 02:44:31PM -0700, Jeff Davis wrote:
> +SET search_path = admin, "!pg_temp";
I think it's unfortunate that these new identifiers must be quoted. I
wonder if we could call these something like "no_pg_temp". *shrug*
> + * Add any implicitly-searched namespaces to t
"Daniel Verite" writes:
> To me the question of what we should put in pg_collation.collctype
> for the "ucs_basic" collation leads to another question which is:
> why do we even consider collctype in the first place?
For starters, C locale should certainly act different from others.
I'm not sold
On Thu, 26 Oct 2023 at 17:00, David Rowley wrote:
> Thanks for looking at this again. I fixed up each of those and pushed
> the result, mentioning the incompatibility in the commit message.
>
> Now that that's done, I've attached a patch which makes use of the new
> initReadOnlyStringInfo initiali
On Wed, Oct 25, 2023 at 10:34:10PM -0700, David G. Johnston wrote:
> I would reword the existing note to be something like:
>
> The SQL Standard defines specific aggregates and their properties, including
> which of DISTINCT and/or ORDER BY is allowed. Due to the extensible nature of
> PostgreSQL
On Fri, Oct 27, 2023 at 2:26 AM Bharath Rupireddy
wrote:
>
> On Thu, Oct 26, 2023 at 8:11 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > The BF animal fairywren[1] failed when testing
> > 003_upgrade_logical_replication_slots.pl.
> >
> > From the log, I can see pg_upgrade failed to open the
> > invalid
On Thu, Oct 26, 2023 at 2:56 PM Bruce Momjian wrote:
> On Wed, Oct 25, 2023 at 10:34:10PM -0700, David G. Johnston wrote:
> > I would reword the existing note to be something like:
> >
> > The SQL Standard defines specific aggregates and their properties,
> including
> > which of DISTINCT and/or
On Wed, Oct 25, 2023 at 5:45 AM Jeff Davis wrote:
>
> Comments:
Thanks for reviewing.
> * It would be good to document that this is partially an optimization
> (read from memory first) and partially an API difference that allows
> reading unflushed data. For instance, walsender may benefit
> per
On Thu, Oct 26, 2023 at 03:09:26PM -0700, David G. Johnston wrote:
> On Thu, Oct 26, 2023 at 2:56 PM Bruce Momjian wrote:
>
> On Wed, Oct 25, 2023 at 10:34:10PM -0700, David G. Johnston wrote:
> > I would reword the existing note to be something like:
> >
> > The SQL Standard defi
On Thu, Oct 26, 2023 at 3:36 PM Bruce Momjian wrote:
> No sneaking. ;-) It would be bad to document this unevenly because it
> sets expectations in other parts of the system if we don't mention it.
>
Agreed.
Last suggestion, remove the first jsonb_agg example that lacks an order by.
+WITH va
On Thu, 2023-10-26 at 23:22 +0200, Daniel Verite wrote:
> Neither does Unicode, which is why the ICU functions like u_isupper()
> or u_toupper() don't take a locale argument.
u_strToUpper() accepts a locale argument:
https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/ustring_8h.html#aa64fbd4a
On Wed, Nov 23, 2022 at 02:33:27PM -0600, Justin Pryzby wrote:
> On Wed, Nov 23, 2022 at 12:35:59PM -0700, David G. Johnston wrote:
> > On Wed, Nov 23, 2022 at 11:47 AM Tom Lane wrote:
> >
> > > Bruce Momjian writes:
> > > > Does this come up enough to document it? I assume the error message th
Bruce Momjian writes:
> Here is a patch to add this.
"function arguments" seems like a completely wrong description
(and if we do want to document that limit, it's 100).
"query parameters" would work, perhaps.
regards, tom lane
On Thu, Oct 26, 2023 at 3:51 PM Bruce Momjian wrote:
> On Wed, Nov 23, 2022 at 02:33:27PM -0600, Justin Pryzby wrote:
> > On Wed, Nov 23, 2022 at 12:35:59PM -0700, David G. Johnston wrote:
> > > On Wed, Nov 23, 2022 at 11:47 AM Tom Lane wrote:
> > >
> > > > Bruce Momjian writes:
> > > > > Does
On Thu, Oct 26, 2023 at 06:56:40PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Here is a patch to add this.
>
> "function arguments" seems like a completely wrong description
> (and if we do want to document that limit, it's 100).
>
> "query parameters" would work, perhaps.
Ah, I was con
On Thu, Oct 26, 2023 at 03:44:14PM -0700, David G. Johnston wrote:
> On Thu, Oct 26, 2023 at 3:36 PM Bruce Momjian wrote:
>
> No sneaking. ;-) It would be bad to document this unevenly because it
> sets expectations in other parts of the system if we don't mention it.
>
>
> Agreed.
>
On Thu, Oct 26, 2023 at 4:03 PM Bruce Momjian wrote:
>
> Sure, done in the attached patch.
>
>
WFM. Thank You!
David J.
Bruce Momjian writes:
> Ah, I was confused. I documented both in the attached patch.
The function one should have the same annotation as some others:
can be increased by recompiling
PostgreSQL
regards, tom lane
On Thu, Oct 26, 2023 at 4:08 PM Tom Lane wrote:
> Bruce Momjian writes:
> > Ah, I was confused. I documented both in the attached patch.
>
> The function one should have the same annotation as some others:
>
> can be increased by recompiling
> PostgreSQL
>
>
I'd like to see a comment on th
On Thu, Oct 26, 2023 at 4:13 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Thu, Oct 26, 2023 at 4:08 PM Tom Lane wrote:
>
>> Bruce Momjian writes:
>> > Ah, I was confused. I documented both in the attached patch.
>>
>> The function one should have the same annotation as some ot
"David G. Johnston" writes:
> Cleanups for consistency:
> Move "identifier length" after "partition keys" (before the new "function
> arguments")
Yeah, the existing ordering of this table seems quite random.
That would help some, by separating items having to do with
database/table size from SQL
On Thu, 2023-10-26 at 17:32 -0400, Tom Lane wrote:
> For starters, C locale should certainly act different from others.
Agreed. ctype of "C" is 100% stable (as implemented in Postgres with
special ASCII-only semantics) and simple.
I'm looking for a way to offer a new middle ground between plain "
On Thu, Oct 26, 2023 at 09:40:09AM -0400, Robert Haas wrote:
> Because of this, it is possible for bucketbuf, prevbuf, and wbuf to be
> the same (your first scenario) but the second scenario you mention
> (nextbuf == wbuf) should be impossible.
Okay..
> It seems to me that maybe we shouldn't eve
On Thu, Oct 26, 2023 at 10:55:00PM +0530, Bharath Rupireddy wrote:
> On Thu, Oct 26, 2023 at 7:30 AM Michael Paquier wrote:
>> Why is that in 0002? Isn't that something we should treat as a bug
>> fix of its own, even backpatching it to make sure that the flush
>> requests for individual commit_t
On Fri, Oct 27, 2023 at 3:28 AM Peter Smith wrote:
>
> On Fri, Oct 27, 2023 at 2:26 AM Bharath Rupireddy
> wrote:
> >
> > On Thu, Oct 26, 2023 at 8:11 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > The BF animal fairywren[1] failed when testing
> > > 003_upgrade_logical_replication_slots.pl.
> >
Hi Momjian.
Thank you for your improvement.
As a matter of detail, I think that the areas marked below are erroneous.
--
+ Pushdown causes aggregate function cals to send partial aggregate
^
+ function calls to the remote server. If the partial aggrega
Hello.
Some messages recently introduced by commit 29d0a77fa6 seem to deviate
slightly from our standards.
+ if (*invalidated && SlotIsLogical(s) && IsBinaryUpgrade)
+ {
+ ereport(ERROR,
+
errcode(ERRCODE_INV
On Thu, Oct 26, 2023 at 04:17:19PM -0700, David G. Johnston wrote:
> On Thu, Oct 26, 2023 at 4:13 PM David G. Johnston
> wrote:
>
> On Thu, Oct 26, 2023 at 4:08 PM Tom Lane wrote:
>
> Bruce Momjian writes:
> > Ah, I was confused. I documented both in the attached patch.
>
On Fri, Oct 27, 2023 at 02:44:42AM +,
fujii.y...@df.mitsubishielectric.co.jp wrote:
> Hi Momjian.
>
> Thank you for your improvement.
> As a matter of detail, I think that the areas marked below are erroneous.
>
> --
> + Pushdown causes aggregate function cals to send partial aggregate
>
On Fri, Oct 27, 2023 at 8:06 AM Amit Kapila wrote:
>
> > > +1 for
> > > s/003_upgrade_logical_replication_slots.pl/003_upgrade_logical_slots.pl
> > > and s/invalid_logical_replication_slots.txt/invalid_logical_slots.txt.
>
> +1. The proposed file name sounds reasonable.
>
> Agreed. So, how about
On Wed, 25 Oct 2023 at 22:48, Ashutosh Bapat
wrote:
> We may save the size of data in VirtualTupleTableSlot, thus avoiding
> the first loop. I assume that when allocating
> VirtualTupleTableSlot->data, we always know what size we are
> allocating so it should be just a matter of saving it in
> Vir
On Fri, Oct 27, 2023 at 8:28 AM Kyotaro Horiguchi
wrote:
>
> Hello.
>
> Some messages recently introduced by commit 29d0a77fa6 seem to deviate
> slightly from our standards.
>
> + if (*invalidated && SlotIsLogical(s) && IsBinaryUpgrade)
> + {
> + e
hi.
The test seems to assume the following sql query should return zero row.
but it does not. I don't know much about the "relreplident" column.
https://git.postgresql.org/cgit/postgresql.git/tree/src/test/regress/expected/type_sanity.out#n499
demo: https://dbfiddle.uk/QFM88S2e
test1=# \dt
Did no
On Fri, Oct 27, 2023 at 8:52 AM Bharath Rupireddy
wrote:
>
> On Fri, Oct 27, 2023 at 8:28 AM Kyotaro Horiguchi:
> The above errhint LGTM. How about a slightly different errmsg, like
> the following?
>
> +errmsg("cannot invalidate replication slots when
> in binary upgrade mode"
On Fri, Oct 27, 2023 at 1:58 PM Kyotaro Horiguchi
wrote:
>
> Hello.
>
> Some messages recently introduced by commit 29d0a77fa6 seem to deviate
> slightly from our standards.
>
> + if (*invalidated && SlotIsLogical(s) && IsBinaryUpgrade)
> + {
> + e
On Fri, Oct 27, 2023 at 9:37 AM Peter Smith wrote:
>
> On Fri, Oct 27, 2023 at 1:58 PM Kyotaro Horiguchi
> wrote:
> >
> > Hello.
> >
> > Some messages recently introduced by commit 29d0a77fa6 seem to deviate
> > slightly from our standards.
> >
> > + if (*invalidated && SlotIsLogica
Hi,
I as far as I can tell, pg_dump does not dup the ‘run_as_owner` setting for a
subscription.
Should it? Should I submit a patch? It seems pretty trivial to fix if anyone
else is working on it.
Sent from Mail for Windows
Dear Hou,
> The BF animal fairywren[1] failed when testing
> 003_upgrade_logical_replication_slots.pl.
Good catch!
>
> The reason could be the length of this path(262) exceed the windows path
> limit(260 IIRC). If so, I recall we fixed similar things before (e213de8e7) by
> reducing the path so
Dear Bharath, Amit, Peter,
Thank you for discussing! A patch can be available in [1].
> > > > +1 for
> s/003_upgrade_logical_replication_slots.pl/003_upgrade_logical_slots.pl
> > > > and s/invalid_logical_replication_slots.txt/invalid_logical_slots.txt.
> >
> > +1. The proposed file name sounds r
On Wed, Oct 25, 2023 at 01:39:41PM +0300, Smolkin Grigory wrote:
> We are running PG13.10 and recently we have encountered what appears to be
> a bug due to some race condition between ALTER TABLE ... ADD CONSTRAINT and
> some other catalog-writer, possibly ANALYZE.
> The problem is that after succ
On Fri, Oct 27, 2023 at 8:03 AM Michael Paquier wrote:
>
> Hmm. As per the existing call of pgstat_count_slru_flush() in
> SimpleLruWriteAll(), routine called SimpleLruFlush() until ~13 and
> dee663f78439, an incrementation of 1 for slru_stats_idx refers to all
> the flushes for all the dirty dat
On Fri, Oct 27, 2023 at 9:36 AM Amit Kapila wrote:
>
> On Fri, Oct 27, 2023 at 8:52 AM Bharath Rupireddy
> wrote:
> >
> > On Fri, Oct 27, 2023 at 8:28 AM Kyotaro Horiguchi:
> > The above errhint LGTM. How about a slightly different errmsg, like
> > the following?
> >
> > +errm
On Fri, Oct 27, 2023 at 10:23:34AM +0530, Bharath Rupireddy wrote:
> A possible way is to move existing pgstat_count_slru_flush in
> SimpleLruWriteAll closer to pg_fsync and WAIT_EVENT_SLRU_SYNC in
> SlruPhysicalWritePage, remove WAIT_EVENT_SLRU_FLUSH_SYNC completely,
> use WAIT_EVENT_SLRU_SYNC in
On Fri, Oct 27, 2023 at 11:45:44AM +0800, jian he wrote:
> The test seems to assume the following sql query should return zero row.
> but it does not. I don't know much about the "relreplident" column.
This is not about relreplident here, that refers to a relation's
replica identity.
> test1=# SE
1 - 100 of 118 matches
Mail list logo
