On Tue, Sep 19, 2023 at 12:07:07PM +0200, Matthias van de Meent wrote:
> V5 is a rebased version of v4, and includes the latest patch from
> "smaller XLRec block header" [0] as 0001.
0001 and 0007 are the meat of the changes.
-#define XLR_CHECK_CONSISTENCY 0x02
+#define XLR_CHECK_CONSISTENCY (0
On 23/8/2023 12:37, Richard Guo wrote:
If we go with the "tablesample scans can't be reparameterized" approach
in the back branches, I'm a little concerned that what if we find more
cases in the futrue where we need modify RTEs for reparameterization.
So I spent some time seeking and have managed
On 29/9/2022 21:32, Benjamin Coutu wrote:
I'd like to revamp this important discussion.
As is well described in this fairly recent paper here
https://www.vldb.org/pvldb/vol9/p204-leis.pdf (which also looks at Postgres)
"estimation errors quickly grow as the number of joins increases, and that
Hi,
Thanks for the review!
Current status of the patch is:
- IOOBJECT_WAL / IOCONTEXT_NORMAL read, write and fsync stats are added.
- IOOBJECT_WAL / IOCONTEXT_NORMAL write and fsync tests are added.
- IOOBJECT_WAL / IOCONTEXT_INIT stats are added.
- pg_stat_io shows different op_bytes for the IOO
On 2023/09/20 12:04, Michael Paquier wrote:
This is a known issue. I guess that the same as this thread and this
CF entry:
https://commitfest.postgresql.org/44/4244/
https://www.postgresql.org/message-id/flat/zarvomifjze7f...@paquier.xyz
I think this is a separate issue, and we should still
On Wed, Sep 20, 2023 at 12:12 PM Amit Kapila wrote:
>
> On Wed, Sep 20, 2023 at 11:51 AM Dilip Kumar wrote:
> >
> > On Wed, Sep 20, 2023 at 11:00 AM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > Dear Amit,
> > >
> > > Thank you for reviewing! PSA new version. In this version I ran pgindent
> >
> On 19 Sep 2023, at 10:06, Sergey Shinderuk wrote:
>
> On 19.09.2023 03:54, Michael Paquier wrote:
>> One doubt that I have is if we shouldn't let X509_NAME_print_ex() be
>> as it is now, and not force a failure on the bio if this calls fails.
>
> If malloc fails inside X509_NAME_print_ex, then
Hi
st 20. 9. 2023 v 9:34 odesílatel Maciek Sakrejda
napsal:
> On Tue, Sep 19, 2023 at 5:56 PM Jeff Davis wrote:
> >...
> > On Tue, 2023-09-19 at 11:41 -0400, Robert Haas wrote:
> > > That leads to a second idea, which is having it continue
> > > to be a GUC but only affect directly-entered SQL,
On 20.09.2023 11:42, Daniel Gustafsson wrote:
Attached is a v2 on top of HEAD with commit message etc, which I propose to
backpatch to v15 where it was introduced.
There is a typo: upon en error. Otherwise, looks good to me. Thank you.
--
Sergey Shinderukhttps://postgrespro.com
> On 20 Sep 2023, at 10:55, Sergey Shinderuk wrote:
>
> On 20.09.2023 11:42, Daniel Gustafsson wrote:
>> Attached is a v2 on top of HEAD with commit message etc, which I propose to
>> backpatch to v15 where it was introduced.
> There is a typo: upon en error. Otherwise, looks good to me. Thank yo
On 06.08.23 21:39, Ahmed Ibrahim wrote:
I have addressed the pg version compatibility with the FORCE option in
drop. Here is the last version of the patch
The patch is pretty small, but I think there is some disagreement
whether we want this option at all? Maybe some more people can make
the
On 29.08.23 05:37, a.rybakina wrote:
Thank you for your interest in this problem and help, and I'm sorry that
I didn't respond to this email for a long time. To be honest, I wanted
to investigate the problems in more detail and already answer more
clearly, but unfortunately I have not found any
Thank you for all your reviews!
>>> PATTERN should be changed to SCHEMA because -n and -N options don't
support
>>> pattern matching for schema names. The attached patch 0001 fixes this.
>>
>> True, there is no pattern matching performed. I wonder if it's worth
lifting
>> the pattern matching fro
On Wed, 20 Sept 2023 at 19:56, Andrey Lepikhov
wrote:
> What could you say about a different way: hybrid join? In MS SQL Server,
> they have such a feature [1], and, according to their description, it
> requires low overhead. They start from HashJoin and switch to NestLoop
> if the inner input con
On Wed, Aug 16, 2023 at 7:57 PM Tomas Vondra
wrote:
>
I was reading through 0001, I noticed this comment in
ReorderBufferSequenceIsTransactional() function
+ * To decide if a sequence change should be handled as transactional or applied
+ * immediately, we track (sequence) relfilenodes created b
Hello Ashutosh and Andrey,
Thank you for your email, and I really apologize for my late response.
On Thu, Sep 7, 2023 at 3:43 PM Ashutosh Bapat
wrote:
> It seems that you are still investigating and fixing issues. But the
> CF entry is marked as "needs review". I think a better status is
> "WoA
On Wed, Sep 20, 2023 at 12:16 PM Amit Kapila wrote:
>
> On Wed, Sep 20, 2023 at 11:00 AM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear Amit,
>
> +int
> +count_old_cluster_logical_slots(void)
> +{
> + int dbnum;
> + int slot_count = 0;
> +
> + for (dbnum = 0; dbnum < old_cluster.dbarr.ndbs; dbnum+
On Wed, 20 Sept 2023 at 22:06, Etsuro Fujita wrote:
> So I would like to propose to extend the comment to explain what they
> can do, as in the comment about set_rel_pathlist_hook() in allpaths.c.
> Attached is a patch for that.
Looks good to me.
I see you've copy/edited the comment just above t
On Wed, Sep 20, 2023 at 3:35 PM Yuya Watari wrote:
> I think we may be able to remove the eclass_child_members field by
> making child members on demand. v20 makes child members at
> add_[child_]join_rel_equivalences() and adds them into
> RelOptInfo->eclass_child_members. Instead of doing that,
> On 20 Sep 2023, at 11:46, Kuwamura Masaki
> wrote:
> I think that supporting pattern matching is quite nice.
> But it will be not only tough but also a breaking change, I wonder.
> So I guess this change should be commited either way.
I agree. Supporting pattern matching should, if anyone is
On Thu, Sep 14, 2023 at 2:41 PM Amit Kapila wrote:
>
> On Thu, Sep 14, 2023 at 7:20 AM Michael Paquier wrote:
> >
> > On Wed, Sep 13, 2023 at 04:20:37PM +0530, Amit Kapila wrote:
> > > The patch is updated as per recent discussion.
> >
> > WFM. Thanks for the updated version.
> >
>
> Pushed.
Co
On Wed, Sep 20, 2023 at 04:48:00PM +0530, Ashutosh Bapat wrote:
> Commitfest entry "https://commitfest.postgresql.org/44/4536/ is in
> "Ready for committer" state. Is there something remaining here? We
> should probably set it as "committed".
Thanks, I've switched that to "Committed".
--
Michael
Dear Amit,
> +int
> +count_old_cluster_logical_slots(void)
> +{
> + int dbnum;
> + int slot_count = 0;
> +
> + for (dbnum = 0; dbnum < old_cluster.dbarr.ndbs; dbnum++)
> + slot_count += old_cluster.dbarr.dbs[dbnum].slot_arr.nslots;
> +
> + return slot_count;
> +}
>
> In this code, aren't we assum
Hi,
What I am concerned about from the report [1] is that this comment is
a bit too terse; it might cause a misunderstanding that extensions can
do different things than we intend to allow:
/*
* 6. Finally, give extensions a chance to manipulate the path list.
*/
if (set_join_pa
Dear Amit,
Thank you for reviewing! New version can be available in [1].
>
> +{ oid => '8046', descr => 'for use by pg_upgrade',
> + proname => 'binary_upgrade_validate_wal_records',
> + prorows => '10', proretset => 't', provolatile => 's', prorettype =>
> 'bool',
> + proargtypes => 'pg_lsn
Hi Ashutosh,
On Wed, Aug 16, 2023 at 2:28 PM Ashutosh Bapat
wrote:
> On Fri, Aug 4, 2023 at 2:11 PM Ashutosh Bapat
> wrote:
> >
> > Attached patchset fixing those.
> > 0001 - patch to report planning memory, with to explain.out regression
> > output fix. We may consider committing this as well.
> On 20 Sep 2023, at 11:24, Peter Eisentraut wrote:
>
> On 06.08.23 21:39, Ahmed Ibrahim wrote:
>> I have addressed the pg version compatibility with the FORCE option in drop.
>> Here is the last version of the patch
>
> The patch is pretty small, but I think there is some disagreement whether
Hi!
When I sent the patch version to commitfest, I thought that the work on
this topic was completed. Patch version and test results in [0].
But in the process of discussing this patch, we found out that there is
another place where you can make a transformation, specifically, during
the cal
On Wed, 20 Sept 2023 at 11:27, jian he wrote:
>
> if I remove IntervalAggState's element: MemoryContext, it will not work.
> so I don't understand what the above sentence means.. Sorry. (it's
> my problem)
>
I don't see why it won't work. The point is to try to simplify
do_interval_accum() as
On Thu, 7 Sept 2023 at 03:34, Nathan Bossart
wrote:
> Committed.
>
Hi! Great job!
But here is one problem I've encountered during working on some unrelated
stuff.
How we have two different things call the same name – sync_method. One in
xlog:
intsync_method = DEFAULT_SYNC_METHOD;
..
On Wed, 20 Sept 2023 at 13:09, Dean Rasheed wrote:
>
> So basically, do_interval_accum() could be simplified to:
>
Oh, and I guess it also needs an INTERVAL_NOT_FINITE() check, to make
sure that finite values don't sum to our representation of infinity,
as in interval_pl().
Regards,
Dean
> On 19 Sep 2023, at 11:21, bt23nguyent wrote:
> Please let me know if you have any further suggestions that I can improve
> more.
+*logdetail = pstrdup("WAL archiving failed because
basic_archive.archive_directory is not set");
Nitpick: detail messages should end with a period per th
On Fri, Sep 15, 2023 at 3:08 PM vignesh C wrote:
>
> The attached v8 version patch has the changes for the same.
>
Is the check to ensure remote_lsn is valid correct in function
check_for_subscription_state()? How about the case where the apply
worker didn't receive any change but just marked the
Hi,
On the latest master head, I can see a $subject bug that seems to be related
commit #b0e96f311985:
Here is the table definition:
create table foo(i int, j int, CONSTRAINT pk PRIMARY KEY(i) DEFERRABLE);
And after restore from the dump, it shows a descriptor where column 'i' not
marked NOT NUL
On Wed, Sep 20, 2023 at 5:24 PM Amit Langote wrote:
>
> I read this thread and have been reading the latest patch. At first
> glance, it seems quite straightforward to me. I agree with Richard
> that pfree()'ing 4 bitmapsets may not be a lot of added overhead. I
> will study the patch a bit mor
On Mon, Sep 18, 2023 at 5:09 PM Dean Rasheed wrote:
>
> On Wed, 13 Sept 2023 at 11:13, Ashutosh Bapat
> wrote:
> >
> > On Tue, Sep 12, 2023 at 2:39 PM Dean Rasheed
> > wrote:
> > >
> > > and it looks like the infinite interval
> > > input code is broken.
> >
> > The code required to handle 'inf
Hi Dmitry,
Thanks for looking at the patch and sorry for the long line.
On 3/17/23 21:14, Dmitry Dolgov wrote:
The idea sounds reasonable to me, but I have to admit snapshot_and_stats
implementation looks awkward. Maybe it would be better to have a
separate structure field for both stats and sn
On Wed, Sep 20, 2023 at 5:44 PM Dean Rasheed wrote:
>
> On Wed, 20 Sept 2023 at 13:09, Dean Rasheed wrote:
> >
> > So basically, do_interval_accum() could be simplified to:
> >
>
> Oh, and I guess it also needs an INTERVAL_NOT_FINITE() check, to make
> sure that finite values don't sum to our rep
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> On Tue, 2023-09-19 at 12:52 -0400, Robert Haas wrote:
> > On Tue, Sep 19, 2023 at 12:30 PM Alvaro Herrera
> > wrote:
> > > I was thinking something vaguely like "a table size that's roughly what
> > > an optimal autovacuuming schedule
Hi, Peter!
Thank you for your interest in this patch.
On Tue, Sep 19, 2023 at 1:48 AM Peter Geoghegan wrote:
>
> On Thu, Sep 14, 2023 at 3:23 AM Alexander Korotkov
> wrote:
> > The attached patch allows Postgres to skip scan keys required for
> > directional scans (even when other keys are pr
On Wed, 20 Sept 2023 at 15:00, Ashutosh Bapat
wrote:
>
> 0005 - Refactored Jian's code fixing window functions. Does not
> contain the changes for serialization and deserialization. Jian,
> please let me know if I have missed anything else.
>
That looks a lot neater. One thing I don't care for is
On 2023-Sep-20, Amul Sul wrote:
> On the latest master head, I can see a $subject bug that seems to be related
> commit #b0e96f311985:
>
> Here is the table definition:
> create table foo(i int, j int, CONSTRAINT pk PRIMARY KEY(i) DEFERRABLE);
Interesting, thanks for the report. Your attributio
On Wed, Sep 20, 2023, at 4:49 PM, David Rowley wrote:
> On Wed, 20 Sept 2023 at 19:56, Andrey Lepikhov
> wrote:
>> What could you say about a different way: hybrid join? In MS SQL Server,
>> they have such a feature [1], and, according to their description, it
>> requires low overhead. They sta
Although v7 patch doesn't have commit messages on the patch, I think
leave commit message is good for reviewers.
Sure, didn't notice it. Added the commit message to the updated patch.
* Note: DON'T convert this error to "soft" style (errsave/ereturn). We
* want this data type to stay perm
I got a complaint that pg_upgrade --check fails to raise red flags when
the source database contains type abstime when upgrading from pg11. The
type (along with reltime and tinterval) was removed by pg12.
In passing, while testing this, I noticed that the translation
infrastructure in pg_upgrade
+/*
+ * check_for_removed_data_type_usage
+ *
+ *similar to the above, but for types that were removed in 12.
+ */
+static void
+check_for_removed_data_type_usage(ClusterInfo *cluster, const char *datatype)
Seems like you could make this more generic instead of hardcoding
version 12, an
On 2023-Sep-20, Tristan Partin wrote:
> > +/*
> > + * check_for_removed_data_type_usage
> > + *
> > + *similar to the above, but for types that were removed in 12.
> > + */
> > +static void
> > +check_for_removed_data_type_usage(ClusterInfo *cluster, const char
> > *datatype)
>
> Seems l
On 9/20/23 01:24, Tom Lane wrote:
> Tomas Vondra writes:
>> bsd@freebsd:~ $ tclsh8.6
>> % clock scan "1/26/2010"
>> time value too large/small to represent
>
> In hopes of replicating this, I tried installing FreeBSD 14-BETA2
> aarch64 on my Pi 3B. This test case works fine:
>
> $ tclsh8.6
>
On 9/20/23 19:59, Tomas Vondra wrote:
>
>
> On 9/20/23 01:24, Tom Lane wrote:
>> Tomas Vondra writes:
>>> bsd@freebsd:~ $ tclsh8.6
>>> % clock scan "1/26/2010"
>>> time value too large/small to represent
>>
>> In hopes of replicating this, I tried installing FreeBSD 14-BETA2
>> aarch64 on my Pi
On Wed Sep 20, 2023 at 12:58 PM CDT, Alvaro Herrera wrote:
On 2023-Sep-20, Tristan Partin wrote:
> > +/*
> > + * check_for_removed_data_type_usage
> > + *
> > + *similar to the above, but for types that were removed in 12.
> > + */
> > +static void
> > +check_for_removed_data_type_usage(
On Wed, Sep 20, 2023 at 03:12:56PM +0300, Maxim Orlov wrote:
> As a solution, I suggest renaming sync_method in xlog module to
> wal_sync_method. In fact,
> appropriate GUC for this variable, called "wal_sync_method" and I see no
> reason not to use
> the exact same name for a variable in xlog modu
On 2023-09-19 Tu 23:07, Amit Langote wrote:
On Tue, Sep 19, 2023 at 9:00 PM Amit Langote wrote:
On Tue, Sep 19, 2023 at 7:37 PM jian he wrote:
---
https://www.postgresql.org/docs/current/extend-type-system.html#EXTEND-TYPES-POLYMORPHIC
When the return value of a function
On Tue, Sep 19, 2023 at 08:36:35AM +0530, Amit Kapila wrote:
> I am of the opinion that worker_type should be 'apply' instead of
> 'leader apply' because even when it is a leader for parallel apply
> worker, it could perform individual transactions apply. For reference,
> I checked pg_stat_activity
On Mon, Sep 18, 2023 at 2:57 PM Robert Haas wrote:
> I've been brainstorming about this today, trying to figure out some
> ideas to make it work.
Here are some patches.
0001 refactors XLogInsertRecord to unify a couple of separate tests of
isLogSwitch, hopefully making it cleaner and cheaper to
Belated thanks Dmitry, Ronan, Andres for your feedback. Here's a new
version, also including Dmitry's patch for 17 which it is now also
time to push. It required a bit more trivial #if magic to be
conditional, as Dmitry already mentioned. I just noticed that Dmitry
had the LLVMPassBuilderOptions
On Tue, Sep 19, 2023 at 12:15:55PM +0200, Pierre Ducroquet wrote:
> Attached updated patches fix this regression, I'm sorry I missed that.
Thanks for the new patches. 0001 and 0002 look reasonable to me. This is
a nitpick, but we might want to use atooid() in 0002, which is just
shorthand for th
Hi,
Currently we claim to support all versions of LLVM from 3.9 up. It's
now getting quite inconvenient to test changes on older releases with
single digit major versions, because they aren't available through
usual package channels on current distributions, and frankly it feels
like pointless bu
On Thu, Sep 21, 2023 at 5:30 AM Nathan Bossart wrote:
>
> On Tue, Sep 19, 2023 at 08:36:35AM +0530, Amit Kapila wrote:
> > I am of the opinion that worker_type should be 'apply' instead of
> > 'leader apply' because even when it is a leader for parallel apply
> > worker, it could perform individua
On Wed, Sep 20, 2023 at 04:54:36PM +0530, Amit Kapila wrote:
> Also, the patch seems to be allowing subscription relations from PG
> >=10 to be migrated but how will that work if the corresponding
> publisher is also upgraded without slots? Won't the corresponding
> workers start failing as soon as
On Thu, Sep 21, 2023 at 09:01:01AM +1000, Peter Smith wrote:
> One question -- the patch comment still says "Bumps catversion.", but
> catversion.h change is missing from the v9 patch?
Yeah, previous patches did that, but it is no big deal. My take is
that it is a good practice to never do a catv
On Thu, Sep 21, 2023 at 08:14:23AM +0900, Michael Paquier wrote:
> On Thu, Sep 21, 2023 at 09:01:01AM +1000, Peter Smith wrote:
>> One question -- the patch comment still says "Bumps catversion.", but
>> catversion.h change is missing from the v9 patch?
>
> Yeah, previous patches did that, but it
On Thu, Sep 21, 2023 at 9:34 AM Nathan Bossart wrote:
>
> On Thu, Sep 21, 2023 at 08:14:23AM +0900, Michael Paquier wrote:
> > On Thu, Sep 21, 2023 at 09:01:01AM +1000, Peter Smith wrote:
> >> One question -- the patch comment still says "Bumps catversion.", but
> >> catversion.h change is missing
Hi Thomas,
On Thu, 2023-09-21 at 08:22 +1200, Thomas Munro wrote:
> So far I've tested LLVM versions 10, 15, 16, 17, 18 (= their main
> branch) against PostgreSQL versions 14, 15, 16. I've attached the
> versions that apply to master and 16, and pushed back-patches to 14
> and 15 to public bran
Hi,
On Thu, 2023-09-21 at 10:54 +1200, Thomas Munro wrote:
> I'm trying to understand the practical constraints. Perhaps a package
> maintainer could correct me if I have this wrong. Distros typically
> support a range of releases from the past few years, and then bless
> one as 'default' by mak
On Thu, Sep 21, 2023 at 12:24 PM Devrim Gündüz wrote:
> On Thu, 2023-09-21 at 08:22 +1200, Thomas Munro wrote:
> > So far I've tested LLVM versions 10, 15, 16, 17, 18 (= their main
> > branch) against PostgreSQL versions 14, 15, 16. I've attached the
> > versions that apply to master and 16, and
On Wed, Sep 20, 2023 at 10:24 PM Ashutosh Bapat
wrote:
> On Wed, Sep 20, 2023 at 5:24 PM Amit Langote wrote:
> > Just one comment on 0003:
> >
> > + /*
> > +* Dummy SpecialJoinInfos do not have any translated fields and hence
> > have
> > +* nothing to free.
> > +*/
> > + if (chi
Hi,
When --buffer-usage-limit option is specified, vacuumdb issues VACUUM or
VACUUM ANALYZE command with BUFFER_USAGE_LIMIT option. Also if
--buffer-usage-limit and -Z options are specified, vacuumdb should issue
ANALYZE command with BUFFER_USAGE_LIMIT option. But it does not. That
is, vacuum
>
> I agree. Supporting pattern matching should, if anyone is interested in
> trying, be done separately in its own thread, no need to move the goalposts
> here. Sorry if I made it sound like so upthread.
>
I got it.
> When sending an update, please include the previous patch as well with
> you
On 2023-09-20 21:14, Daniel Gustafsson wrote:
On 19 Sep 2023, at 11:21, bt23nguyent
wrote:
Please let me know if you have any further suggestions that I can
improve more.
+*logdetail = pstrdup("WAL archiving failed because
basic_archive.archive_directory is not set");
Nitpick: deta
On Thu, Sep 21, 2023 at 10:44:49AM +0900, Ryoga Yoshida wrote:
> When --buffer-usage-limit option is specified, vacuumdb issues VACUUM or
> VACUUM ANALYZE command with BUFFER_USAGE_LIMIT option. Also if
> --buffer-usage-limit and -Z options are specified, vacuumdb should issue
> ANALYZE command wit
On Wed, Sep 20, 2023, at 5:05 PM, Etsuro Fujita wrote:
> Hi,
>
> What I am concerned about from the report [1] is that this comment is
> a bit too terse; it might cause a misunderstanding that extensions can
> do different things than we intend to allow:
>
> /*
> * 6. Finally, give extensi
nterval negate function, So I changed to interval_um_internal.
based on 20230920 patches. I have made the attached changes.
The serialization do make big difference when configure to parallel mode.
From bff5e3dfa8607a8b45aa287a7c55fda9d984f339 Mon Sep 17 00:00:00 2001
From: pgaddict
Date: Thu,
Dear hackers,
While developing my patch, I found that the CI for macOS failed with unknown
error [1].
Do you know the reason why it happened? Please tell me if you have
workarounds...
It failed the test at "Upload 'ccache' cache". The Cirrus app said a following
message:
> Persistent worker f
Thanks for the patch.
I rerun the test in
https://www.postgresql.org/message-id/flat/ZQtzcH2lvo8leXEr%40paquier.xyz#cc5ed83e0edc0b9a1c1305f08ff7a335
. We can discuss all the problems in this thread.
First I encountered the problem " FATAL: could not find
recovery.signal or standby.signal when re
On Tue, Sep 19, 2023 at 10:29 AM shveta malik wrote:
>
> On Fri, Sep 15, 2023 at 2:22 PM Peter Smith wrote:
> >
> > Hi. Here are some review comments for v17-0002.
> >
>
> Thanks Peter for the feedback. I have addressed most of these in v18
> except 2. Please find my comments for the ones not a
On Thu, 21 Sept 2023 at 13:45, Ryoga Yoshida
wrote:
> When --buffer-usage-limit option is specified, vacuumdb issues VACUUM or
> VACUUM ANALYZE command with BUFFER_USAGE_LIMIT option. Also if
> --buffer-usage-limit and -Z options are specified, vacuumdb should issue
> ANALYZE command with BUFFER_U
On Thu, Sep 21, 2023 at 6:37 AM Amit Langote wrote:
>
> On Wed, Sep 20, 2023 at 10:24 PM Ashutosh Bapat
> wrote:
> > On Wed, Sep 20, 2023 at 5:24 PM Amit Langote
> > wrote:
> > > Just one comment on 0003:
> > >
> > > + /*
> > > +* Dummy SpecialJoinInfos do not have any translated fields a
Thomas Munro writes:
> I wonder if there is a good way to make this sort of thing more
> systematic. If we could agree on a guiding principle vaguely like the
> above, then perhaps we just need a wiki page that lists relevant
> distributions, versions and EOL dates, that could be used to reduce
>
On Thu, 21 Sept 2023 at 16:18, David Rowley wrote:
> Thanks for the report and the patch. I agree this has been overlooked.
>
> I also wonder if we should be escaping the buffer-usage-limit string
> sent in the comment. It seems quite an unlikely attack vector, as the
> user would have command li
Hi,
On Thu, Sep 21, 2023 at 11:49 AM Lepikhov Andrei
wrote:
> On Wed, Sep 20, 2023, at 5:05 PM, Etsuro Fujita wrote:
> > What I am concerned about from the report [1] is that this comment is
> > a bit too terse; it might cause a misunderstanding that extensions can
> > do different things than we
On Fri, Sep 15, 2023 at 03:08:21PM +0530, vignesh C wrote:
> On Tue, 12 Sept 2023 at 14:25, Hayato Kuroda (Fujitsu)
> wrote:
>> Is there a possibility that apply worker on old cluster connects to the
>> publisher during the upgrade? Regarding the pg_upgrade on publisher, the we
>> refuse TCP/IP co
On Thu, Sep 21, 2023 at 05:50:26PM +1200, David Rowley wrote:
> I've pushed your patch plus some additional code to escape the text
> specified in --buffer-usage-limit before passing it to the server in
> commit 5cfba1ad6
That was fast. If I may ask, why don't you have some regression tests
for t
On Wed, Sep 20, 2023 at 04:54:36PM +0530, Amit Kapila wrote:
> Is the check to ensure remote_lsn is valid correct in function
> check_for_subscription_state()? How about the case where the apply
> worker didn't receive any change but just marked the relation as
> 'ready'?
I may be missing, of cour
On Thu, Sep 21, 2023, at 12:53 PM, Etsuro Fujita wrote:
> Hi,
>
> On Thu, Sep 21, 2023 at 11:49 AM Lepikhov Andrei
> wrote:
>> On Wed, Sep 20, 2023, at 5:05 PM, Etsuro Fujita wrote:
>> > What I am concerned about from the report [1] is that this comment is
>> > a bit too terse; it might cause a mi
On Fri, Sep 15, 2023 at 02:47:45PM +0300, Heikki Linnakangas wrote:
> On 05/09/2023 21:20, Robert Haas wrote:
> Thinking about this some more, I think this is still not 100% correct, even
> with the patch I posted earlier:
>
> > /*
> > * When we WAL-logged rel pages, we must nonetheless
Thanks, Alvaro, for working on this.
The patch looks good to me.
+ * similar to the above, but for types that were removed in 12.
Comment can start with a capital letter.
Also, We need to backport the same, right?
On Wed, Sep 20, 2023 at 10:24 PM Alvaro Herrera
wrote:
> I got a complaint that
On Thu, 21 Sept 2023 at 17:59, Michael Paquier wrote:
> That was fast. If I may ask, why don't you have some regression tests
> for the two code paths of vacuumdb that append this option to the
> commands generated for VACUUM and ANALYZE?
I think we have differing standards for what constitutes
87 matches
Mail list logo
