> I've attached an updated patch with that change.
LGTM!
--
Regards,
ChangAo Chen
On Sun, Jul 27, 2025 at 6:56 AM Alvaro Herrera wrote:
>
> Hello,
>
> Here's a patch to add REPACK and eventually the CONCURRENTLY flag to it.
> This is coming from [1]. The ultimate goal is to have an in-core tool
> to allow concurrent table rewrite to get rid of bloat;
+1
> right now, VACUUM
On Sat, Jul 26, 2025 at 6:27 PM cca5507 wrote:
>
> Hi,
>
> The test case seems to have a problem:
>
> We cannot ensure that the SELECT happens after the pg_stat_activity can show
> the logical replication launcher.
Thanks for the review! You're right. We should use poll_query_until()
instead of
On Sat, Jul 26, 2025 at 5:56 PM Alvaro Herrera wrote:
>
> Hello,
>
> Here's a patch to add REPACK and eventually the CONCURRENTLY flag to it.
> This is coming from [1]. The ultimate goal is to have an in-core tool
> to allow concurrent table rewrite to get rid of bloat; right now, VACUUM
> FULL d
On Tue, Jul 22, 2025 at 2:13 PM Andrei Lepikhov wrote:
>
> On 4/6/2025 00:41, Alexander Korotkov wrote:
> > On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov
wrote:
> >> For me, it seems like a continuation of the 7d8ac98 discussion. We may
> >> charge a small fee for MergeAppend to adjust the balan
Hello,
Here's a patch to add REPACK and eventually the CONCURRENTLY flag to it.
This is coming from [1]. The ultimate goal is to have an in-core tool
to allow concurrent table rewrite to get rid of bloat; right now, VACUUM
FULL does that, but it's not concurrent. Users have resorted to using
the
>
>
> >
> > Statistics are transactional. Without this option specified are we
> really
> > removing them and commiting prior to computing and saving new ones? And
> we are
> > opposed to just changing this behavior and instead prefer to add an
> option that
> > at first glance seems like everyon
On 2025-Jul-25, Andrey Borodin wrote:
> Also I've discovered one more serious problem.
> If a backend crashes just before WAL-logging multi, any heap tuple
> that uses this multi will become unreadable. Any attempt to read it
> will hang forever.
>
> I've reproduced the problem and now I'm workin
On Sat, Jul 26, 2025 at 07:47:47AM -0700, David G. Johnston wrote:
> On Sat, Jul 26, 2025, 07:23 Bruce Momjian wrote:
>
> On Wed, Jul 23, 2025 at 02:45:10PM +0200, Frédéric Yhuel wrote:
> >
> >
> > On 3/18/25 22:37, Nathan Bossart wrote:
> > > Committed with the following smal
On Sat, Jul 26, 2025, 07:23 Bruce Momjian wrote:
> On Wed, Jul 23, 2025 at 02:45:10PM +0200, Frédéric Yhuel wrote:
> >
> >
> > On 3/18/25 22:37, Nathan Bossart wrote:
> > > Committed with the following small changes:
> >
> > Hi, I don't really understand this sentence in
> > doc/src/sgml/ref/vacu
On Wed, Jul 23, 2025 at 02:45:10PM +0200, Frédéric Yhuel wrote:
>
>
> On 3/18/25 22:37, Nathan Bossart wrote:
> > Committed with the following small changes:
>
> Hi, I don't really understand this sentence in
> doc/src/sgml/ref/vacuumdb.sgml:
>
> > This option prevents vacuumdb from deleting ex
Completely rewritten version of prefetch patch.
Now prefetch workers do not try to apply LR application and then
rollback transaction.
They just perform indexes lookup and so prefetch index and referenced
heap pages.
So no any hacks are needed to prevent lock conflicts and WAL logging.
Perform
On Sat, Jul 26, 2025 at 5:49 AM Tom Lane wrote:
> Pushed the larger patchset now. I had to do a little more work
> to get it to play with 112faf137, but it wasn't hard.
Thanks for working on this!
Best regards,
Etsuro Fujita
On Fri, Jul 25, 2025 at 7:59 PM Ashutosh Bapat
wrote:
> On Fri, Jul 25, 2025 at 3:22 PM Etsuro Fujita wrote:
> > On Thu, Jul 24, 2025 at 12:06 AM Ashutosh Bapat
> > wrote:
> > > On Wed, Jul 23, 2025 at 4:16 PM Etsuro Fujita
> > > wrote:
> > > > On Tue, Jul 15, 2025 at 4:55 PM Etsuro Fujita
>
Hey pgsql hackers
This is my first email to this list. I'm reaching out about a possible doc
update for the log_statement parameter.
Here's the current doc -
https://www.postgresql.org/docs/current/runtime-config-logging.html
The doc already has a Note bubble for the log_statement parameter with so
Hi,
The test case seems to have a problem:
We cannot ensure that the SELECT happens after the pg_stat_activity can
show the logical replication launcher.
With the following patch the test will fail (without the patch it may happen
very rarely):
diff --git a/src/backend/replication/logical
Hello Kuroda-san and Takatsuka-san,
24.07.2025 03:49, TAKATSUKA Haruka wrote:
{snip}
Maybe you could try tools.syncTime = "0" by any chance?
It has been already tools.syncTime = "0" so far.
I confirmed the following GUI setting.
...
23.07.2025 09:15, Hayato Kuroda (Fujitsu) wrote:
It looks
On 2025/07/26 9:29, Michael Paquier wrote:
On Sat, Jul 26, 2025 at 12:26:21AM +0900, Hironobu SUZUKI wrote:
Even when using EXPLAIN ANALYZE with TIMING=FALSE, the functions
InstrStopNode(), InstrEndLoop(), and InstrAggNode() in Instrument.c still
execute code related to the "starttime", "counter
Hi.
I've updated patches for asynchronous merge append. They allowed us to
significantly improve performance in practice. Earlier select from
partitioned (and distributed table) could switch to synchronous merge
append plan from asynchronous append. Given that table could have 20+
partitions,
19 matches
Mail list logo
