On Tue, May 07, 2024 at 02:06:10PM -0700, Jacob Champion wrote:
> Maybe I've misunderstood, but isn't that what's being done in v2?
Something a bit different.. I was wondering if it could be possible
to tweak this code to truncate the data in the generated error string
so as the incomplete
On Mon, May 06, 2024 at 06:55:46PM +0300, m.litsa...@postgrespro.ru wrote:
> as a first step I have introduced the `SharedRecoveryDataFlags` bitmask
> instead of three boolean SharedHotStandbyActive, SharedPromoteIsTriggered
> and SharedStandbyModeRequested flags (the last one from my previous
Hi, Bharath. I've been testing this. It's cool. Is there any way we could
monitor the hit rate about directly reading from WAL buffers by exporting
to some views?
---
Regards, Jingtang
On Wed, May 1, 2024 at 4:29 PM John Naylor wrote:
>
> On Thu, Apr 25, 2024 at 8:36 AM Masahiko Sawada wrote:
> >
> > On Mon, Apr 15, 2024 at 6:12 PM John Naylor wrote:
>
> > > - RT_KEY_GET_SHIFT is not covered for key=0:
> > >
> > >
On Tue, May 07, 2024 at 02:39:42PM -0500, Nathan Bossart wrote:
> Okay, phew. We can still do something like v3-0002 for v18. I'll give
> Michael a chance to comment on 0001 before committing/back-patching that
> one.
What you are doing in 0001, and 0002 for v18 sounds fine to me.
--
Michael
On Tue, May 07, 2024 at 02:07:42PM -0500, Tristan Partin wrote:
> On Tue May 7, 2024 at 1:29 PM CDT, Andres Freund wrote:
>> I think it's a good idea. I'd really like to allow extensions to register new
>> types of stats eventually. Stuff like pg_stat_statements having its own,
>> fairly ...
On Wed, May 8, 2024 at 6:54 AM Justin Pryzby wrote:
> On Tue, May 07, 2024 at 10:55:28AM +1200, Thomas Munro wrote:
> > https://github.com/openzfs/zfs/issues/11641
> >
> > I don't know enough to say anything useful about that but it certainly
> > smells similar...
>
> Wow - I'd completely
On Tue, May 07, 2024 at 07:27:54AM -0500, Justin Pryzby wrote:
> This didn't get fixed for v16, and it seems unlikely that it'll be
> addressed in back branches.
>
> But while I was reviewing forgotten threads, it occurred to me to raise
> the issue in time to fix it for v17.
Thanks for the
On Tue, May 07, 2024 at 12:36:24PM +0200, Daniel Gustafsson wrote:
> Fair enough. I've taken a stab at documenting that the functions are
> deprecated, while at the same time documenting when and how they can be used
> (and be useful). The attached also removes one additional comment in the
>
Hi, Here are some review comments for patch v6-0001
==
Commit message
1.
This patch allows user to alter two_phase option
/allows user/allows the user/
/to alter two_phase option/to alter the 'two_phase' option/
==
doc/src/sgml/ref/alter_subscription.sgml
2.
two_phase can be altered
David Rowley writes:
> On Wed, 8 May 2024 at 10:55, Tom Lane wrote:
>> Not in a way that gives me any confidence that we found *all* the
>> problems.
> Here are some statements I believe to be true:
> 1. If REALLOCATE_BITMAPSETS is defined then modifications to a
> Bitmapset will make a copy
On Wed, 8 May 2024 at 10:55, Tom Lane wrote:
>
> David Rowley writes:
> > REALLOCATE_BITMAPSETS was invented for this and IMO, it found exactly
> > the problem it was invented to find.
>
> Not in a way that gives me any confidence that we found *all* the
> problems.
Here are some statements I
David Rowley writes:
> On Wed, 8 May 2024 at 10:40, Tom Lane wrote:
>> Didn't test, but that route seems awfully invasive and fragile: how
>> will we find all the places to modify, or ensure that the policy
>> is followed by future patches?
> REALLOCATE_BITMAPSETS was invented for this and IMO,
On Wed, 8 May 2024 at 10:40, Tom Lane wrote:
>
> David Rowley writes:
> > We could make the policy copy-on-modify. If you put bms_copy around
> > the bms_del_member() calls in remove_rel_from_query(), does it pass
> > then?
>
> Didn't test, but that route seems awfully invasive and fragile: how
David Rowley writes:
> On Wed, 8 May 2024 at 06:20, Tom Lane wrote:
>> I find that Richard's proposed fix makes the core regression tests
>> pass, but we still fail check-world. So I'm afraid we need something
>> more aggressive, like the attached which makes make_restrictinfo
>> copy all its
On Wed, 8 May 2024 at 10:35, David Rowley wrote:
>
> On Wed, 8 May 2024 at 06:20, Tom Lane wrote:
> > I find that Richard's proposed fix makes the core regression tests
> > pass, but we still fail check-world. So I'm afraid we need something
> > more aggressive, like the attached which makes
On Wed, 8 May 2024 at 06:20, Tom Lane wrote:
> I find that Richard's proposed fix makes the core regression tests
> pass, but we still fail check-world. So I'm afraid we need something
> more aggressive, like the attached which makes make_restrictinfo
> copy all its input bitmapsets. Without
On Tue, May 07, 2024 at 11:53:10AM -0700, Noah Misch wrote:
> On Tue, May 07, 2024 at 10:17:49AM +0900, Michael Paquier wrote:
> > Overall, this switches from one detach behavior to a different one,
>
> Can you say more about that? The only behavior change known to me is that a
> given injection
On Tue, May 07, 2024 at 10:31:00AM -0400, Robert Haas wrote:
> On Wed, May 1, 2024 at 10:03 PM David Rowley wrote:
>> I think we need at least 1a) before we can give autovacuum more work
>> to do, especially if we do something like multiply its workload by
>> 1024x, per your comment above.
>
> I
On Mon, May 6, 2024 at 8:43 PM Michael Paquier wrote:
> On Fri, May 03, 2024 at 07:05:38AM -0700, Jacob Champion wrote:
> > We could port something like that to src/common. IMO that'd be more
> > suited for an actual conversion routine, though, as opposed to a
> > parser that for the most part
On 30.04.24 12:59, Ashutosh Bapat wrote:
PFA patch which fixes all the three problems.
I have committed this patch. Thanks all.
Hi again!
Made an error in `GlobalVisHorizonKindForRel` logic, and it was caught by a
new test.
Fixed version in attach.
>
From 9a8ea366f6d2d144979e825c4ac0bdd2937bf7c1 Mon Sep 17 00:00:00 2001
From: nkey
Date: Tue, 7 May 2024 22:10:56 +0200
Subject: [PATCH v3] WIP: fix d9d076222f5b "VACUUM:
On Mon, May 6, 2024 at 4:30 PM Peter Geoghegan wrote:
> FWIW I always found those weird inconsistencies to be annoying at
> best, and confusing at worst. I speak as somebody that uses
> disable_cost a lot.
>
> I certainly wouldn't ask anybody to make it a priority for that reason
> alone -- it's
On Tue, May 07, 2024 at 03:02:01PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Tue, May 07, 2024 at 01:44:16PM -0400, Tom Lane wrote:
>>> +1 to include that, as it offers a defense if someone invokes this
>>> function directly. In HEAD we could then rip out the test in the
>>> view.
>
On Tue May 7, 2024 at 1:29 PM CDT, Andres Freund wrote:
Hi,
On 2024-05-06 14:07:53 -0500, Tristan Partin wrote:
> Instead of needing to be explicit, we can just iterate the
> pgstat_kind_infos array to find the memory locations to read into.
> This was originally thought of by Andres in
>
Nathan Bossart writes:
> On Tue, May 07, 2024 at 01:44:16PM -0400, Tom Lane wrote:
>> +1 to include that, as it offers a defense if someone invokes this
>> function directly. In HEAD we could then rip out the test in the
>> view.
> I apologize for belaboring this point, but I don't see how we
On Tue, May 07, 2024 at 10:55:28AM +1200, Thomas Munro wrote:
> On Tue, May 7, 2024 at 6:21 AM Justin Pryzby wrote:
> > FWIW: both are running zfs-2.2.3 RPMs from zfsonlinux.org.
> ...
> > Yes, they're running centos7 with the indicated kernels.
>
> So far we've got:
>
> * spurious EIO when
On Tue, May 07, 2024 at 10:17:49AM +0900, Michael Paquier wrote:
> On Mon, May 06, 2024 at 02:23:24PM -0700, Noah Misch wrote:
> > Here's how I've patched it locally. It does avoid changing the
> > backend-side,
> > which has some attraction. Shall I just push this?
>
> It looks like you did
On Tue, May 07, 2024 at 01:44:16PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> char relpersist = seqrel->rd_rel->relpersistence;
>
>> if (relpersist == RELPERSISTENCE_PERMANENT ||
>> (relpersist == RELPERSISTENCE_UNLOGGED &&
>> !RecoveryInProgress()) ||
>>
Hi,
On 2024-05-06 14:07:53 -0500, Tristan Partin wrote:
> Instead of needing to be explicit, we can just iterate the
> pgstat_kind_infos array to find the memory locations to read into.
> This was originally thought of by Andres in
> 5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd.
>
> Not a fix, per
Andrew Dunstan writes:
> On 2024-05-07 Tu 06:05, Richard Guo wrote:
>> +1 to have build farm coverage of REALLOCATE_BITMAPSETS. This flag
>> seems quite useful.
> I have added it to the CPPFLAGS on prion.
... and as expected, prion fell over.
I find that Richard's proposed fix makes the core
On Mon, May 06, 2024 at 11:09:24PM -0400, Jonathan S. Katz wrote:
> * Avoid leaking a query result from
> [`psql`](https://www.postgresql.org/docs/current/app-psql.html)
> after the query is cancelled.
I'd delete this item about a psql-lifespan memory leak, because (a) it's so
minor and (b)
> On May 7, 2024, at 05:02, Amit Kapila wrote:
>
>
> In PG-14, we have added a feature in logical replication to stream
> long in-progress transactions which should reduce spilling to a good
> extent. You might want to try that.
That's been my principal recommendation (since that would also
On Tue May 7, 2024 at 1:01 AM CDT, Michael Paquier wrote:
On Tue, May 07, 2024 at 12:44:51AM -0500, Tristan Partin wrote:
> Thanks for the feedback Michael. Should I just throw the patch in the next
> commitfest so it doesn't get left behind?
Better to do so, yes. I have noted this thread in
Nathan Bossart writes:
> Okay, so are we okay to back-patch something like v1? Or should we also
> return NULL for other sessions' temporary schemas on primaries? That would
> change the condition to something like
> char relpersist = seqrel->rd_rel->relpersistence;
> if
On Sat, May 04, 2024 at 06:45:32PM +0900, Michael Paquier wrote:
> On Fri, May 03, 2024 at 05:22:06PM -0400, Tom Lane wrote:
>> Nathan Bossart writes:
>>> IIUC this would cause other sessions' temporary sequences to appear in the
>>> view. Is that desirable?
>>
>> I assume Michael meant to move
On 5/7/24 08:23, David G. Johnston wrote:
On Tue, May 7, 2024 at 7:54 AM Bruce Momjian mailto:br...@momjian.us>> wrote:
In the two marked lines, it says "if one side of the foreign key uses
PERIOD, the other side must too." However, looking at the example
queries, it seems like if
On Fri, May 03, 2024 at 12:57:18PM +, Imseih (AWS), Sami wrote:
>> That's true, but using a hard-coded limit means we no longer need to add a
>> new GUC. Always allocating, say, 256 slots might require a few additional
>> kilobytes of shared memory, most of which will go unused, but that seems
On Tue, May 7, 2024 at 7:54 AM Bruce Momjian wrote:
> In this commit:
>
> commit 34768ee3616
> Author: Peter Eisentraut
> Date: Sun Mar 24 07:37:13 2024 +0100
>
> Add temporal FOREIGN KEY contraints
>
> Add PERIOD clause to foreign key
In this commit:
commit 34768ee3616
Author: Peter Eisentraut
Date: Sun Mar 24 07:37:13 2024 +0100
Add temporal FOREIGN KEY contraints
Add PERIOD clause to foreign key constraint definitions. This is
supported for
I wrote:
> I think this may be a bug in -l mode: ProcessArchiveRestoreOptions
> saves the result of _tocEntryRequired in te->reqs, but PrintTOCSummary
> doesn't, and that will bollix its subsequent _tocEntryRequired checks
> for "dependent" TOC entries.
Yeah ... the attached seems to fix it.
On Wed, May 1, 2024 at 10:03 PM David Rowley wrote:
> Here are some of the problems that I know about:
>
> 1. Autovacuum has exactly zero forward vision and operates reactively
> rather than proactively. This "blind operating" causes tables to
> either not need vacuumed or suddenly need vacuumed
Robert Haas writes:
> Never mind all this. I think what I have in mind requires doing what
> you did first. So if you're happy with what you've got, I'd go for it.
OK. HEAD-only sounds like a good compromise. Barring objections,
I'll do that later today.
regards, tom
Robert Haas writes:
> On Mon, May 6, 2024 at 7:31 PM Tom Lane wrote:
>> So maybe this is not really worth fixing. Thoughts?
> Hmm, I thought the RLS condition needed to accept the old and new
> TIDs, but not (InvalidBlockNumber,0). I might well have misunderstood,
> though.
If you leave the
On Tue, May 7, 2024 at 9:47 AM Robert Haas wrote:
> As to whether this is worth fixing, I think it is, but it might not be
> worth back-patching the fix. Also, I'd really like to get disable_cost
> out of the picture here. That would require more code reorganization
> than you've done here, but I
Justin Pryzby writes:
> pg_dump -Fc |pg_restore -l -N schema:
> | 2; 3079 18187 EXTENSION - pg_buffercache
> Without -N schema also shows:
> | 2562; 0 0 COMMENT - EXTENSION pg_buffercache
Hmm, but what happens if you actually do the restore?
I think this may be a bug in -l mode:
On Mon, May 6, 2024 at 7:31 PM Tom Lane wrote:
> Robert pointed out [1] that the planner fails if we have $SUBJECT,
> because tidpath.c can seize on the RLS-derived ctid constraint
> instead of the CurrentOfExpr. Since the executor can only handle
> CurrentOfExpr in a TidScan's tidquals, that
Hi,
Nazir Bilal Yavuz wrote:
>Any kind of feedback would be appreciated.
I know it's coming from copy-and-paste, but
I believe the flags could be:
- dstfd = OpenTransientFile(tofile, O_RDWR | O_CREAT | O_EXCL | PG_BINARY);
+ dstfd = OpenTransientFile(tofile, O_CREAT | O_WRONLY | O_TRUNC |
Hello, Matthias and others!
Updated WIP in attach.
Changes are:
* Renaming, now it feels better for me
* More reliable approach in `GlobalVisHorizonKindForRel` to make sure we
have not missed `rd_safeindexconcurrentlybuilding` by calling
`RelationGetIndexList` if required
* Optimization to avoid
pg_dump -Fc |pg_restore -l -N schema:
| 2; 3079 18187 EXTENSION - pg_buffercache
Without -N schema also shows:
| 2562; 0 0 COMMENT - EXTENSION pg_buffercache
I mean literal s-c-h-e-m-a, but I suppose anything else will work the
same.
BTW, I noticed that pg_restore -v shows that duplicate
On Sat, Jan 21, 2023 at 02:45:40AM +0100, Matthias van de Meent wrote:
> > Would you do anything different in the master branch, with no
> > compatibility constraints ? I think the progress reporting would still
> > be limited to one row per backend, not one per CopyFrom().
>
> I think I would
On Tue, May 7, 2024 at 9:51 AM Ashutosh Bapat
wrote:
>
> On Tue, May 7, 2024 at 12:00 AM Christophe Pettus wrote:
>>
>> Thank you for the reply!
>>
>> > On May 1, 2024, at 02:18, Ashutosh Bapat
>> > wrote:
>> > Is there a large transaction which is failing to be replicated repeatedly
>> > -
On Tue, Apr 30, 2024 at 11:28 PM Christophe Pettus wrote:
>
> I wanted to check my understanding of how control flows in a walsender doing
> logical replication. My understanding is that the (single) thread in each
> walsender process, in the simplest case, loops on:
>
> 1. Pull a record out
On 2024-05-07 Tu 06:05, Richard Guo wrote:
On Tue, May 7, 2024 at 1:22 PM David Rowley wrote:
It would be good to get some build farm coverage of this so we don't
have to rely on manual testing. I wonder if it's a good idea to just
define REALLOCATE_BITMAPSETS when #ifdef
Hi,
On Wed, 6 Mar 2024 at 05:17, Thomas Munro wrote:
>
> The main thing that is missing is support for redo. It's mostly
> trivial I think, probably just a record type for "try cloning first"
> and then teaching that clone function to fall back to the regular copy
> path if it fails in
On Tue, May 7, 2024 at 8:29 AM Tom Lane wrote:
> David Rowley writes:
> > Yeah, before the revert, that did:
> > - sjinf->syn_lefthand = replace_relid(sjinf->syn_lefthand, relid,
> > subst);
> > That replace code seems to have always done a bms_copy()
>
> Hmm, not always; see e0477837c.
>
On Tue, May 7, 2024 at 1:19 PM Richard Guo wrote:
> On Tue, May 7, 2024 at 1:46 PM David Rowley wrote:
>>
>> On Tue, 7 May 2024 at 17:28, Tom Lane wrote:
>> > What I'm trying to figure out here is whether we have a live bug
>> > in this area in released branches; and if so, why we've not seen
Hi PostgreSQL Community,
I would like to bring to your attention an observation regarding the
planner's behavior for foreign table update/delete operations. It appears
that the planner adds rowmarks (ROW_MARK_COPY) for non-target tables, which
I believe is unnecessary when using the postgres-fdw.
> On 7 May 2024, at 01:31, Michael Paquier wrote:
>
> On Fri, May 03, 2024 at 10:39:15AM +0200, Daniel Gustafsson wrote:
>> They are no-ops when linking against v18, but writing an extension which
>> targets all supported versions of postgres along with their respective
>> supported OpenSSL
On Tue, May 7, 2024 at 1:46 PM David Rowley wrote:
> On Tue, 7 May 2024 at 17:28, Tom Lane wrote:
> > What I'm trying to figure out here is whether we have a live bug
> > in this area in released branches; and if so, why we've not seen
> > reports of that.
>
> We could check what portions of
On Tue, May 7, 2024 at 1:22 PM David Rowley wrote:
> It would be good to get some build farm coverage of this so we don't
> have to rely on manual testing. I wonder if it's a good idea to just
> define REALLOCATE_BITMAPSETS when #ifdef CLOBBER_FREED_MEMORY... or if
> we should ask on the
Hello,
At Wed, 1 May 2024 19:49:35 +0200, Alvaro Herrera
wrote in
> Here are two patches that I intend to push soon (hopefully tomorrow).
This commit added and edited two error messages, resulting in using
slightly different wordings "in" and "on" for relation constraints.
+ errmsg("cannot
Hi Tom and -hackers!
On Thu, Mar 28, 2024 at 7:36 PM Tom Lane wrote:
>
> Jakub Wartak writes:
> > While chasing some other bug I've learned that backtrace_functions
> > might be misleading with top elog/ereport() address.
>
> That was understood from the beginning: this type of backtrace is
>
Hi, Alexander!
On 06.05.2024 13:19, Alexander Korotkov wrote:
The patch attached fix the 010_tab_completion.pl test in the same way like [1].
Thank you for the fix. As I get, the fix teaches
010_tab_completion.pl to tolerate the invalid result of tab
completion. Do you think we could fix it
On Tue, May 07, 2024 at 12:44:51AM -0500, Tristan Partin wrote:
> Thanks for the feedback Michael. Should I just throw the patch in the next
> commitfest so it doesn't get left behind?
Better to do so, yes. I have noted this thread in my TODO list, but
we're a couple of weeks away from the next
65 matches
Mail list logo
