Hi,
I like the idea of your change as it saves me out of converting-in-my-mind.
And I suggest to create a macro to do this job.
#define getRmgrInfo(info) (info & XLR_RMGR_INFO_MASK)
Then the code can become:
XLogRecGetInfo(record) & ~XLR_INFO_MASK;
-->
getRmgrInfo(XLogRecGetInfo(record)
Hi,
I refactored the code of extracting XLogRecord info.
In XLogRecord, the high 4 bits in xl_info is used by rmgr.
typedef struct XLogRecord
{
uint32 xl_tot_len; /* total len of entire record */
TransactionId xl_xid; /* xact id */
XLogRecPtr xl_prev;/* ptr to p
Hello Peter,
06.06.2025 19:33, Peter Geoghegan wrote:
On Wed, Jun 4, 2025 at 1:39 PM Peter Geoghegan wrote:
My current plan is to commit this in the next couple of days.
Pushed.
Please look at the following script, which falsifies an assertion
introduced with e6eed40e4:
create user u;
grant
On Wed, 4 Jun 2025 at 16:12, Ajin Cherian wrote:
>
> On Tue, May 20, 2025 at 2:33 AM Shlok Kyal wrote:
> >
> > This approach seems better to me. I have created a patch with the
> > above approach.
> >
> > Thanks and Regards,
> > Shlok Kyal
>
> Some quick comments on the patch:
> 1. In doc/src/sgm
ne 8. 6. 2025 v 23:49 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > Is there some description of what keywords should be reserved? If I
> > remember correctly, the scanner was changed more times, and maybe more
> > reserved keywords are not necessary.
>
> Per the comment in pl_scanner.
Hi,
On Mon, Jun 9, 2025 at 12:52 PM Xuneng Zhou wrote:
>
> Hi,
>
> > Please find attached Version 2, incorporating the suggested changes.
>
> Apologies for the confusion — in the previous attempt, I mistakenly
> named the patch file with a `0002-` prefix, thinking it reflected the
> patch version
Hi,
> Please find attached Version 2, incorporating the suggested changes.
Apologies for the confusion — in the previous attempt, I mistakenly
named the patch file with a `0002-` prefix, thinking it reflected the
patch version rather than the patch series number. I've corrected the
filename to f
Dear Fujii-san,
> I agree with Peter. I don't think patches 0002 and 0003 are necessary.
>
> As for 0004, it adds tests for the short options -? and -V, which
> duplicate the existing tests for the long options --help and --version.
> I'm not sure it's worth adding tests just to confirm that the
ne 8. 6. 2025 v 23:09 odesílatel Tom Lane napsal:
> I wrote:
> > I think your patch is about the right thing to do, although I'm
> > inclined to check for K_VERS_1_14 which is closer to when the
> > fix was made.
>
> Pushed. After thinking about how to rewrite the comment, I went
> with the vers
On Thu, Jun 5, 2025 at 4:47 AM Robert Treat wrote:
>
> I think some of those changes are worth a second stab, so here is an
> updated patch which removes the ancillary tagging and corresponding
> line wrappings and focuses just on the wording/grammer improvements;
> hopefully it will be easier to
Hi all,
While hacking a different patch, I've noticed that a couple of %llu
did not get the PRIu64 call in the AIO code, and I don't see why we
could not switch them. These have been introduced in commits that got
into the tree after Peter's 15a79c73111f.
A couple remain even after the attached,
On Sat, Jun 7, 2025 at 2:44 AM Masahiko Sawada wrote:
>
> On Fri, Jun 6, 2025 at 3:02 AM shveta malik wrote:
> >
> > On Wed, Jun 4, 2025 at 3:40 PM shveta malik wrote:
> > >
> > > On Wed, Jun 4, 2025 at 6:41 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Tue, May 20, 2025 at 9:54 PM Amit K
Hi Fujii-san,
Thanks for reviewing.
> On 2025/06/09 7:41, Michael Paquier wrote:
> > On Sun, Jun 08, 2025 at 10:30:45PM +0800, Xuneng Zhou wrote:
> >> This is more problematic in logical replication scenarios where these
> >> waits can be very long - for example, when creating a logical
> >> rep
Just CC.
On Mon, Jun 9, 2025 at 10:57 AM Xuneng Zhou wrote:
>
> Hi Michael,
>
> Thanks for reviewing.
>
> On Mon, Jun 9, 2025 at 6:41 AM Michael Paquier wrote:
>
> > + pgstat_report_wait_start(WAIT_EVENT_XACT_DONE);
> > [...]
> > + pgstat_report_wait_start(WAIT_EVENT_XACT_DONE);
> >
> >
On 2025/06/09 7:41, Michael Paquier wrote:
On Sun, Jun 08, 2025 at 10:30:45PM +0800, Xuneng Zhou wrote:
This is more problematic in logical replication scenarios where these
waits can be very long - for example, when creating a logical
replication slot on a busy system. Without a specific wai
On Sun, 8 Jun 2025 at 21:41, Junwang Zhao wrote:
> The comments of TidRangeEval saids:
>
> ```
> Returns false if we detect the range cannot contain any tuples.
> ```
>
> After narrowing the upper and lower bounds, we can add an
> additional check to verify if the lower bound exceeds the
> upper b
On Mon, 9 Jun 2025 at 06:53, Robert Treat wrote:
>
> On Sat, Jun 7, 2025 at 9:17 PM David Rowley wrote:
> > What are your thoughts on cached plans? In this scenario, do you
> > assume that waiting a few days means that connections get reset and
> > prepared statements will have been replanned? Or
On Sat, Jun 7, 2025 at 6:47 AM Andres Freund wrote:
> On 2025-06-06 14:03:12 +0300, Konstantin Knizhnik wrote:
> > There is really essential difference in code generated by clang 15 (working)
> > and 16 (not working).
>
> There also are code gen differences between upstream clang 17 and apple's
>
On Sun, Jun 08, 2025 at 10:30:45PM +0800, Xuneng Zhou wrote:
> This is more problematic in logical replication scenarios where these
> waits can be very long - for example, when creating a logical
> replication slot on a busy system. Without a specific wait event, it's
> hard to distinguish legitim
On 6/8/25 14:39, Arseniy Mukhin wrote:
> Hi,
>
> Here is a new version.
>
> TAP tests were added. Tried to reproduce more or less every violation.
> I don't include 2 tests where disk representation ItemIdData needs to
> be changed: it works locally, but I don't think these tests are
> portable.
On 5/29/25 13:53, Arseniy Mukhin wrote:
> On Mon, May 26, 2025 at 7:28 PM Arseniy Mukhin
> wrote:
>> On Mon, May 26, 2025 at 1:27 PM Tomas Vondra wrote:
>>> Also, I've noticed that the TAP test passes even with some (most) of the
>>> verify_gin.c changes reverted. See the 0002 patch - this does n
Pavel Stehule writes:
> Is there some description of what keywords should be reserved? If I
> remember correctly, the scanner was changed more times, and maybe more
> reserved keywords are not necessary.
Per the comment in pl_scanner.c:
* We try to avoid reserving more keywords than we have to;
I wrote:
> I think your patch is about the right thing to do, although I'm
> inclined to check for K_VERS_1_14 which is closer to when the
> fix was made.
Pushed. After thinking about how to rewrite the comment, I went
with the version test as you had it. K_VERS_1_14 isn't really
better, since i
Pavel Stehule writes:
> It is a problem of PostgreSQL 11 - the pg_dump from PostgreSQL 12 sets
> filename correctly,
> and pg_restore doesn't need patching (in this case).
Yeah. It looks like the actual filename was always "blobs.toc" before
v17, but prior to 548e50976 pg_backup_directory.c's _A
Hi
>
>> 2. That "has no field" error message is flat-out wrong. The now-known
>> way to trigger it has a different cause, and what's more, we simply do
>> not know at this point whether the malleable record type has such a
>> field. So in 0002 below I just changed it to assume that the problem
Andres Freund writes:
> The symptoms I can reproduce are slightly different than Alexander's - it's
> the assertion failure reported upthread by Tom.
>
> FWIW, I can continue to repro the assertion after removing the use of the
> bitfield in PgAioHandle. So the problem indeed seems to be be indepe
Hi
> The problem is related to the commit a45c78e
>
> I am not sure if this is correct fix, but it fixed this issue
>
> diff --git a/src/bin/pg_dump/pg_backup_directory.c
> b/src/bin/pg_dump/pg_backup_directory.c
> index 21b00792a8a..16da4decbd0 100644
> --- a/src/bin/pg_dump/pg_backup_directory
Hi,
On 2025-06-06 15:37:45 -0400, Andres Freund wrote:
> There shouldn't be any concurrent accesses here, so I don't really see how the
> above would explain the problem (the IO can only ever be modified by one
> backend, initially the "owning backend", then, when submitted, by the IO
> worker, an
Hi
ne 8. 6. 2025 v 14:39 odesílatel Pavel Stehule
napsal:
> Hi,
>
> one customer reported an issue related probably to pg_restore and
> dictionary format.
>
> Inside PostgreSQL 11 I created one large object
>
> I used pg_dump (version 11) and did dump a) dictionary format, b) tar
> format
>
> I
On Sat, Jun 7, 2025 at 9:17 PM David Rowley wrote:
> On Sun, 8 Jun 2025 at 01:35, Robert Treat wrote:
> > On Fri, Jun 6, 2025 at 8:04 PM David Rowley wrote:
> > > Can you list your proposed series of steps you'd recommend to a DBA
> > > wishing to remove an index, assuming this feature exists in
hi.
some more minor comments about v13-0001.
GetCommandLogLevel also needs to specify LogStmtLevel for T_RepackStmt?
/*
* (CLUSTER might change the order of
* rows on disk, which could affect the ordering of pg_dump
* output, but that's not semantically significant.)
*/
do we need adjust this
Dear Kuroda-san, hackers,
On 2025/06/04 21:57, Hayato Kuroda (Fujitsu) wrote:
Dear Ikeda-san,
Thanks for starting the new thread! I have never known the issue before I heard
at
PGConf.dev.
Few comments:
1.
This parameter seems a type of benchmark option. So should we set
benchmarking_option
Hi,
> Thanks for the patch! I haven't reviewed it yet, but since this is
> a v19 item, please add it to the next CommitFest so we don't lose
> track of it.
>
> Also, I think it would be better to split the addition of the wait event
> and the introduction of exponential backoff in XactLockTableWai
Hi hackers,
This patch implements progressive backoff in XactLockTableWait() and
ConditionalXactLockTableWait().
As Kevin reported in this thread [1], XactLockTableWait() can enter a
tight polling loop during logical replication slot creation on standby
servers, sleeping for fixed 1ms intervals t
Hi hackers,
Currently, when XactLockTableWait() and ConditionalXactLockTableWait()
sleep waiting for transactions to complete, they don't report any
specific wait event to the statistics system. This means that backends
stuck in these waits show up in pg_stat_activity with NULL
wait_event_type and
Hi,
one customer reported an issue related probably to pg_restore and
dictionary format.
Inside PostgreSQL 11 I created one large object
I used pg_dump (version 11) and did dump a) dictionary format, b) tar format
I will try to restore these files in PostgreSQL 18 with pg_restore (version
18).
Hi,
Here is a new version.
TAP tests were added. Tried to reproduce more or less every violation.
I don't include 2 tests where disk representation ItemIdData needs to
be changed: it works locally, but I don't think these tests are
portable. While writing tests some minor issues were found and fi
Hi Cary,
On Fri, Jun 6, 2025 at 5:24 AM Cary Huang wrote:
>
> Hello
>
> Sorry David and all who have reviewed the patch, it's been awhile since the
> patch
> was last worked on :(. Thank you all for the reviews and comments! Attached is
> the rebased patch that adds support for parallel TID rang
Hi hackers,
The comments of TidRangeEval saids:
```
Returns false if we detect the range cannot contain any tuples.
```
After narrowing the upper and lower bounds, we can add an
additional check to verify if the lower bound exceeds the
upper bound. If true, return false to avoid unnecessary call
On Thu, Jun 5, 2025 at 7:40 PM Etsuro Fujita wrote:
> I will revert this in a few days.
Done.
Best regards,
Etsuro Fujita
40 matches
Mail list logo
