Hello Noah,
28.06.2024 08:13, Noah Misch wrote:
Pushed.
A recent buildfarm test failure [1] showed that the
intra-grant-inplace-db.spec test added with 0844b3968 may fail
on a slow machine (per my understanding):
test intra-grant-inplace-db ... FAILED 4302 ms
@@ -21,8 +21,7 @@
On Thu, Jul 18, 2024 at 02:11:13PM +0300, Nazir Bilal Yavuz wrote:
> v4 is attached.
Removal of the PinBufferForBlock() comment about the "persistence =
RELPERSISTENCE_PERMANENT" fallback started to feel like a loss. I looked for
a way to re-add a comment about the fallback.
https://coverage.post
On Sat, Jul 20, 2024 at 11:00:00AM +0300, Alexander Lakhin wrote:
> 28.06.2024 08:13, Noah Misch wrote:
> > Pushed.
>
> A recent buildfarm test failure [1] showed that the
> intra-grant-inplace-db.spec test added with 0844b3968 may fail
> on a slow machine
> But as the test going to be modified b
> On 8 May 2024, at 18:37, Andrey M. Borodin wrote:
>
> It's RFC now.
PFA version with references to RFC instead of drafts.
In nearby thread [0] we found out that most systems have enough presicion to
fill additional 12 bits of sub-millisecond information. So I switched
implementation to thi
Hi,
On Sat, 20 Jul 2024 at 14:27, Noah Misch wrote:
>
> On Thu, Jul 18, 2024 at 02:11:13PM +0300, Nazir Bilal Yavuz wrote:
> > v4 is attached.
>
> Removal of the PinBufferForBlock() comment about the "persistence =
> RELPERSISTENCE_PERMANENT" fallback started to feel like a loss. I looked for
>
On Fri, 19 Jul 2024 at 21:48, Tomas Vondra
wrote:
>
>
>
> On 7/19/24 17:16, Jelte Fennema-Nio wrote:
> > That's been moving forward, even relatively fast imho for the
> > size/impact of that patchset. But those changes are much less
> > straight-forward than this patch. And while I hope that they
On 2024-05-28 Tu 6:13 PM, Andres Freund wrote:
Hi,
On 2024-04-05 16:12:12 -0400, Andrew Dunstan wrote:
OK, this has been fixed and checked. The attached is what I propose.
The perl command is pretty hard to read. What about using python's shlex
module instead? Rough draft attached. Still not
On Wed, 10 Jul 2024 at 13:46, Peter Smith wrote:
>
> Here are a few comments for patch v20240705-0003.
>
> (This is a WIP. I have only looked at the docs so far.)
>
> ==
> doc/src/sgml/config.sgml
>
> nitpick - max_logical_replication_workers: /and sequence
> synchornization worker/and a seque
On Fri, 12 Jul 2024 at 08:22, Peter Smith wrote:
>
> Hi Vignesh. Here are the rest of my comments for patch v20240705-0003.
> ==
> src/backend/catalog/pg_subscription.c
>
> 1. GetSubscriptionSequences
>
> +/*
> + * Get the sequences for the subscription.
> + *
> + * The returned list is palloc
Wow I was busy for a controle of days and now I’m again fully committed to
this initiative. These ideas are extremely useful to my. I’ll first start
by reading the old in-place implementation, but meanwhile I have the
following questions:
1- I’m thinking of adding only one simple step to be auto-va
On Thu, 18 Jul 2024 at 07:41, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Peter,
>
> Thanks for giving comments! PSA new version.
Couple of suggestions:
1) How will user know which all transactions should be rolled back
since the prepared transaction name will be different in subscriber
like pg_gid_1
On Sat, Jul 20, 2024 at 03:01:31PM +0300, Nazir Bilal Yavuz wrote:
> On Sat, 20 Jul 2024 at 14:27, Noah Misch wrote:
> >
> > On Thu, Jul 18, 2024 at 02:11:13PM +0300, Nazir Bilal Yavuz wrote:
> > > v4 is attached.
> >
> > Removal of the PinBufferForBlock() comment about the "persistence =
> > RELP
On 2024-07-08 15:56:59 -0700, Andres Freund wrote:
> While looking at this I also found an argument omission present in the commit
> adding meson support. I plan to fix that with the attached commit.
Pushed that portion.
Hi,
On 2024-07-17 09:49:47 -0700, Andres Freund wrote:
> On 2024-07-16 15:53:45 -0500, Tristan Partin wrote:
> > Other than that, it looks pretty solid.
>
> Thanks for looking! I'm thinking of pushing the first few patches soon-ish.
>
> I'm debating between going for 17 + HEAD or also applying
Hi,
I was going through the "needs review" patches with no recent messages,
trying to figure out what is needed to move them forward, and this one
caught my eye because I commented on it before. And it's also a bit sad
example, because it started in 2021 and is moving at glacier speed :-(
I read
On 19.07.2024 01:10, Tom Lane wrote:
Actually, I think we ought to just reject this change. Debian 10
will be two years past EOL before PG 17 ships. So I don't see a
reason to support it in the tests anymore. One of the points of
such testing is to expose broken platforms, not mask them.
Obvi
On 7/20/24 14:09, Jelte Fennema-Nio wrote:
> On Fri, 19 Jul 2024 at 21:48, Tomas Vondra
> wrote:
>>
>>
>>
>> On 7/19/24 17:16, Jelte Fennema-Nio wrote:
>>> That's been moving forward, even relatively fast imho for the
>>> size/impact of that patchset. But those changes are much less
>>> straight-f
19 июля 2024 г., в 04:17, Michael Paquier
написал(а):
On Fri, Jul 12, 2024 at 11:07:49PM +0100, Ilya Gladyshev wrote:
While working on CIC for partitioned tables [1], I noticed that
REINDEX for
partitioned tables is not tracking keeping progress of partitioned
tables,
so I'm creating a se
On Fri, 19 Jul 2024 at 17:24, Ashutosh Bapat
wrote:
> According to [1] these GUCs were added because of increased
> memory consumption during planning and time taken to plan the query.
> The execution time memory consumption issue was known even back then
> but the GUC was not set to default becau
On Sun, 21 Jul 2024 at 04:00, Ahmed Yarub Hani Al Nuaimi
wrote:
> 2- Can you point me to a resource explaining why this might lead to index
> bloating?
No resource links, but if you move a tuple to another page then you
must also adjust the index. If you have no exclusive lock on the
table, the
On Fri, Jul 19, 2024 at 03:44:22PM -0500, Nathan Bossart wrote:
> I've been looking into optimizing pg_upgrade's once-in-each-database steps
> [0], and I noticed that we are opening a connection to every database in
> the cluster and running a query like
>
> SELECT count(*) FROM pg_catalog.p
David Rowley writes:
> No resource links, but if you move a tuple to another page then you
> must also adjust the index. If you have no exclusive lock on the
> table, then you must assume older transactions still need the old
> tuple version, so you need to create another index entry rather than
On 2024/03/07 16:59, Ronan Dunklau wrote:
Le mercredi 6 mars 2024, 20:28:44 CET Stephen Frost a écrit :
I agree that this would generally be a useful thing to have.
Thanks !
Does that seem correct ?
Definitely needs to have a 'REVOKE ALL ON FUNCTION' at the end of the
upgrade script,
Hi hackers.
Recently I came to an issue about logical replicating very big
transactions. Since we already have logical_decoding_work_mem to keep
the memory usage, there is no risk of OOM during decoding. However, the
memory usage still goes out of control in 'Tuples' memory context of
reorder buff
Fujii Masao writes:
>> Le mercredi 6 mars 2024, 20:28:44 CET Stephen Frost a écrit :
>>> I agree that this would generally be a useful thing to have.
Personally, I want to push back on whether this has any legitimate
use-case. Even if the FSM is corrupt, it should self-heal over
time, and I'm no
25 matches
Mail list logo
