On Tue, Apr 5, 2022 at 9:18 PM Robert Haas wrote:
>
> On Wed, Mar 30, 2022 at 12:03 PM Justin Pryzby wrote:
> > On Wed, Mar 30, 2022 at 11:53:52AM -0400, Greg Stark wrote:
> > > Sadly the cfbot is showing a patch conflict again. It's just a trivial
> > > conflict in the regression test schedule s
On Mon, Apr 4, 2022 at 1:06 PM Etsuro Fujita wrote:
> On Sun, Apr 3, 2022 at 11:38 PM Zhihong Yu wrote:
> > + WRITE_ENUM_FIELD(status, SubqueryScanStatus);
> >
> > Looks like the new field can be named subquerystatus - this way its purpose
> > is clearer.
>
> I agree that “status” is too gener
At Wed, 06 Apr 2022 15:31:53 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 06 Apr 2022 14:30:37 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > So if we don't want to move any member in PGPROC, we do:
> >
> > 14: after statusFlags.
> > 13: after delayChkpt.
> > 12-10: after syncRepState (a
At Wed, 06 Apr 2022 14:30:37 +0900 (JST), Kyotaro Horiguchi
wrote in
> So if we don't want to move any member in PGPROC, we do:
>
> 14: after statusFlags.
> 13: after delayChkpt.
> 12-10: after syncRepState (and before syncRepLinks).
>
> If we allow to shift some members, the new flag can be p
On Wed, Apr 6, 2022 at 11:09 AM wangw.f...@fujitsu.com
wrote:
>
> On Fri, Apr 1, 2022 at 12:09 AM Amit Kapila wrote:
> > On Fri, Apr 1, 2022 at 8:28 AM Euler Taveira wrote:
> > >
> > > It seems I didn't make myself clear. The callbacks I'm referring to the
> > > *_cb_wrapper functions. After eve
On Fri, Apr 1, 2022 at 12:09 AM Amit Kapila wrote:
> On Fri, Apr 1, 2022 at 8:28 AM Euler Taveira wrote:
> >
> > On Thu, Mar 31, 2022, at 11:27 PM, Amit Kapila wrote:
> >
> > This is exactly our initial analysis and we have tried a patch on
> > these lines and it has a noticeable overhead. See [1
me> I'd like to do that. Let me see.
At Tue, 5 Apr 2022 10:29:03 -0400, Robert Haas wrote in
> On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
> > What I think you need to do is:
> >
> > 1. In the back branches, revert delayChkpt to its previous type and
> > semantics. Squeeze a separate delay
Tom,
thank you very much! It makes sense now.
K
On Tue, Apr 5, 2022 at 10:08 PM Tom Lane wrote:
> Konstantin Izmailov writes:
> > could you help me understand if this is an intended behaviour, or I'm
> > incorrectly querying a "char" field?
>
> We do not support '\0' as an element of a string
In this email, I would like to discuss allowing streaming logical
transactions (large in-progress transactions) by background workers
and parallel apply in general. The goal of this work is to improve the
performance of the apply work in logical replication.
Currently, for large transactions, the
Konstantin Izmailov writes:
> could you help me understand if this is an intended behaviour, or I'm
> incorrectly querying a "char" field?
We do not support '\0' as an element of a string value. You didn't
show how you're trying to insert this value, but I suspect that
Postgres saw it as an empt
On Mon, 2022-04-04 at 09:15 +0530, Bharath Rupireddy wrote:
> My intention is to return the overall undecoded WAL record [5] i.e.
> the data starting from XLogReadRecord's output [6] till length
> XLogRecGetTotalLen(xlogreader);. Please see [7], where Andres agreed
> to have this function, I also m
Hi,
could you help me understand if this is an intended behaviour, or I'm
incorrectly querying a "char" field? I have simple table with column
declared as:
c_tinyint char NOT NULL
The column contains tiny integers in range 0-10. When I query the column
from my app using libpq values 1-10 are ret
On Wed, Apr 6, 2022 at 7:21 AM Ajin Cherian wrote:
>
> On Tue, Apr 5, 2022 at 8:32 PM Amit Kapila wrote:
>
> >
> > How about something like the attached?
> >
>
> LGTM.
>
Pushed.
--
With Regards,
Amit Kapila.
On Wed, Apr 6, 2022 at 9:25 AM Masahiko Sawada wrote:
>
> On Wed, Apr 6, 2022 at 12:21 PM Noah Misch wrote:
>
> Right. I've attached an updated patch.
>
Thanks, this looks good to me as well. Noah, would you like to commit it?
--
With Regards,
Amit Kapila.
Amit Langote writes:
> On Sun, Apr 3, 2022 at 10:31 PM Greg Stark wrote:
>> Is this a problem with the patch or its tests?
>> [18:14:20.798] Test Summary Report
>> [18:14:20.798] ---
>> [18:14:20.798] t/013_partition.pl (Wstat: 15360 Tests: 31 Failed: 0)
> Hmm, make check-world p
On Tue, Apr 5, 2022 at 7:06 PM Ashutosh Bapat
wrote:
>
> On Tue, Apr 5, 2022 at 6:21 AM Peter Smith wrote:
> >
> > Below are some other name ideas. Maybe they are not improvements, but
> > it might help other people to come up with something better.
> >
> > subscribe_publocal_only = true/false
>
On Wed, Apr 6, 2022 at 12:21 PM Noah Misch wrote:
>
> On Tue, Apr 05, 2022 at 04:41:28PM +0900, Masahiko Sawada wrote:
> > On Tue, Apr 5, 2022 at 4:08 PM Noah Misch wrote:
> > > On Tue, Apr 05, 2022 at 03:05:10PM +0900, Masahiko Sawada wrote:
> > > > I've attached an updated patch. The patch incl
On Sun, Apr 3, 2022 at 10:31 PM Greg Stark wrote:
> Is this a problem with the patch or its tests?
>
> [18:14:20.798] # poll_query_until timed out executing this query:
> [18:14:20.798] # SELECT count(1) = 0 FROM pg_subscription_rel WHERE
> srsubstate NOT IN ('r', 's');
> [18:14:20.798] # expectin
On Tue, Apr 5, 2022 at 8:14 PM Andres Freund wrote:
>
> On 2022-04-05 20:00:50 -0700, David G. Johnston wrote:
>
> * Statistics are loaded from the filesystem during startup (by the startup
> * process), unless preceded by a crash, in which case all stats are
> * discarded. They are written ou
Andres Freund writes:
> The new jsonb_sqljson test is, on my machine, the slowest test in the main
> regression tests:
> ...
> Any chance the slowness isn't required slowness?
In general, there's been a serious bump in the buildfarm cycle
time in the last month --- for example, on my admittedly s
Hi,
On 2022-04-05 23:11:07 -0400, Greg Stark wrote:
> I've never tried to review a 24-patch series before. It's kind of
> intimidating Is there a good place to start to get a good idea of
> the most important changes?
It was more at some point :). And believe me, I find this whole project
int
On Tue, Apr 05, 2022 at 04:41:28PM +0900, Masahiko Sawada wrote:
> On Tue, Apr 5, 2022 at 4:08 PM Noah Misch wrote:
> > On Tue, Apr 05, 2022 at 03:05:10PM +0900, Masahiko Sawada wrote:
> > > I've attached an updated patch. The patch includes a regression test
> > > to detect the new violation as w
On Tue, Apr 5, 2022 at 8:11 PM Greg Stark wrote:
> I've never tried to review a 24-patch series before. It's kind of
> intimidating Is there a good place to start to get a good idea of
> the most important changes?
>
It isn't as bad as the number makes it sound - I just used "git am" to
appl
Hi,
On 2022-04-05 20:00:50 -0700, David G. Johnston wrote:
> On Tue, Apr 5, 2022 at 4:16 PM Andres Freund wrote:
> > On 2022-04-05 14:43:49 -0700, David G. Johnston wrote:
> > > On Tue, Apr 5, 2022 at 2:23 PM Andres Freund wrote:
> > > > I guess I should add a paragraph about snapshots / fetch c
I've never tried to review a 24-patch series before. It's kind of
intimidating Is there a good place to start to get a good idea of
the most important changes?
On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote:
>
> Here comes v70:
>
> I think this is basically ready, minus a a few comment adjustments here and
> there. Unless somebody protests I'm planning to start pushing things
> tomorrow
> morning.
>
>
Nothing I've come across, given my area of exper
On Tue, Apr 5, 2022 at 4:16 PM Andres Freund wrote:
> On 2022-04-05 14:43:49 -0700, David G. Johnston wrote:
> > On Tue, Apr 5, 2022 at 2:23 PM Andres Freund wrote:
>
> >
> > > I guess I should add a paragraph about snapshots / fetch consistency.
> > >
> >
> > I apparently confused/combined the
Hi,
On 2022-04-06 00:08:13 +0200, Gunnar "Nick" Bluth wrote:
> AFAICT, Andres' work is more about the structure (e.g.
> 13619598f1080d7923454634a2570ca1bc0f2fec). Or I've missed something...?
That was just the prep work... I'm about to send slightly further polished
version, but here's the patchs
Hi,
On 2022-03-27 16:53:57 -0400, Andrew Dunstan wrote:
> I'm therefore going to commit this series
The new jsonb_sqljson test is, on my machine, the slowest test in the main
regression tests:
4639 ms jsonb_sqljson
2401 ms btree_index
2166 ms stats_ext
2027 ms alter_table
1616 ms triggers
1498 m
Hi,
On 2022-04-04 23:32:50 +0200, Peter Eisentraut wrote:
> This has been committed.
It's somewhat annoying that made pg_regress even more verbose than before:
== removing existing temp instance==
== creating temporary instance=
On Tue, Apr 5, 2022 at 8:32 PM Amit Kapila wrote:
>
> How about something like the attached?
>
LGTM.
regards,
Ajin Cherian
Fujitsu Australia
At Tue, 5 Apr 2022 10:01:56 -0400, Robert Haas wrote in
> I think as the person who committed that patch I'm on the hook to fix
> this if nobody else would like to do it, but let me ask whether
> Kyotaro Horiguchi would like to propose a patch, since the original
> patch did, and/or whether you w
On Wed, Apr 6, 2022 at 12:41 AM Robert Haas wrote:
> On Tue, Apr 5, 2022 at 10:10 AM Andy Fan wrote:
> >> > I wanted to have a WAL record spanning multiple WAL files of size, say
> >> > 16MB. I'm wondering if the Full Page Images (FPIs) of a TOAST table
> >> > would help here. Please let me know
On Wed, 6 Apr 2022 at 01:42, Thom Brown wrote:
>
> On Tue, 5 Apr 2022 at 16:02, Robert Haas wrote:
> >
> > On Tue, Apr 5, 2022 at 10:58 AM Magnus Hagander wrote:
> > >> Makes sense. I will do this soon if nobody objects.
> > >>
> > >> I'm mildly uncomfortable with the phrase "WAL records generat
>> I would suggest to reorder the last chunk to:
>>
>>... retried retries failures serfail dlfail
>>
>> because I intend to add connection failures handling at some point,
>> and it would make more sense to add the corresponding count at the end
>> with other fails.
>
> Ok, I have adjusted t
Andres Freund writes:
> On 2022-04-04 00:50:27 -0400, Tom Lane wrote:
>> It's hard to be totally sure, but I think what happened is that
>> gaur hit the in-hindsight-obvious race condition in this code:
>> we managed to execute a successful iteration of poll_query_until
>> before the postmaster ha
On Tue, 5 Apr 2022 at 16:02, Robert Haas wrote:
>
> On Tue, Apr 5, 2022 at 10:58 AM Magnus Hagander wrote:
> >> Makes sense. I will do this soon if nobody objects.
> >>
> >> I'm mildly uncomfortable with the phrase "WAL records generated over
> >> the delay period" because it seems a bit imprecis
On 2022-04-05 14:43:49 -0700, David G. Johnston wrote:
> On Tue, Apr 5, 2022 at 2:23 PM Andres Freund wrote:
>
> >
> > On 2022-04-05 13:51:12 -0700, David G. Johnston wrote:
> >
> > >, but rather add to the shared queue
> >
> > Queue? Maybe you mean the hashtable?
> >
>
> Queue implemented by a
Hi
Updated patch: we use the posix semantic features in Windows build 17763
and up.
We found an issue with this feature on Windows Server 2016 without
updates (Windows 1607 Build 14393)
Victor Spirin
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
05.07.2021 16:
On Tue, Apr 5, 2022 at 3:35 PM Zhihong Yu wrote:
>
>
> On Tue, Apr 5, 2022 at 3:18 PM Joe Wildish wrote:
>
>> Hello Hackers,
>>
>> Reporting a bug with the new MERGE statement. Tested against
>> 75edb919613ee835e7680e40137e494c7856bcf9.
>>
>> psql output as follows:
>>
>> ...
>> psql:merge.sql:3
On Tue, Apr 5, 2022 at 3:18 PM Joe Wildish wrote:
> Hello Hackers,
>
> Reporting a bug with the new MERGE statement. Tested against
> 75edb919613ee835e7680e40137e494c7856bcf9.
>
> psql output as follows:
>
> ...
> psql:merge.sql:33: ERROR: variable not found in subplan target lists
> ROLLBACK
>
On Tue, Apr 5, 2022 at 2:53 PM Robert Haas wrote:
> On Tue, Apr 5, 2022 at 4:30 PM Peter Geoghegan wrote:
> > On Tue, Apr 5, 2022 at 1:10 PM Robert Haas wrote:
> > > I had assumed that this would not be the case, because if the page is
> > > being accessed by the workload, it can be pruned - and
Hello Hackers,
Reporting a bug with the new MERGE statement. Tested against
75edb919613ee835e7680e40137e494c7856bcf9.
psql output as follows:
...
psql:merge.sql:33: ERROR: variable not found in subplan target lists
ROLLBACK
[local] joe@joe=# \errverbose
ERROR: XX000: variable not found in sub
Am 05.04.22 um 18:17 schrieb Robert Haas:
> On Thu, Mar 31, 2022 at 9:16 AM Gunnar "Nick" Bluth
> wrote:
>> That was meant to say "v10", sorry!
>
> Hi,
Hi Robert,
and thx for looking at this.
> From my point of view, at least, it would be preferable if you'd stop
> changing the subject line ev
On Tue, Apr 5, 2022 at 4:30 PM Peter Geoghegan wrote:
> On Tue, Apr 5, 2022 at 1:10 PM Robert Haas wrote:
> > I had assumed that this would not be the case, because if the page is
> > being accessed by the workload, it can be pruned - and probably frozen
> > too, if we wanted to write code for th
On Tue, Apr 5, 2022 at 2:23 PM Andres Freund wrote:
>
> On 2022-04-05 13:51:12 -0700, David G. Johnston wrote:
>
> >, but rather add to the shared queue
>
> Queue? Maybe you mean the hashtable?
>
Queue implemented by a list...? Anyway, I think I mean this:
/*
* List of PgStat_EntryRefs with u
Hi,
On 2022-04-05 13:51:12 -0700, David G. Johnston wrote:
> On Mon, Apr 4, 2022 at 8:05 PM Andres Freund wrote:
>
> > - added an architecture overview comment to the top of pgstat.c - not sure
> > if
> > it makes sense to anybody but me (and perhaps Horiguchi-san)?
> >
> >
> I took a look at
This is not passing regression tests due to some details of the plan
output - marking Waiting on Author:
diff -w -U3 c:/cirrus/src/test/regress/expected/partition_prune.out
c:/cirrus/src/test/recovery/tmp_check/results/partition_prune.out
--- c:/cirrus/src/test/regress/expected/partition_prune.out
On Mon, Apr 4, 2022 at 8:05 PM Andres Freund wrote:
> - added an architecture overview comment to the top of pgstat.c - not sure
> if
> it makes sense to anybody but me (and perhaps Horiguchi-san)?
>
>
I took a look at this, diff attached. Some typos and minor style stuff,
plus trying to bring
Hi,
On 2022-04-02 01:16:48 -0700, Andres Freund wrote:
> I just noticed that the code doesn't appear to actually work like that right
> now. Whenever the timeout is reached, pgstat_report_stat() is called with
> force = true.
>
> And even if the backend is busy running queries, once there's conte
On Tue, Apr 5, 2022 at 1:10 PM Robert Haas wrote:
> I had assumed that this would not be the case, because if the page is
> being accessed by the workload, it can be pruned - and probably frozen
> too, if we wanted to write code for that and spend the cycles on it -
> and if it isn't, pruning and
On Wed, 6 Apr 2022 at 02:27, Greg Stark wrote:
>
> This is failing regression tests. I don't understand how this patch
> could be affecting this test though. Perhaps it's a problem with the
> json patches that were committed recently -- but they don't seem to be
> causing other patches to fail.
I
On Tue, Apr 5, 2022 at 3:22 PM Peter Geoghegan wrote:
> It's not just an enabler of more frequent index vacuuming (for those
> indexes that need it the most), though. It's also an enabler of more
> frequent lazy_scan_prune processing (in particular setting hint bits
> and freezing), which is proba
On Tue, Apr 05, 2022 at 11:25:36AM -0400, Stephen Frost wrote:
> Please find attached an updated patch + commit message. Mostly, I just
> went through and did a bit more in terms of updating the documentation
> and improving the comments (there were some places that were still
> worrying about the
On Fri, Apr 1, 2022 at 11:12 AM Matthias van de Meent
wrote:
> Here's a new 0001 to keep CFBot happy.
This seems like it would conflict with the proposal from
http://postgr.es/m/ca+tgmoad8wmn6i1mmuo+4znege3hd57ys8uv8uzm7cneqy3...@mail.gmail.com
which I still hope to advance in some form at an app
On Tue, Mar 8, 2022 at 6:12 AM Antonin Houska wrote:
> Thanks for your comments, the initial version is attached here.
I've been meaning to look at this thread for some time but have not
found enough time to do that until just now. And now I have
questions...
1. Supposing we accepted this, how w
On Tue, Apr 5, 2022 at 5:44 AM Robert Haas wrote:
> The whole idea of decoupling table and index vacuum
> supposes that there are situations in which it's worth performing the
> first heap pass where we gather the dead line pointers but where it's
> not necessary to follow that up as quickly as po
Robert Haas writes:
> Do you care whether your commit
> or mine goes in first?
I do not. If they're not independent, at least one of us has messed up.
I have family commitments on Saturday, so if I don't get mine in
on Friday it'll likely not happen before Sunday.
regar
Robert Haas writes:
> On Tue, Apr 5, 2022 at 10:32 AM Tom Lane wrote:
>> My point is that we want that to happen in HEAD, but it's not okay
>> for it to happen in a minor release of a stable branch.
> I understand, but I am not sure that I agree. I think that if an
> extension stops compiling ag
>Can't the progress data trivially be inferred by the fact that the worker
>completed?
Yes, at some point, this idea was experimented with in
0004-Expose-progress-for-the-vacuuming-indexes-cleanup-ph.patch.
This patch did the calculation in system_views.sql
However, the view is complex an
On Tuesday, April 5, 2022, Andres Freund wrote:
> Hi,
>
> On 2022-04-05 08:49:36 -0700, David G. Johnston wrote:
> > On Mon, Apr 4, 2022 at 7:36 PM Andres Freund wrote:
> >
> > >
> > > I think all this is going to achieve is to making code more
> complicated.
> > > There
> > > is a *single* non-
On Tue, 2022-04-05 at 15:13 +0900, Michael Paquier wrote:
> On Wed, Mar 30, 2022 at 04:02:09PM +, Jacob Champion wrote:
> > Whether that's a problem in the future entirely depends on whether
> > there's some authentication method that considers the empty string a
> > sane and meaningful identit
Apologies -- I selected the wrong commit to extract the commit message
from. Here it is again. I also removed an obsolete /* XXX */ comment.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
>From 0b26f90f1b95f8e9b932eb34bbf9c2a50729cf60 Mon Sep 17 00:00:00 2001
F
On Tue, Apr 5, 2022 at 10:06 PM Robert Haas wrote:
>
> On Tue, Apr 5, 2022 at 10:07 AM Tom Lane wrote:
> > Yeah, the frontend error message rework in [1]. That has exactly
> > the same constraint that it's likely to break other open patches,
> > so it'd be better to do it after the CF cutoff. I
On 2022-04-05 16:42:28 +, Imseih (AWS), Sami wrote:
> >Why isn't the obvious thing to do here to provide a way to associate
> > workers
> >with their leaders in shared memory, but to use the existing progress
> > fields
> >to report progress? Then, when querying progress, the lead
Hi,
On 2022-04-05 08:49:36 -0700, David G. Johnston wrote:
> On Mon, Apr 4, 2022 at 7:36 PM Andres Freund wrote:
>
> >
> > I think all this is going to achieve is to making code more complicated.
> > There
> > is a *single* non-assert use of accessed_across_databases and now a single
> > asserti
On Tue, Apr 5, 2022 at 12:42 PM Imseih (AWS), Sami wrote:
> >Why isn't the obvious thing to do here to provide a way to associate
> > workers
> >with their leaders in shared memory, but to use the existing progress
> > fields
> >to report progress? Then, when querying progress, the l
On Mon, Apr 4, 2022 at 10:20 PM Thomas Munro wrote:
> > The checkpointer never takes heavyweight locks, so the opportunity
> > you're describing can't arise.
>
> Hmm, oh, you probably meant the buffer interlocking
> in SyncOneBuffer(). It's true that my most recent patch throws away
> more requ
On 3/26/22 11:10 AM, Jonathan S. Katz wrote:
Additionally, the RMT has set the feature freeze date to be April 7,
2022. This is the last day to commit features for PostgreSQL 15. In
other words, no new PostgreSQL 15 feature can be committed after April 8
0:00, 2022 AoE[1].
[1] https://en.wik
On Mon, Apr 4, 2022 at 8:25 PM Peter Geoghegan wrote:
> Right. The reason I used WARNINGs was because it matches vaguely
> related WARNINGs in vac_update_relstats()'s sibling function,
> vacuum_set_xid_limits().
Okay, pushed the relfrozenxid warning patch.
Thanks
--
Peter Geoghegan
On Tue, Apr 5, 2022 at 5:25 PM Stephen Frost wrote:
> Greetings,
>
> * David Steele (da...@pgmasters.net) wrote:
> > On 4/4/22 11:42 AM, Nathan Bossart wrote:
> > >I noticed a couple of other things that can be removed. Since we no
> longer
> > >wait on exclusive backup mode during smart shutdow
>I nevertheless think that's not acceptable. The whole premise of the
> progress
>reporting infrastructure is to be low overhead. It's OK to require locking
> to
>initialize parallel progress reporting, it's definitely not ok to require
>locking to report progress.
Fair point.
>
On Tue, Apr 5, 2022 at 10:10 AM Andy Fan wrote:
>> > I wanted to have a WAL record spanning multiple WAL files of size, say
>> > 16MB. I'm wondering if the Full Page Images (FPIs) of a TOAST table
>> > would help here. Please let me know if there's any way to generate
>> > such large WAL records.
On Thu, Mar 31, 2022 at 9:16 AM Gunnar "Nick" Bluth
wrote:
> That was meant to say "v10", sorry!
Hi,
>From my point of view, at least, it would be preferable if you'd stop
changing the subject line every time you post a new version.
Based on the test results in
http://postgr.es/m/42bfa680-7998-
On 4/5/22 11:25 AM, Stephen Frost wrote:
Please find attached an updated patch + commit message. Mostly, I just
went through and did a bit more in terms of updating the documentation
and improving the comments (there were some places that were still
worrying about the chance of a 'stray' backup
Hi,
I'm thinking if there's a way in core postgres to achieve $subject. In
reality, the sync/async standbys can either be closer/farther (which
means sync/async standbys can receive WAL at different times) to
primary, especially in cloud HA environments with primary in one
Availability Zone(AZ)/Re
On Mon, Mar 21, 2022 at 9:15 PM Andres Freund wrote:
> On 2022-02-25 13:23:31 +0900, Noboru Saito wrote:
> > I have created a patch that allows you to turn it on and off in \pset.
>
> The patch unfortunately causes tests to fail:
It doesn't seem like the originally proposed design here will be
ac
On Mon, Apr 4, 2022 at 7:36 PM Andres Freund wrote:
>
> I think all this is going to achieve is to making code more complicated.
> There
> is a *single* non-assert use of accessed_across_databases and now a single
> assertion involving it.
>
> What would having PGSTAT_KIND_CLUSTER and PGSTAT_KIND
On Wed, Mar 30, 2022 at 12:03 PM Justin Pryzby wrote:
> On Wed, Mar 30, 2022 at 11:53:52AM -0400, Greg Stark wrote:
> > Sadly the cfbot is showing a patch conflict again. It's just a trivial
> > conflict in the regression test schedule so I'm not going to update
> > the status but it would be good
Here's a v8, where per my previous comment I removed some code that I
believe is no longer necessary.
I've omitted the patch that renames LogwrtResult subvariables into
LogWriteResult/LogWriteFlush; I still think the end result is better
after that one, but it's a pretty trivial change that can be
Good day, David.
I'm looking on patch and don't get some moments.
`GrantLockLocal` allocates `LOCALLOCKOWNER` and links it into
`locallock->locallockowners`. It links it regardless `owner` could be
NULL. But then `RemoveLocalLock` does `Assert(locallockowner->owner != NULL);`.
Why it should not f
On Thu, Mar 17, 2022 at 4:02 PM Tom Lane wrote:
> Pretty much, yeah. I'm way more interested in cleaning up the code
> we have than in making things prettier for hypothetical future
> call sites. In particular, the problem with writing an API in a
> vacuum is that you have little evidence that i
Greetings,
* David Steele (da...@pgmasters.net) wrote:
> On 4/4/22 11:42 AM, Nathan Bossart wrote:
> >I noticed a couple of other things that can be removed. Since we no longer
> >wait on exclusive backup mode during smart shutdown, we can change
> >connsAllowed (in postmaster.c) to a boolean and
On Tue, Apr 5, 2022 at 10:07 AM Tom Lane wrote:
> Yeah, the frontend error message rework in [1]. That has exactly
> the same constraint that it's likely to break other open patches,
> so it'd be better to do it after the CF cutoff. I think that doing
> that concurrently with Robert's thing shou
On Tue, Apr 5, 2022 at 10:58 AM Magnus Hagander wrote:
>> Makes sense. I will do this soon if nobody objects.
>>
>> I'm mildly uncomfortable with the phrase "WAL records generated over
>> the delay period" because it seems a bit imprecise, but I'm not sure
>> what would be better and I think the m
On Tue, Apr 5, 2022 at 4:54 PM Robert Haas wrote:
> On Tue, Apr 5, 2022 at 8:41 AM Thom Brown wrote:
> > I know it's been 8 years, but I still think it would be a useful note
> > to add to the docs.
>
Many points for bringing that one back :)
Makes sense. I will do this soon if nobody objects
On Tue, Apr 5, 2022 at 8:41 AM Thom Brown wrote:
> I know it's been 8 years, but I still think it would be a useful note
> to add to the docs.
Makes sense. I will do this soon if nobody objects.
I'm mildly uncomfortable with the phrase "WAL records generated over
the delay period" because it see
On Tue, Apr 5, 2022 at 10:32 AM Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
> >> Renaming it would constitute an API break, which is if anything worse
> >> than an ABI break.
>
> > I don't think so, because an API break will cause a compilation
> > f
Robert Haas writes:
> On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
>> Renaming it would constitute an API break, which is if anything worse
>> than an ABI break.
> I don't think so, because an API break will cause a compilation
> failure, which an extension author can easily fix.
My point is
On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
> Renaming it would constitute an API break, which is if anything worse
> than an ABI break.
I don't think so, because an API break will cause a compilation
failure, which an extension author can easily fix.
> While we're complaining at you, let me
This is failing regression tests. I don't understand how this patch
could be affecting this test though. Perhaps it's a problem with the
json patches that were committed recently -- but they don't seem to be
causing other patches to fail.
diff -U3 /tmp/cirrus-ci-build/src/test/regress/expected/js
Robert Haas writes:
> On Tue, Apr 5, 2022 at 9:02 AM Markus Wanner
> wrote:
>> And for this specific case: Is it worth reverting this change and
>> applying a fully backwards compatible fix, instead?
> I think it's normally our policy to avoid changing definitions of
> accessible structs in back
On 4/4/22 16:41, Andres Freund wrote:
> Hi,
>
> On 2022-03-30 17:26:18 -0700, Andres Freund wrote:
>> Hi,
>>
>> On 2022-03-22 19:00:42 +0300, Melih Mutlu wrote:
>>> Rebased it.
>>> I also removed the temp installation task and
>>> used NoDefaultCurrentDirectoryInExePath env variable instead.
>> H
Hi,
On Tue, Apr 5, 2022 at 9:46 PM Alvaro Herrera
wrote:
> On 2022-Apr-05, Bharath Rupireddy wrote:
>
> > Hi,
> >
> > I wanted to have a WAL record spanning multiple WAL files of size, say
> > 16MB. I'm wondering if the Full Page Images (FPIs) of a TOAST table
> > would help here. Please let me
Andrew Dunstan writes:
> On 3/30/22 14:37, Robert Haas wrote:
>> @RMT: Andres proposed upthread that we should plan to do this just
>> after feature freeze. Accordingly I propose to commit at least 0002
>> and perhaps 0001 if people want it just after feature freeze. I
>> therefore ask that the RM
On Tue, Apr 5, 2022 at 9:02 AM Markus Wanner
wrote:
> And for this specific case: Is it worth reverting this change and
> applying a fully backwards compatible fix, instead?
I think it's normally our policy to avoid changing definitions of
accessible structs in back branches, except that we allow
On 2022-Apr-05, Bharath Rupireddy wrote:
> Hi,
>
> I wanted to have a WAL record spanning multiple WAL files of size, say
> 16MB. I'm wondering if the Full Page Images (FPIs) of a TOAST table
> would help here. Please let me know if there's any way to generate
> such large WAL records.
It's easi
On Tue, 5 Apr 2022 at 15:13, Bharath Rupireddy
wrote:
>
> Hi,
>
> I wanted to have a WAL record spanning multiple WAL files of size, say
> 16MB. I'm wondering if the Full Page Images (FPIs) of a TOAST table
> would help here. Please let me know if there's any way to generate
> such large WAL recor
On Tue, Apr 5, 2022 at 6:21 AM Peter Smith wrote:
>
> Here are my comments for the latest patch v6-0001.
>
> (I will post my v6-0002 review comments separately)
>
> PATCH v6-0001 comments
> ==
>
> 1.1 General - Option name
>
> I still feel like the option name is not ideal. Unf
On 3/30/22 14:37, Robert Haas wrote:
> On Fri, Feb 18, 2022 at 7:02 PM Andres Freund wrote:
>> On 2022-02-15 08:06:58 -0800, Andres Freund wrote:
>>> The more I think about it the more I'm convinced that if we want to do this,
>>> we should do it for variables and functions.
>> Btw, if we were t
1 - 100 of 133 matches
Mail list logo
