doc PG 18 relnotes: update to current, add one commit
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/fa638edc74ee4be90e94a45f8489f3be9a926d7e
Modified Files
--
doc/src/sgml/release-18.sgml | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
doc PG 18 relnotes: indent tag blocks
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/d21cf31f7c3f2657d9396913c5cea91f01a88105
Modified Files
--
doc/src/sgml/release-18.sgml | 4054 --
1 file changed, 2322 insertio
doc PG 18 relnotes: add remaining missing link tags
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/fed7aa8f56064e3e492c9e145a3197128d6abdf7
Modified Files
--
doc/src/sgml/release-18.sgml | 274 +--
1 file changed,
Alexander Korotkov writes:
> And I see the following variable values.
> (lldb) p/x targetPagePtr
> (XLogRecPtr) 0x29004000
> (lldb) p/x RecPtr
> (XLogRecPtr) 0x29002138
> I hardly understand how is this possible given it was compiled with "-O0".
> I'm planning to continue investi
Alexander Korotkov writes:
> I think this indicates unfinished intention to wait for checkpoint
> completion. But I think both cases (checkpoint finished and
> unfinished) should work correctly. So, I believe there is a backend
> problem. I'm trying to reproduce this locally. Sorry for the
> c
On Sat, Jun 21, 2025 at 1:40 AM Alexander Korotkov
wrote:
> On Sat, Jun 21, 2025 at 1:25 AM Tom Lane wrote:
> > I wrote:
> > > But in the buildfarm failures I don't see any 'checkpoint complete'
> > > before the shutdown.
> >
> > Ooops, I lied: we have at least one case where the checkpoint does
On Sat, Jun 21, 2025 at 1:25 AM Tom Lane wrote:
> I wrote:
> > But in the buildfarm failures I don't see any 'checkpoint complete'
> > before the shutdown.
>
> Ooops, I lied: we have at least one case where the checkpoint does
> finish but then it hangs up anyway:
>
> https://buildfarm.postgresql.
I wrote:
> But in the buildfarm failures I don't see any 'checkpoint complete'
> before the shutdown.
Ooops, I lied: we have at least one case where the checkpoint does
finish but then it hangs up anyway:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=melonworm&dt=2025-06-20%2019%3
Melanie Plageman writes:
> Quite a few animals have started failing since this commit (for example
> [1]) . I haven't looked into why, but I suspect something is wrong.
It looks to me like it's being triggered by this questionable bit in
046_checkpoint_logical_slot.pl:
# Continue the checkpoint
Remove planner's have_dangerous_phv() join-order restriction.
Commit 85e5e222b, which added (a forerunner of) this logic,
argued that
Adding the necessary complexity to make this work doesn't seem like
it would be repaid in significantly better plans, because in cases
where such a PHV
Use SnapshotDirty when checking for conflicting index names.
While choosing an autogenerated name for an index, look for
pre-existing relations using a SnapshotDirty snapshot, instead of the
previous behavior that considered only committed-good pg_class rows.
This allows us to detect and avoid con
Use SnapshotDirty when checking for conflicting index names.
While choosing an autogenerated name for an index, look for
pre-existing relations using a SnapshotDirty snapshot, instead of the
previous behavior that considered only committed-good pg_class rows.
This allows us to detect and avoid con
Use SnapshotDirty when checking for conflicting index names.
While choosing an autogenerated name for an index, look for
pre-existing relations using a SnapshotDirty snapshot, instead of the
previous behavior that considered only committed-good pg_class rows.
This allows us to detect and avoid con
Use SnapshotDirty when checking for conflicting index names.
While choosing an autogenerated name for an index, look for
pre-existing relations using a SnapshotDirty snapshot, instead of the
previous behavior that considered only committed-good pg_class rows.
This allows us to detect and avoid con
Use SnapshotDirty when checking for conflicting index names.
While choosing an autogenerated name for an index, look for
pre-existing relations using a SnapshotDirty snapshot, instead of the
previous behavior that considered only committed-good pg_class rows.
This allows us to detect and avoid con
Use SnapshotDirty when checking for conflicting index names.
While choosing an autogenerated name for an index, look for
pre-existing relations using a SnapshotDirty snapshot, instead of the
previous behavior that considered only committed-good pg_class rows.
This allows us to detect and avoid con
On Fri, Jun 20, 2025, 19:10 Melanie Plageman
wrote:
>
> On Thu, Jun 19, 2025 at 7:31 PM Alexander Korotkov <
> akorot...@postgresql.org> wrote:
>
>> Improve runtime and output of tests for replication slots checkpointing.
>>
>> The TAP tests that verify logical and physical replication slot behav
pgxs.mk: remove unreachable rule for deleting regress.def.
We never create regress.def, and if we did this code would fail to
delete it, because "win" is not the correct PORTNAME for Windows.
This thinko seems to have originated in commit 7a6b562fd from 1999,
although it got moved around multiple
On Thu, Jun 19, 2025 at 7:31 PM Alexander Korotkov
wrote:
> Improve runtime and output of tests for replication slots checkpointing.
>
> The TAP tests that verify logical and physical replication slot behavior
> during checkpoints (046_checkpoint_logical_slot.pl and
> 047_checkpoint_physical_slot
19 matches
Mail list logo
