On Tue, 2021-12-14 at 07:41 -0800, Mark Dilger wrote:
> I went a different direction with this. The need is to prevent non-
> superuser subscription owners from *circumventing* RLS. For this
> patch set, I'm just checking whether RLS should be enforced against
> the subscription owner, and if so,
> On Dec 13, 2021, at 10:18 PM, Jeff Davis wrote:
>
>>This is implemented but I still need to update the documentation
>> before
>>posting.
>
> We also discussed how much of the insert path we want to include in the
> apply worker. The immediate need is for the patch to support RLS, b
On Mon, 2021-12-13 at 11:20 -0800, Mark Dilger wrote:
> - The logical replication subscription patch needs to consider RLS.
> (Jeff Davis)
>
> This is implemented but I still need to update the documentation
> before
> posting.
We also discussed how much of the insert path we want t
> On Nov 11, 2021, at 2:12 PM, Daniel Gustafsson wrote:
>
> 3223: Delegating superuser tasks to new security roles
> ==
> There is a lot of ongoing discussion on this one, but skimming the thread it's
> not really clear (to me) where it leave
> On Fri, Dec 03, 2021 at 09:51:21AM +0100, Daniel Gustafsson wrote:
> I've now closed the 2021-11 commitfest, ~36% of the patches were closed in
> some
> way (committed, returned with feedback, withdrawn or rejected) with 184
> patches
> moved to the next CF.
Impressive numbers, thank you!
Daniel Gustafsson writes:
> I've now closed the 2021-11 commitfest, ~36% of the patches were closed in
> some
> way (committed, returned with feedback, withdrawn or rejected) with 184
> patches
> moved to the next CF.
Thanks for all your hard work on managing the CF!
(And particularly, thanks
I've now closed the 2021-11 commitfest, ~36% of the patches were closed in some
way (committed, returned with feedback, withdrawn or rejected) with 184 patches
moved to the next CF.
--
Daniel Gustafsson https://vmware.com/
On Wed, 1 Dec 2021 09:14:31 -0300
Marcos Pegoraro wrote:
> >
> > I think the reason why we can't update a materialized view directly is
> > because
> > it is basically a "view" and it should not contains any data irrelevant to
> > its
> > definition and underlying tables. If we would have a featu
On 12/2/21 12:06, Daniel Gustafsson wrote:
On 6 Nov 2021, at 17:20, Tomas Vondra wrote:
On 11/5/21 22:15, Daniel Gustafsson wrote:
...
1651: GROUP BY optimization
===
This is IMO a desired optimization, and after all the heavy lifting by Tomas
the patch seems to be i
> On 6 Nov 2021, at 17:20, Tomas Vondra wrote:
>
> On 11/5/21 22:15, Daniel Gustafsson wrote:
>> ...
>> 1651: GROUP BY optimization
>> ===
>> This is IMO a desired optimization, and after all the heavy lifting by Tomas
>> the patch seems to be in pretty good shape.
>
> I
>
> I think the reason why we can't update a materialized view directly is
> because
> it is basically a "view" and it should not contains any data irrelevant to
> its
> definition and underlying tables. If we would have a feature to update a
> materialized view direcly, maybe, it should behave as
On Mon, 29 Nov 2021 09:03:06 -0300
Marcos Pegoraro wrote:
> >
> > > 2138: Incremental Materialized View Maintenance
> >
> > I've responded to it in the following thread, and described the recent
> > discussions,
> > current status, summary of IVM feature and design, and past discussions.
> >
>
>
> 2780: Allow COPY "text" to output a header and add header matching mode to
> COPY
> FROM
> ===
> The original patch was rejected for lacking matching, but it has since been
> addressed in an updated patch which has se
>
> > 2138: Incremental Materialized View Maintenance
>
> I've responded to it in the following thread, and described the recent
> discussions,
> current status, summary of IVM feature and design, and past discussions.
>
IVM is a wonderful feature, but some features were omitted because of
its co
On Fri, 5 Nov 2021 22:15:49 +0100
Daniel Gustafsson wrote:
> 2138: Incremental Materialized View Maintenance
> ===
> There seems to be concensus on the thread that this is a feature that we want,
> and after initial design discussions there seems to be
Hi! It’s been a while since the original patch release. Let me provide a brief
overview of the current patch status.
The initial approach was to use the streaming compression to compress all
outgoing and decompress all incoming bytes. However, after the long discussion
in the thread, the initia
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Nov 15, 2021 at 2:51 PM Stephen Frost wrote:
> > I get that just compressing the entire stream is simpler and easier and
> > such, but it's surely cheaper and more efficient to not decompress and
> > then recompress data that's alr
On Mon, Nov 15, 2021 at 03:23:17PM -0500, Robert Haas wrote:
> On Mon, Nov 15, 2021 at 2:51 PM Stephen Frost wrote:
> > I get that just compressing the entire stream is simpler and easier and
> > such, but it's surely cheaper and more efficient to not decompress and
> > then recompress data that's
On Mon, Nov 15, 2021 at 2:51 PM Stephen Frost wrote:
> I get that just compressing the entire stream is simpler and easier and
> such, but it's surely cheaper and more efficient to not decompress and
> then recompress data that's already compressed. Finding a way to pass
> through data that's alr
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 15 Nov 2021, at 15:32, Robert Haas wrote:
> > On Tue, Nov 9, 2021 at 9:12 AM Daniel Gustafsson wrote:
> >> 2773: libpq compression
> >> ===
> >> This patch intended to provide libpq connection compression to "repl
> On 15 Nov 2021, at 15:32, Robert Haas wrote:
>
> On Tue, Nov 9, 2021 at 9:12 AM Daniel Gustafsson wrote:
>> 2773: libpq compression
>> ===
>> This patch intended to provide libpq connection compression to "replace SSL
>> compression" which was doomed when the patch was writ
On Tue, Nov 9, 2021 at 9:12 AM Daniel Gustafsson wrote:
> 2773: libpq compression
> ===
> This patch intended to provide libpq connection compression to "replace SSL
> compression" which was doomed when the patch was written, and have since been
> removed altogether. The initi
Stephen Frost writes:
> Attackers aren't likely to have the kind of isolated control over the
> data in the WAL stream (which is a combination of data from lots of
> ongoing activity in the system and isn't likely to be exactly what the
> attacker supplied at some higher level anyway) and the abil
Greetings,
* Andrey Borodin (x4...@yandex-team.ru) wrote:
> > On 11/10/21 16:54, Andrey Borodin wrote:
> >> Compression is crucial for highly available setups. Replication traffic is
> >> often billed. Or route has bandwidth limits.
> >> An entropy added by WAL headers makes CRIME attack against
> On 11/10/21 16:54, Andrey Borodin wrote:
>
>> Compression is crucial for highly available setups. Replication traffic is
>> often billed. Or route has bandwidth limits.
>> An entropy added by WAL headers makes CRIME attack against replication
>> encryption impractical.
>
> I very much doub
On 11/10/21 16:54, Andrey Borodin wrote:
Daniel Gustafsson writes:
2773: libpq compression
===
This patch intended to provide libpq connection compression to "replace SSL
compression" which was doomed when the patch was written, and have since been
removed altogether. Th
On 11/10/21 00:21, Bruce Momjian wrote:
On Tue, Nov 9, 2021 at 12:43:20PM -0500, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Daniel Gustafsson writes:
I'm not Robert, but I still have an opinion here, and that it's that this
feature would at best be an attractive nuisance.
On Tue, Nov 9, 2021 at 7:02 AM Tom Lane wrote:
> Daniel Gustafsson writes:
> > 2773: libpq compression
> > ===
> > This patch intended to provide libpq connection compression to "replace
> SSL
> > compression" which was doomed when the patch was written, and have since
> been
> On 9 Nov 2021, at 18:43, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Daniel Gustafsson writes:
>>> 2773: libpq compression
>>> ===
>>> This patch intended to provide libpq connection compression to "replace SSL
>>> compression" which was doomed when the
Welcome to the third installment of the CF 2021-11 patch triage, looking at the
patches which have been in four CF's and parts of the ones with three CF's. As
per usual I might very well have misunderstood something (or many things), but
there seem to be a fair few ones which should be closeable i
> Daniel Gustafsson writes:
>
>> 2773: libpq compression
>> ===
>> This patch intended to provide libpq connection compression to "replace SSL
>> compression" which was doomed when the patch was written, and have since been
>> removed altogether. The initial approach didn't
On Tue, Nov 09, 2021 at 03:12:39PM +0100, Daniel Gustafsson wrote:
> 2800: CLUSTER on partitioned table
> ==
> The the patch above, it too spawned off from the REINDEX CONCURRENTLY thread
> but seems to have stalled awaiting more review. There was scepticism raised
On Tue, Nov 9, 2021 at 12:43:20PM -0500, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Daniel Gustafsson writes:
> > I'm not Robert, but I still have an opinion here, and that it's that this
> > feature would at best be an attractive nuisance. If you need compression
> > on a
On 11/9/21 09:12, Daniel Gustafsson wrote:
>
> 2901: SQL/JSON: functions
> 2901: SQL/JSON: JSON_TABLE
> ==
> Grouping these two together as they are in very similar states. The patches
> seems to mostly move forward by rebases fixing smaller things. Andrew, do you
> have
> Daniel Gustafsson writes:
> > 2773: libpq compression
> > ===
> > This patch intended to provide libpq connection compression to
> > "replace SSL compression" which was doomed when the patch was
> written,
> > and have since been removed altogether. The initial approach didn
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Daniel Gustafsson writes:
> > 2773: libpq compression
> > ===
> > This patch intended to provide libpq connection compression to "replace SSL
> > compression" which was doomed when the patch was written, and have since
> > b
Hi
2839: possibility to rename root namespace in plpgsql
> =
> This patch addresses a feature request for making plpgsql easier to work
> with,
> but the approach has been questioned with the thread stalling since March
> in
> one of these discus
Daniel Gustafsson writes:
> 2773: libpq compression
> ===
> This patch intended to provide libpq connection compression to "replace SSL
> compression" which was doomed when the patch was written, and have since been
> removed altogether. The initial approach didn't get much tr
Below is the second pass over the patches in the current commitfest, this time
the patches which have been around for 5 or 6 commitfests. The usual
disclaimers that I very well might have missed something still apply.
2773: libpq compression
===
This patch intended to provide
On Mon, Nov 08, 2021 at 03:07:43PM +0900, Kyotaro Horiguchi wrote:
> I noticed I'm one of the author^^; I'll also look into the comments
> and try to address them.
Cool, thanks. I'll come back to this thread from this point, then.
--
Michael
signature.asc
Description: PGP signature
At Mon, 8 Nov 2021 14:43:43 +0900, Michael Paquier wrote
in
> On Fri, Nov 05, 2021 at 10:15:49PM +0100, Daniel Gustafsson wrote:
> > 2161: standby recovery fails when re-replaying due to missing directory
> > which
> > was removed in previous replay.
> >
On Fri, Nov 05, 2021 at 10:15:49PM +0100, Daniel Gustafsson wrote:
> 2161: standby recovery fails when re-replaying due to missing directory which
> was removed in previous replay.
> =
> Tom and Robert seem to be in agreeme
Thanks for the summary.
At Fri, 5 Nov 2021 22:15:49 +0100, Daniel Gustafsson wrote in
> 2490: Make message at end-of-recovery less scary
>
> This thread stalled, but has had recent interest. The patch no longer applies
> so while the patch has su
On 2021-Nov-05, Daniel Gustafsson wrote:
> 2716: fix spinlock contention in LogwrtResult
> =
> This addresses a bottleneck which definitely seems like one we want to fix, I
> don't have a hard time imagining it impacting other production usecases then
>
> On 6 Nov 2021, at 02:12, Andy Fan wrote:
>
>> 1741: Index Skip Scan
>> =
>> An often requested feature which has proven hard to reach consensus on an
>> implementation for. The thread(s) have stalled since May,
>
> This statement is not accurate. Peter started a new threa
> On 6 Nov 2021, at 17:20, Tomas Vondra wrote:
>
> On 11/5/21 22:15, Daniel Gustafsson wrote:
>> ...
>> 1651: GROUP BY optimization
>> ===
>> This is IMO a desired optimization, and after all the heavy lifting by Tomas
>> the patch seems to be in pretty good shape.
>
> I
> On 7 Nov 2021, at 10:26, Etsuro Fujita wrote:
>
> On Sat, Nov 6, 2021 at 6:16 AM Daniel Gustafsson wrote:
>> 2601: Fast COPY FROM command for the foreign tables
>> ===
>> This approach taken in this patch has stabilized and the benchmarks posted
On Sat, Nov 6, 2021 at 6:16 AM Daniel Gustafsson wrote:
> 2601: Fast COPY FROM command for the foreign tables
> ===
> This approach taken in this patch has stabilized and the benchmarks posted are
> very promising. It seems pretty uncontroversial to
On 11/5/21 22:15, Daniel Gustafsson wrote:
...
1651: GROUP BY optimization
===
This is IMO a desired optimization, and after all the heavy lifting by Tomas
the patch seems to be in pretty good shape.
I agree it's desirable. To move the patch forward, I need some feedbac
> 1741: Index Skip Scan
> =
> An often requested feature which has proven hard to reach consensus on an
> implementation for. The thread(s) have stalled since May,
This statement is not accurate. Peter started a new thread in [1] for this
topic last month and then we had a di
Thanks for taking care of this.
> 2433: Erase the distinctClause if the result is unique by definition
>
> (parts of) The approach taken in this patch has been objected against in favor
> of work that Tom has proposed.
Actually
We have amassed quite a lot of patches in the CF app, and while Jaime did a
very good job closing patches in the last CF there is still a lot to go
through. I've attempted a brief per-patch triage here to see where we are with
these. Reading every email in the threads for these patches is a hercu
> On 1 Nov 2021, at 14:38, Daniel Gustafsson wrote:
>
> It is now November 1st AOE and thus the 2021-11 commitfest is now in progress.
> I've switched the status and opened 2022-01 for new patches, but noone has so
> far raised their hand to run it AFAICT? Do we have a volunteer Commitfest
> Man
It is now November 1st AOE and thus the 2021-11 commitfest is now in progress.
I've switched the status and opened 2022-01 for new patches, but noone has so
far raised their hand to run it AFAICT? Do we have a volunteer Commitfest
Manager keen to help the community make progress on closing patches
54 matches
Mail list logo
