On 2024-Apr-02, David E. Wheeler wrote:
> That quotation comes from this Debian patch[2] maintained by Christoph
> Berg. I’d like to formally propose integrating this patch into the
> core. And not only because it’s overhead for package maintainers like
> Christoph, but because a number of use cas
On Wed, Apr 3, 2024 at 11:30 AM jian he wrote:
>
> On Tue, Apr 2, 2024 at 9:57 PM Amit Langote wrote:
> >
> > Please let me know if you have further comments on 0001. I'd like to
> > get that in before spending more energy on 0002.
> >
-- a/src/backend/parser/parse_target.c
+++ b/src/backend/pa
Alvaro Herrera:
I support the idea of there being a second location from where to load
shared libraries ... but I don't like the idea of making it
runtime-configurable. If we want to continue to tighten up what
superuser can do, then one of the things that has to go away is the
ability to load s
Buildfarm animal mamba (NetBSD 10.0 on macppc) started failing on this with
what seems like a bogus compiler warning:
waitlsn.c: In function 'WaitForLSN':
waitlsn.c:275:24: error: 'endtime' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
275 |delay_ms = (endtime - G
Hi,
On Wed, Apr 03, 2024 at 11:17:41AM +0530, Bharath Rupireddy wrote:
> On Wed, Apr 3, 2024 at 8:38 AM shveta malik wrote:
> >
> > > > Or a simple solution is that the slotsync worker updates
> > > > inactive_since as it does for non-synced slots, and disables
> > > > timeout-based slot invalida
> On 3 Apr 2024, at 09:13, Alvaro Herrera wrote:
>
> On 2024-Apr-02, David E. Wheeler wrote:
>
>> That quotation comes from this Debian patch[2] maintained by Christoph
>> Berg. I’d like to formally propose integrating this patch into the
>> core. And not only because it’s overhead for package m
> I also can confirm that a lot of users would be very happy to have
> "read your writes consistency" and ready to do something to achieve
> this at an application level. However, they typically don't know what
> exactly they need.
>
> So, blogging about pg_wal_replay_wait() and spreading words
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 committed, I gave a try to this patch.
With autovacuum=off and 30GB table on NVMe (with standard readahead of
256kb and ext4, Debian 12, kernel 6.
Hi, Alvaro!
Thank you for your feedback.
On Wed, Apr 3, 2024 at 9:58 AM Alvaro Herrera wrote:
> Hello, I noticed that commit 06c418e163e9 uses waitLSN->mutex (a
> spinlock) to protect the contents of waitLSN -- and it's used to walk an
> arbitrary long list of processes waiting ... and also, an
On Mon, 2024-04-01 at 12:42 +0900, Masahiko Sawada wrote:
> While reviewing the patches, I realized the comment of
> binearyheap_allocate() should also be updated. So I've attached the
> new patches.
In sift_{up|down}, each loop iteration calls set_node(), and each call
to set_node does a hash loo
Hi Andrey,
On Thu, Mar 28, 2024 at 1:09 PM Andrey M. Borodin wrote:
>
>
>
> > On 8 Aug 2023, at 12:31, John Naylor wrote:
> >
> > > > Also the shared counter is the cause of the slowdown, but not the
> > > > reason for the numeric limit.
> > >
> > > Isn't it both? typedef Oid is unsigned int =
On Wed, Apr 3, 2024 at 1:10 AM Jeff Davis wrote:
>
> On Sun, 2024-03-31 at 21:18 +0530, Bharath Rupireddy wrote:
> > if (table_modify_buffer_insert() is defined)
> >table_modify_buffer_insert(...);
> > else
> > {
> > myState->bistate = GetBulkInsertState();
> > table_tuple_insert(...);
> >
> On 6 Mar 2024, at 09:59, Daniel Gustafsson wrote:
> Nothing sticks out from reading through these patches, they seem quite ready
> to
> me.
Took another look at this today and committed it. Thanks!
--
Daniel Gustafsson
On Wed, Apr 3, 2024 at 11:17 AM Bharath Rupireddy
wrote:
>
> On Wed, Apr 3, 2024 at 8:38 AM shveta malik wrote:
> >
> > > > Or a simple solution is that the slotsync worker updates
> > > > inactive_since as it does for non-synced slots, and disables
> > > > timeout-based slot invalidation for syn
On Wed, Apr 3, 2024 at 3:15 PM jian he wrote:
>
> On Wed, Apr 3, 2024 at 11:30 AM jian he wrote:
> >
> > On Tue, Apr 2, 2024 at 9:57 PM Amit Langote wrote:
> > >
> > > Please let me know if you have further comments on 0001. I'd like to
> > > get that in before spending more energy on 0002.
> >
Hello Sami,
(v26)
> Here is an example [1] where the session information functions are
> referenced.
> The public doc for this example is in [2].
> Something similar can be done here. For example:
> The session user's name; see the session_user()
> function in
> for more details.
I
On Wed, Apr 3, 2024 at 12:20 PM Bertrand Drouvot
wrote:
>
> On Wed, Apr 03, 2024 at 11:17:41AM +0530, Bharath Rupireddy wrote:
> > On Wed, Apr 3, 2024 at 8:38 AM shveta malik wrote:
> > >
> > > > > Or a simple solution is that the slotsync worker updates
> > > > > inactive_since as it does for no
On Wed, Apr 3, 2024 at 11:13 AM Amit Kapila wrote:
>
> On Wed, Apr 3, 2024 at 9:36 AM Bharath Rupireddy
> wrote:
>
> > I quickly looked at v8, and have a nit, rest all looks good.
> >
> > +if (DecodingContextReady(ctx) && found_consistent_snapshot)
> > +*found_consistent_snaps
Hi,
On Tue, 2 Apr 2024 at 10:23, Nazir Bilal Yavuz wrote:
>
> v4 is rebased on top of v14 streaming read API changes.
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, he
On Sun, 7 Jan 2024 at 07:55, vignesh C wrote:
> One of the test has aborted in CFBot at [1] with:
Rebased the patchset and removed patch 0003 since it was causing the
CI issue reported by vignesh and it seems much less useful and more
controversial to me anyway (due to the extra required roundtri
On Wed, Apr 3, 2024 at 2:58 PM shveta malik wrote:
>
> On Wed, Apr 3, 2024 at 11:17 AM Bharath Rupireddy
> wrote:
> >
> > On Wed, Apr 3, 2024 at 8:38 AM shveta malik wrote:
> > >
> > > > > Or a simple solution is that the slotsync worker updates
> > > > > inactive_since as it does for non-synced
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 use with atomic access. Since this new member is not
added to XL
Em ter., 2 de abr. de 2024 às 18:13, Tom Lane escreveu:
> Ranier Vilela writes:
> > While I working in [1], Coverity reported some errors:
> > src/bin/pg_basebackup/pg_createsubscriber.c
> > CID 1542690: (#1 of 2): Out-of-bounds access (OVERRUN)
> > alloc_strlen: Allocating insufficient memory f
On Wed, Apr 3, 2024 at 12:20 PM Bertrand Drouvot
wrote:
>
> > Please find the attached v31 patches implementing the above idea:
>
> Some comments related to v31-0001:
>
> === testing the behavior
>
> T1 ===
>
> > - synced slots get their on inactive_since just like any other slot
>
> It behaves as
Hello Alvaro,
27.02.2024 20:33, Alvaro Herrera wrote:
Here's the complete set, with these two names using the singular.
I've managed to trigger an assert added by 53c2a97a9.
Please try the following script against a server compiled with
-DTEST_SUMMARIZE_SERIAL (initially I observed this failu
On 2024-Apr-03, Alvaro Herrera wrote:
> So what I do in the attached 0001 is stop using the XLogwrtResult struct
> in XLogCtl and replace it with separate Write and Flush values, and add
> the macro XLogUpdateLocalLogwrtResult() that copies the values of Write
> and Flush from the shared XLogCtl t
Hi,
On Wed, 3 Apr 2024 at 12:11, Daniel Gustafsson wrote:
>
> > On 6 Mar 2024, at 09:59, Daniel Gustafsson wrote:
>
> > Nothing sticks out from reading through these patches, they seem quite
> > ready to
> > me.
>
> Took another look at this today and committed it. Thanks!
Thanks for the commi
On Tue, Apr 2, 2024 at 8:32 PM Thomas Munro wrote:
>
> Here are the remaining patches discussed in this thread. They give
> tablespace-specific io_combine_limit, effective_io_readahead_window
> (is this useful?), and up-to-1MB io_combine_limit (is this useful?).
> I think the first two would prob
On Wed, Apr 3, 2024 at 2:32 PM Bharath Rupireddy
wrote:
>
> I too prefer the latter so that the caller doesn't have to have two
> paths. The new API can just transparently fallback to single inserts.
> I've implemented that in the attached v17 patch. I also tested the
> default APIs manually, but
On 02/04/2024 16:11, Heikki Linnakangas wrote:
On 01/04/2024 20:22, Melanie Plageman wrote:
Review for 0003-0006 (I didn't have any new thoughts on 0002). I know
you didn't modify them much/at all, but I noticed some things in my code
that could be better.
Ok, here's what I have now. I made a
On Apr 3, 2024, at 3:57 AM, walt...@technowledgy.de wrote:
> I can also imagine that it would be very helpful in a container setup to be
> able to set an environment variable with this path instead of having to
> recompile all of postgres to change it.
Yes, I like the suggestion to make it requ
On Apr 3, 2024, at 8:54 AM, David E. Wheeler wrote:
> 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.
Or SIGHUP?
D
vignesh C , 27 Oca 2024 Cmt, 06:01 tarihinde şunu
yazdı:
> On Wed, 3 Jan 2024 at 16:56, Melih Mutlu wrote:
> CFBot shows that the patch does not apply anymore as in [1]:
> === Applying patches on top of PostgreSQL commit ID
> 729439607ad210dbb446e31754e8627d7e3f7dda ===
> === applying patch
> ./v
Hi,
On Wed, Apr 03, 2024 at 05:12:12PM +0530, Bharath Rupireddy wrote:
> On Wed, Apr 3, 2024 at 4:19 PM Amit Kapila wrote:
> >
> > + 'postgres',
> > + "SELECT '$inactive_since_on_primary'::timestamptz <
> > '$inactive_since_on_standby'::timestamptz AND
> > + '$inactive_since_on_standby'::timestam
Dear PostgreSQL Hackers,
I am submitting a patch to modify pg_ctl to detect the presence of a geek
user on the system and adapt its behavior accordingly. This patch
introduces the following changes:
1.
*Detection of geek user*: The modified pg_ctl now checks user created on
the computer
Hi,
Michael Paquier , 14 Şub 2024 Çar, 10:23 tarihinde
şunu yazdı:
> On Fri, Jan 19, 2024 at 05:41:45PM +0900, torikoshia wrote:
> > We already have additional description below the table which explains
> each
> > column of the system view. For example pg_locks:
> > https://www.postgresql.org/doc
On Wed, Apr 3, 2024 at 04:17:21PM +0300, Panda Developpeur wrote:
> Dear PostgreSQL Hackers,
>
> I am submitting a patch to modify pg_ctl to detect the presence of a geek user
> on the system and adapt its behavior accordingly. This patch introduces the
> following changes:
>
> 1. Detection of
On Wed, Apr 3, 2024 at 09:25:02AM -0400, Bruce Momjian wrote:
> On Wed, Apr 3, 2024 at 04:17:21PM +0300, Panda Developpeur wrote:
> > Dear PostgreSQL Hackers,
> >
> > I am submitting a patch to modify pg_ctl to detect the presence of a geek
> > user
> > on the system and adapt its behavior acco
On Tue, 2 Apr 2024 at 16:33, Robert Haas wrote:
> Committed it, I did. My thanks for working on this issue, I extend.
Looking at the committed version of this patch, the pg_unreachable
calls seemed weird to me. 1 is actually incorrect, thus possibly
resulting in undefined behaviour. And for the o
On Mon, Apr 1, 2024 at 9:46 PM Tomas Vondra
wrote:
>
> Hi,
>
> I've been running some benchmarks and experimenting with various stuff,
> trying to improve the poor performance on ZFS, and the regression on XFS
> when using copy_file_range. And oh boy, did I find interesting stuff ...
[..]
Congra
On Apr 3, 2024, at 8:54 AM, David E. Wheeler wrote:
> 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 st
On Tue, Apr 2, 2024 at 11:55 AM Daniel Gustafsson wrote:
> The attached removes 1.0.2 support (meson build parts untested yet) with a few
> small touch ups of related documentation. I haven't yet done the research on
> where that leaves LibreSSL since we don't really define anywhere what we
> sup
Hello,
On 2024-Apr-03, Alexander Lakhin wrote:
> I've managed to trigger an assert added by 53c2a97a9.
> Please try the following script against a server compiled with
> -DTEST_SUMMARIZE_SERIAL (initially I observed this failure without the
> define, it just simplifies reproducing...):
Ah yes, a
On Wed, Apr 3, 2024 at 8:39 AM Heikki Linnakangas wrote:
>
> On 02/04/2024 16:11, Heikki Linnakangas wrote:
> > On 01/04/2024 20:22, Melanie Plageman wrote:
> >> Review for 0003-0006 (I didn't have any new thoughts on 0002). I know
> >> you didn't modify them much/at all, but I noticed some things
On Wed, Apr 3, 2024 at 7:40 PM Alvaro Herrera wrote:
>
> Hello,
>
> On 2024-Apr-03, Alexander Lakhin wrote:
>
> > I've managed to trigger an assert added by 53c2a97a9.
> > Please try the following script against a server compiled with
> > -DTEST_SUMMARIZE_SERIAL (initially I observed this failure
On Wed Apr 3, 2024 at 8:32 AM CDT, Jelte Fennema-Nio wrote:
On Tue, 2 Apr 2024 at 16:33, Robert Haas wrote:
> Committed it, I did. My thanks for working on this issue, I extend.
Looking at the committed version of this patch, the pg_unreachable
calls seemed weird to me. 1 is actually incorrect,
=?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 sure if it is safe to do (or I need to perform some steps to make
> sure cached info is not leaked between rescans).
AFAIK i
Jelte Fennema-Nio writes:
> Looking at the committed version of this patch, the pg_unreachable
> calls seemed weird to me. 1 is actually incorrect, thus possibly
> resulting in undefined behaviour. And for the other call an imho
> better fix would be to remove the now 21 year unused enum variant,
hi.
+
+ json_table is an SQL/JSON function which
+ queries JSON data
+ and presents the results as a relational view, which can be accessed as a
+ regular SQL table. You can only use
json_table inside the
+ FROM clause of a SELECT,
+ UPDATE, DELETE, or
MERGE
+ statement.
+
the on
On Wed, 3 Apr 2024 at 16:31, Tom Lane wrote:
> If we do the latter, we will almost certainly get pushback from
> distros who check for library ABI breaks. I fear the comment
> suggesting that we could remove it someday is too optimistic.
Alright, changed patch 0002 to keep the variant. But remov
On Wed Apr 3, 2024 at 9:50 AM CDT, Jelte Fennema-Nio wrote:
On Wed, 3 Apr 2024 at 16:31, Tom Lane wrote:
> If we do the latter, we will almost certainly get pushback from
> distros who check for library ABI breaks. I fear the comment
> suggesting that we could remove it someday is too optimisti
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',
> + "SELECT '$inactive_since_on_primary'::timestamptz <=
> '$inactiv
On Wed, 3 Apr 2024 at 16:55, Tristan Partin wrote:
> Removing from the switch statement causes a warning:
>
> > [1/2] Compiling C object src/bin/psql/psql.p/command.c.o
> > ../src/bin/psql/command.c: In function ‘wait_until_connected’:
> > ../src/bin/psql/command.c:3803:17: warning: enumeration va
On Wed Apr 3, 2024 at 10:05 AM CDT, Jelte Fennema-Nio wrote:
On Wed, 3 Apr 2024 at 16:55, Tristan Partin wrote:
> Removing from the switch statement causes a warning:
>
> > [1/2] Compiling C object src/bin/psql/psql.p/command.c.o
> > ../src/bin/psql/command.c: In function ‘wait_until_connected’:
Jacob Champion writes:
> As far as I can tell, no versions of LibreSSL so far provide
> X509_get_signature_info(), so this patch is probably a bit too
> aggressive.
Another problem with cutting support is how many buildfarm members
will we lose. I scraped recent configure logs and got the attach
Yeah sorry for the delay, it took me some time to understood how build,
modify and test the modification
On 2024-Apr-03, Dilip Kumar wrote:
> Yeah, we missed acquiring the bank lock w.r.t. intervening pages,
> thanks for reporting. Your fix looks correct to me.
Thanks for the quick review! And thanks to Alexander for the report.
Pushed the fix.
--
Álvaro Herrera PostgreSQL Developer —
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(
> > + 'postgr
> 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
+ usl
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 attac
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 bringi
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 s
Hello Alexander,
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 replayed. In my experience
> waking up a process is way
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 in
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 u
=?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.
> pg_trg
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
> t
> 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, it
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 n
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 p
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 segfau
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 sh
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 bit
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 poin
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 mod
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 (M
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 Ma
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
> directory
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 forgott
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 depende
On 2024-Apr-03, Bharath Rupireddy wrote:
> On Wed, Apr 3, 2024 at 4:49 PM Alvaro Herrera wrote:
> > So what I do in the attached 0001 is stop using the XLogwrtResult struct
> > in XLogCtl and replace it with separate Write and Flush values, and add
> > the macro XLogUpdateLocalLogwrtResult() tha
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 inspect
>
>
> 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 pg_input_error
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 se
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 replayed.
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 av
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 Wed, Apr 3, 2024 at 1:04 PM Melanie Plageman
wrote:
> Thanks! And thanks for updating the commitfest entry!
Nice work!
--
Peter Geoghegan
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 committ
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, becaus
> On 3 Apr 2024, at 19:38, Tom Lane wrote:
>
> 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 (
> On 3 Apr 2024, at 17:29, Tom Lane wrote:
>
> Jacob Champion writes:
>> As far as I can tell, no versions of LibreSSL so far provide
>> X509_get_signature_info(), so this patch is probably a bit too
>> aggressive.
>
> Another problem with cutting support is how many buildfarm members
> will we
On Tue, Apr 2, 2024 at 12:58 PM Tom Lane wrote:
> Not really. But if you had, say, a join of a promoted path to a
> disabled path, that would be treated as on-par with a join of two
> regular paths, which seems like it'd lead to odd choices. Maybe
> it'd be fine, but my gut says it'd likely not
Hi,
Thank you for looking into this!
On Wed, 3 Apr 2024 at 20:17, Heikki Linnakangas wrote:
>
> 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
> >
> On 3 Apr 2024, at 20:09, Peter Eisentraut wrote:
>
> 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
On 2024-04-03 We 15:12, Daniel Gustafsson wrote:
The
fact that very few animals run the ssl tests is a pet peeve of mine, it would
be nice if we could get broader coverage there.
Well, the only reason for that is that the SSL tests need to be listed
in PG_TEST_EXTRA, and the only reason for
On Wed, Apr 3, 2024 at 11:17 AM Tristan Partin wrote:
> I think patch 2 makes it worse. The value in -Wswitch is that when new
> enum variants are added, the developer knows the locations to update.
> Adding a default case makes -Wswitch pointless.
>
> Patch 1 is still good. The comment change in
Corey Huinker writes:
>> 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.
>>
On Wed, Apr 3, 2024 at 3:21 PM Robert Haas wrote:
> It's also pretty clear to me that the fact that enable_indexscan
> and enable_indexonlyscan work completely differently from each other
> is surprising at best, wrong at worst, but here again, what this patch
> does about that is not above repro
On Fri, Jan 26, 2024 at 8:33 PM James Coleman wrote:
>
> On Tue, Jan 23, 2024 at 2:46 AM Dilip Kumar wrote:
> >
> > On Tue, Jan 23, 2024 at 7:18 AM James Coleman wrote:
> > >
> > > On Mon, Jan 22, 2024 at 8:21 PM James Coleman wrote:
> > > >
> > > > See rebased patch attached.
> > >
> > > I jus
1 - 100 of 160 matches
Mail list logo
