Hi,
As most will know by now, the way xz debacle was able to make sshd vulnerable
was through a dependency from sshd to libsystemd and then from libsystemd to
liblzma. One lesson from this is that unnecessary dependencies can still
increase risk.
It's worth noting that we have an optional
On Wed, Apr 3, 2024 at 7:55 PM Alvaro Herrera wrote:
>
> On 2024-Apr-03, Alexander Korotkov wrote:
>
> > Regarding the shmem data structure for LSN waiters. I didn't pick
> > LWLock or ConditionVariable, because I needed the ability to wake up
> > only those waiters whose LSN is already
On Wed, Apr 3, 2024 at 11:13 AM Tom Lane wrote:
> wikipedia says that RHEL7 ends ELS as of June 2026 [1].
I may have misunderstood something in here then:
https://www.redhat.com/en/blog/announcing-4-years-extended-life-cycle-support-els-red-hat-enterprise-linux-7
> ELS for RHEL 7 is now
On Wed, Apr 3, 2024 at 8:29 AM Tom Lane wrote:
> I count 3 machines running 1.0.1, 18 running some flavor
> of 1.0.2, and 7 running various LibreSSL versions.
I don't know all the tradeoffs with buildfarm wrangling, but IMO all
those 1.0.2 installations are the most problematic, so I dug in a
Jacob Champion writes:
> On Wed, Apr 3, 2024 at 10:38 AM Tom Lane wrote:
>> Bottom line for me is that pulling 1.0.1 support now is OK,
>> but I think pulling 1.0.2 is premature.
> Okay, but IIUC, waiting for it to drop out of extended support means
> we deal with it for four more years. That
>
>
> As far as that goes, it shouldn't be that hard to deal with, at least
> not for "soft" errors which hopefully cover most input-function
> failures these days. You should be invoking array_in via
> InputFunctionCallSafe and passing a suitably-set-up ErrorSaveContext.
> (Look at
Hi Jakub,
Thank you for looking into this and doing a performance analysis.
On Wed, 3 Apr 2024 at 11:42, Jakub Wartak wrote:
>
> On Tue, Apr 2, 2024 at 9:24 AM Nazir Bilal Yavuz wrote:
> [..]
> > v4 is rebased on top of v14 streaming read API changes.
>
> Hi Nazir, so with streaming API
On Wed, Apr 3, 2024 at 1:04 PM Melanie Plageman
wrote:
> Thanks! And thanks for updating the commitfest entry!
Nice work!
--
Peter Geoghegan
Hi,
On Wed, Apr 03, 2024 at 08:28:04PM +0530, Bharath Rupireddy wrote:
> On Wed, Apr 3, 2024 at 6:46 PM Bertrand Drouvot
> wrote:
> >
> > Just one comment on v32-0001:
> >
> > +# Synced slot on the standby must get its own inactive_since.
> > +is( $standby1->safe_psql(
> > +
> On 3 Apr 2024, at 18:17, Panda Developpeur
> wrote:
>
> Thank you for considering my contribution.
Looks interesting!
+ usleep(50);
Don't we need to make system 500ms faster instead? Let's change it to
+
On Tue, 2 Apr 2024 at 17:47, Tom Lane wrote:
>
> Matthias van de Meent writes:
> > Attached is v9, which is rebased on master to handle 24eebc65's
> > changed signature of pq_sendcountedtext.
> > It now also includes autocompletion, and a second patch which adds
> > documentation to give users
On Wed, Apr 3, 2024 at 4:49 PM Alvaro Herrera wrote:
>
> Thanks for keeping this moving forward. I gave your proposed patches a
> look. One thing I didn't like much is that we're adding a new member
> (Copy) to XLogwrtAtomic -- but this struct is supposed to be a mirror of
> XLogwrtResult for
On Wed, Apr 3, 2024 at 12:34 PM Heikki Linnakangas wrote:
>
> On 03/04/2024 17:18, Melanie Plageman wrote:
> > I noticed you didn't make the comment updates I suggested in my
> > version 13 here [1]. A few of them are outdated references to
> > heap_page_prune() and one to a now deleted variable
> Fwiw, I wrote this patch to solve the problem of testing extensions at
> build-time where the build process does not have write access to
> PGSHAREDIR. It solves that problem quite well, almost all PG
> extensions have build-time test coverage now (where there was
> basically 0 before).
Also,
I got Greg's blessing on squashing the commits down, and now including
a v4 with additional improvements on the output formatting front.
Main changes:
- all generated comments are the same width
- width has been bumped to 80
- removed _() functions for consumers of the new output functions
This
Building the docs fail for v26. The error is:
ref/psql-ref.sgml:1042: element member: validity error : Element term is not
declared in member list of possible children
^
I am able to build up to v24 before the was replaced with
I tested building with a
Hi, Alexander!
On Wed, 3 Apr 2024 at 22:18, Alexander Korotkov
wrote:
> On Wed, Apr 3, 2024 at 7:55 PM Alvaro Herrera
> wrote:
> >
> > On 2024-Apr-03, Alexander Korotkov wrote:
> >
> > > Regarding the shmem data structure for LSN waiters. I didn't pick
> > > LWLock or ConditionVariable,
Re: David E. Wheeler
> > Yes, I like the suggestion to make it require a restart, which lets the
> > sysadmin control it and not limited to whatever the person who compiled it
> > thought would make sense.
>
> Here’s a revision of the Debian patch that requires a server start.
Thanks for
Thanks for taking your time to answer. Not sure if I understand though.
> On 3 Apr 2024, at 16:27, Tom Lane wrote:
>
> =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= writes:
>> When implementing a GiST consistent function I found the need to cache
>> pre-processed query across invocations.
>> I am not
On Tue, Apr 2, 2024 at 1:10 PM Heikki Linnakangas wrote:
>
> On 01/04/2024 22:58, Melanie Plageman wrote:
> > Attached v7 has version 14 of the streaming read API as well as a few
> > small tweaks to comments and code.
>
> I saw benchmarks in this thread to show that there's no regression when
>
=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= writes:
> On 3 Apr 2024, at 16:27, Tom Lane wrote:
>> AFAIK it works. I don't see any of the in-core ones doing so,
>> but at least range_gist_consistent and multirange_gist_consistent
>> are missing a bet by repeating their cache search every time.
>
On 03/04/2024 13:31, Nazir Bilal Yavuz wrote:
Streaming API has been committed but the committed version has a minor
change, the read_stream_begin_relation function takes Relation instead
of BufferManagerRelation now. So, here is a v5 which addresses this
change.
I'm getting a repeatable
Corey Huinker writes:
> - functions strive to not ERROR unless absolutely necessary. The biggest
> exposure is the call to array_in().
As far as that goes, it shouldn't be that hard to deal with, at least
not for "soft" errors which hopefully cover most input-function
failures these days. You
I committed v23-0001. Here is a rebased version of the remaining patches.
I intend to test the masking idea from Ants next.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 295b03530de5f42fe876b4489191da2f8dc83194 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 27
Yeah sorry for the delay, it took me some time to understood how build,
modify and test the modification
Hi Regina,
On 2024-Mar-27, Regina Obe wrote:
> The error is
>
> rm -f '../../src/include/storage/lwlocknames.h'
> cp -pR ../../backend/storage/lmgr/lwlocknames.h
> '../../src/include/storage/lwlocknames.h'
> cp: cannot stat '../../backend/storage/lmgr/lwlocknames.h': No such file or
>
On Wed, Apr 3, 2024 at 10:38 AM Tom Lane wrote:
> Also, calling Photon 3
> dead because it went EOL three days ago seems over-hasty.
Well, March 1, but either way I thought "dead" for the purposes of
this thread meant "you can't build the very latest version of Postgres
on it", not "we've
Hi,
On 2024-02-14 16:23:38 +0900, Michael Paquier wrote:
> It is possible to retrieve this information some WITH RECURSIVE as well, as
> mentioned upthread. Perhaps we could consider documenting these tricks?
I think it's sufficiently hard that it's not a reasonable way to do this.
Greetings,
On 03/04/2024 17:18, Melanie Plageman wrote:
I noticed you didn't make the comment updates I suggested in my
version 13 here [1]. A few of them are outdated references to
heap_page_prune() and one to a now deleted variable name
(all_visible_except_removable).
I applied them to your v13 and
On Wed, 2024-04-03 at 01:45 -0700, Jeff Davis wrote:
> I suggest that you add a "heap_index" field to ReorderBufferTXN that
> would point to the index into the heap's array (the same as
> bh_nodeidx_entry.index in your patch). Each time an element moves
> within the heap array, just follow the
Jacob Champion writes:
> The RHEL7-alikes are the biggest set, but that's already discussed
> above. Looks like SUSE 12 goes EOL later this year (October 2024), and
> it ships OpenSSL 1.1.1 as an option. Already-dead distros are Ubuntu
> 16.04 (April 2021), Photon 2 (January 2023), and Photon 3
On 30.03.24 00:14, Daniel Gustafsson wrote:
One take-away for me is how important it is to ship recipes for regenerating
any testdata which is included in generated/compiled/binary format. Kind of
how we in our tree ship the config for test TLS certificates and keys which can
be manually
> I don't think we should rely on !OidIsValid(proc->roleId) for signaling
> autovacuum workers. That might not always be true, and I don't see any
> need to rely on that otherwise. IMHO we should just add a few lines before
> the existing code, which doesn't need to be changed at all:
>
>
Update - the condition should be &&
if (pgstat_get_backend_type(proc->backendId) == B_AUTOVAC_WORKER)
{
if (!has_privs_of_role(GetUserId(), ROLE_PG_SIGNAL_AUTOVACUUM)
&& !superuser())
return SIGNAL_BACKEND_NOAUTOVACUUM;
}
Thanks
On Thu, 4 Apr 2024 at 06:03, Melanie Plageman wrote:
> Attached v8 is rebased over current master (which now has the
> streaming read API).
I've looked at the v8-0001 patch.
I wasn't too keen on heapbuildvis() as a function name for an external
function. Since it also does pruning work, it
On Thu, 4 Apr 2024 at 10:15, David Rowley wrote:
> In short, I don't find it strange that disabling one node type results
> in considering another type that we'd otherwise not consider in cases
> where we assume that the disabled node type is always superior and
> should always be used when it is
On Wed, Apr 3, 2024 at 8:28 PM Bharath Rupireddy
wrote:
>
> On Wed, Apr 3, 2024 at 6:46 PM Bertrand Drouvot
> wrote:
> >
> > Just one comment on v32-0001:
> >
> > +# Synced slot on the standby must get its own inactive_since.
> > +is( $standby1->safe_psql(
> > + 'postgres',
> > +
Hi,
On Thu, Apr 4, 2024 at 2:32 AM Jeff Davis wrote:
>
> On Wed, 2024-04-03 at 01:45 -0700, Jeff Davis wrote:
> > I suggest that you add a "heap_index" field to ReorderBufferTXN that
> > would point to the index into the heap's array (the same as
> > bh_nodeidx_entry.index in your patch). Each
On Mon, Apr 01, 2024 at 06:46:01PM -0500, Tristan Partin wrote:
> 1. version-check.diff
>
> Wrap the offending line in a Meson version check.
>
> 2. perl-string.diff
>
> Pass the perl program as a string via its .path() method.
>
> 3. meson-bump.diff
>
> Bump the minimum meson version from
On Tue, Apr 2, 2024 at 1:47 PM Bruce Momjian wrote:
> On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote:
>
> Okay, I changed "superseded" to "old", and changed "latest" to
> "current", patch attached.
>
>
I took a pass at this and found a few items of note. Changes on top of
On Mon, Apr 01, 2024 at 01:21:53PM -0400, Tom Lane wrote:
> I'm not sure. I think if we put our heads down we could finish
> the changes I'm suggesting and resolve the other issues this week.
> However, it is starting to feel like the sort of large, barely-ready
> patch that we often regret
On Thu, Mar 28, 2024 at 8:02 PM Erik Wienhold wrote:
> Thanks, that sounds better. I incorporated that with some minor edits
> in the attached v3.
>
Looks good.
You added my missing ( but dropped the comma after "i.e."
diff --git a/doc/src/sgml/ref/create_table.sgml
On Tue, Mar 26, 2024 at 02:53:35PM +0300, Svetlana Derevyanko wrote:
> What do you think?
>
> +use constant SLRU_PAGES_PER_SEGMENT => 32;
Well, I disagree with what you are doing here, adding a hardcoded
dependency between the test code and the backend code. I would
suggest to use a more dynamic
On Fri, Mar 22, 2024 at 01:58:24PM +, Dagfinn Ilmari Mannsåker wrote:
> Here's an updated patch that adds such a comment. I'll add it to the
> commitfest later today unless someone commits it before then.
I see no problem to do that now rather than later. So, done to make
pg_regress able to
On Thu, 4 Apr 2024 at 11:50, Nathan Bossart wrote:
> If we can verify this approach won't cause segfaults and can stomach the
> regression between 8 and 16 bytes, I'd happily pivot to this approach so
> that we can avoid the function call dance that I have in v25.
>
> Thoughts?
If we're worried
On Wed, Mar 6, 2024 at 1:29 AM Давыдов Виталий
wrote:
> In usual work, the subscription has two_phase = on. I have to change this
> option at catchup stage only, but this parameter can not be altered. There
> was a patch proposal in past to implement altering of two_phase option, but
> it was
On Thu, Apr 4, 2024 at 10:48 AM Amit Kapila wrote:
>
> The v33-0001 looks good to me. I have made minor changes in the
> comments/commit message and removed one part of the test which was a
> bit confusing and didn't seem to add much value. Let me know what you
> think of the attached?
Thanks
On Wed, Apr 3, 2024 at 9:08 PM David Rowley wrote:
>
> On Thu, 4 Apr 2024 at 06:03, Melanie Plageman
> wrote:
> > Attached v8 is rebased over current master (which now has the
> > streaming read API).
>
> I've looked at the v8-0001 patch.
Thanks for taking a look!
> I wasn't too keen on
> On 3 Apr 2024, at 19:02, Tom Lane wrote:
>
> =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= writes:
>
>> pg_trgm consistent caches tigrams but it has some logic to make sure cached
>> values are recalculated:
>
>> cache = (gtrgm_consistent_cache *) fcinfo->flinfo->fn_extra;
>> if (cache
On Tue, Apr 02, 2024 at 04:35:28PM +0500, Andrey M. Borodin wrote:
> We can add tests just like [0] with injection points.
> I mean replace that "sleep 1" with something like
> "$node->wait_for_event('autovacuum worker', 'autocauum-runing');".
> Currently we have no infrastructure to wait for
On Thu, 4 Apr 2024 at 12:34, Michael Paquier wrote:
> I've been re-reading the patch again to remember what this is about,
> and I'm OK with having this "path" column in the catalog. However,
> I'm somewhat confused by the choice of having a temporary number that
> shows up in the catalog
On Thu, 4 Apr 2024 at 14:38, Melanie Plageman wrote:
> Looking at it in the code, I am wondering if we should call
> heap_page_prep() heap_scan_page_prep(). Just wondering if it is clear
> that it is prepping a page to be scanned. You choose whatever you
> think is best.
I ended up calling it
On Wed, Apr 3, 2024 at 11:58 PM Bharath Rupireddy
wrote:
>
>
> Please find the attached v33 patches.
@@ -1368,6 +1416,7 @@ ShutDownSlotSync(void)
if (SlotSyncCtx->pid == InvalidPid)
{
SpinLockRelease(>mutex);
+ update_synced_slots_inactive_since();
return;
}
On 2024-04-04 03:29 +0200, David G. Johnston wrote:
> On Thu, Mar 28, 2024 at 8:02 PM Erik Wienhold wrote:
>
> > Thanks, that sounds better. I incorporated that with some minor edits
> > in the attached v3.
> >
>
> You added my missing ( but dropped the comma after "i.e."
Thanks, fixed in v4.
On Wed, Apr 03, 2024 at 03:13:13PM +0900, Michael Paquier wrote:
> While looking again at that. there were two more comments that missed
> a refresh about JSON in get_formatted_log_time() and
> get_formatted_start_time(). It's been a few weeks since the last
> update, but I'll be able to wrap
On Thu, Apr 4, 2024 at 10:53 AM Ajin Cherian wrote:
>
> On Wed, Mar 6, 2024 at 1:29 AM Давыдов Виталий
> wrote:
>>
>> In usual work, the subscription has two_phase = on. I have to change this
>> option at catchup stage only, but this parameter can not be altered. There
>> was a patch proposal
On Tue, Apr 02, 2024 at 09:53:57AM +0900, Masahiko Sawada wrote:
> Pushed.
Thanks for following up with this thread.
--
Michael
signature.asc
Description: PGP signature
On Mon, 18 Mar 2024 at 15:50, Michael Paquier wrote:
> Additionally, the RMT has set the feature freeze to be **April 8, 2024
> at 0:00 AoE** (see [1]). This is the last time to commit features for
> PostgreSQL 17. In other words, no new PostgreSQL 17 feature can be
> committed after April 8,
On Fri, Mar 8, 2024 at 6:20 AM Maxim Orlov wrote:
> Quite an interesting patch, in my opinion. I've decided to work on it a bit,
> did some refactoring (sorry) and add
> basic tests. Also, I try to take into account as much as possible notes on
> the patch, mentioned by Cédric Villemain.
On Thu, Apr 4, 2024 at 9:42 AM Masahiko Sawada wrote:
>
> @@ -1368,6 +1416,7 @@ ShutDownSlotSync(void)
> if (SlotSyncCtx->pid == InvalidPid)
> {
> SpinLockRelease(>mutex);
> + update_synced_slots_inactive_since();
> return;
> }
> SpinLockRelease(>mutex);
> @@
On Thu, 2024-04-04 at 09:31 +0900, Masahiko Sawada wrote:
> IIUC, with your suggestion, sift_{up|down} needs to update the
> heap_index field as well. Does it mean that the caller needs to pass
> the address of heap_index down to sift_{up|down}?
I'm not sure quite how binaryheap should be
101 - 161 of 161 matches
Mail list logo