On 3/15/24 17:57, Teodor Sigaev wrote:
Okay, I've applied this piece for now. Not sure I'll have much room
to look at the rest.
Thank you very much!
I have spent some time reviewing this feature. I think we can discuss
and apply it step-by-step. So, the 0001-* patch is at this moment.
The
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
+++
> 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
> 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: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)
> > +
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
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
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
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
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
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
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:
> >
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
>
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
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,
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
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 <=
>
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
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
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
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
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
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
> > +
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
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
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
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
>
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 ...
[..]
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,
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
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 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
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
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
=?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
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
On Tue, Apr 02, 2024 at 03:18:24PM -0400, Tom Lane wrote:
> I've closed the CF entry for this [1] as committed. Please re-open
> it if there was something left to do here.
>
> [1] https://commitfest.postgresql.org/47/4878/
Thanks, I was not aware of this one.
--
Michael
signature.asc
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
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.
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
> 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 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(...);
>
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
On Mon, Mar 18, 2024 at 02:12:57PM +0900, Michael Paquier wrote:
> I may be able to get this one committed just before the feature freeze
> of v17, as timestamp consistency for hooks that call
> log_status_format() is narrow. For now, I have added an entry in the
> CF app to keep track of it:
>
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 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
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
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
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
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
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 arbitrary
number of processes could be calling this code. I think using a
spinlock for this is
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 -
Hello,
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).
The comment in gistrescan says:
/*
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
On Tue, Apr 02, 2024 at 03:56:13PM +0200, Daniel Gustafsson wrote:
> > On 2 Apr 2024, at 15:50, Tom Lane wrote:
>
> > I'll go ahead with what I have.
>
> +1
+#ifdef USE_RESOWNER_FOR_HMAC
Why not, that's cleaner. Thanks for the commit. The interactions
between this code and b8bff07da are
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
> 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
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 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.
Hi,
On 2024-04-03 17:58:55 -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Apr 3, 2024 at 7:57 PM Andres Freund wrote:
> >> Openssh has now integrated [1] a patch to remove the dependency on
> >> libsystemd
> >> for triggering service manager readyness notifications, by inlining
On Thu, Apr 4, 2024 at 11:51 AM Peter Eisentraut wrote:
> On 30.03.24 22:27, Thomas Munro wrote:
> > Hmm, OK so it doesn't have 3 available in parallel from base repos.
> > But it's also about to reach end of "full support" in 2 months[1], so
> > if we applied the policies we discussed in the
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
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
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 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.
>
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,
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
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
On Wed, Apr 03, 2024 at 12:41:27PM -0500, Nathan Bossart wrote:
> I committed v23-0001. Here is a rebased version of the remaining patches.
> I intend to test the masking idea from Ants next.
0002 was missing a cast that is needed for the 32-bit builds. I've fixed
that in v25.
--
Nathan
On Wed, Apr 3, 2024 at 10:04 PM Pavel Borisov wrote:
> 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
On Wed, Apr 3, 2024 at 4:28 PM Thomas Munro wrote:
>
> On Thu, Apr 4, 2024 at 6:03 AM Melanie Plageman
> wrote:
> > On the topic of BAS_BULKREAD buffer access strategy, I think the least
> > we could do is add an assert like this to read_stream_begin_relation()
> > after calculating
Hi,
On 2024-04-04 09:27:35 +1300, Thomas Munro wrote:
> Anecdotally by all reports I've seen so far, all-in-cache seems to be
> consistently a touch faster than master if anything, for streaming seq
> scan and streaming ANALYZE. That's great!, but it doesn't seem to be
> due to intentional
> On 4 Apr 2024, at 00:06, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> On 3 Apr 2024, at 19:38, 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.
>
>> Is Red Hat building and and shipping v17 packages for RHEL7 ELS
On Tue, Apr 02, 2024 at 11:30:39PM +0300, Ants Aasma wrote:
> On Tue, 2 Apr 2024 at 00:31, Nathan Bossart wrote:
>> On Tue, Apr 02, 2024 at 12:11:59AM +0300, Ants Aasma wrote:
>> > What about using the masking capabilities of AVX-512 to handle the
>> > tail in the same code path? Masked out
Hi,
Here's a much more polished and cleaned up version of the patches,
fixing all the issues I've been aware of, and with various parts merged
into much more cohesive parts (instead of keeping them separate to make
the changes/evolution more obvious).
I decided to reorder the changes like this:
On 03.04.24 23:19, Magnus Hagander wrote:
When the code is this simple, we should definitely consider carrying it
ourselves. At least if we don't expect to need *other* functionality
from the same library in the future, which I doubt we will from libsystemd.
Well, I've long had it on my list
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
> 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, 2024-04-03 at 13:19 +0200, 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
On Thu, Apr 4, 2024 at 6:03 AM Melanie Plageman
wrote:
> 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
On Thu, 4 Apr 2024 at 08:21, Robert Haas wrote:
> I wanted to further explore the idea of just not generating plans of
> types that are currently disabled. I looked into doing this for
> enable_indexscan and enable_indexonlyscan. As a first step, I
> investigated how those settings work now, and
On Tue, 2024-03-26 at 08:14 +0100, Peter Eisentraut wrote:
>
> Full vs. simple case mapping is more of a legacy compatibility
> question,
> in my mind. There is some expectation/precedent that C.UTF-8 uses
> simple case mapping, but beyond that, I don't see a reason why
> someone
> would want
> 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
On Wed, Apr 03, 2024 at 10:25:01PM +0300, Nazir Bilal Yavuz wrote:
>
> I realized the same error while working on Jakub's benchmarking results.
>
> Cause: I was using the nblocks variable to check how many blocks will
> be returned from the streaming API. But I realized that sometimes the
>
On Wed, Apr 3, 2024 at 7:57 PM Andres Freund wrote:
> 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
Magnus Hagander writes:
> On Wed, Apr 3, 2024 at 7:57 PM Andres Freund wrote:
>> Openssh has now integrated [1] a patch to remove the dependency on
>> libsystemd
>> for triggering service manager readyness notifications, by inlining the
>> necessary function. That's not hard, the protocol is
On Wed, Apr 03, 2024 at 04:20:39PM +0300, Melih Mutlu wrote:
> Michael Paquier , 14 Şub 2024 Çar, 10:23 tarihinde
> şunu yazdı:
>> I was reading the patch, and using int[] as a representation of the
>> path of context IDs up to the top-most parent looks a bit strange to
>> me, with the
> 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
Alvaro Herrera writes:
> Great, thanks for looking. Pushed now, I'll be closing the commitfest
> entry shortly.
On my machine, headerscheck does not like this:
$ src/tools/pginclude/headerscheck --cplusplus
In file included from /tmp/headerscheck.4gTaW5/test.cpp:3:
Matthias van de Meent writes:
> On Tue, 2 Apr 2024 at 17:47, Tom Lane wrote:
>> IIUC, it's not possible to use the SERIALIZE option when explaining
>> CREATE TABLE AS, because you can't install the instrumentation tuple
>> receiver when the IntoRel one is needed. I think that's fine because
>>
Daniel Gustafsson writes:
> On 3 Apr 2024, at 19:38, 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.
> Is Red Hat building and and shipping v17 packages for RHEL7 ELS customers? If
> not then it seems mostly academical
> On 3 Apr 2024, at 21:48, Andrew Dunstan wrote:
> 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
On 30.03.24 22:27, Thomas Munro wrote:
On Sun, Mar 31, 2024 at 9:59 AM Tom Lane wrote:
Thomas Munro writes:
I was reminded of this thread by ambient security paranoia. As it
stands, we require 1.0.2 (but we very much hope that package
maintainers and others in control of builds don't decide
On Wed, Apr 03, 2024 at 01:38:50PM -0400, Tom Lane wrote:
> The discussion we had last year concluded that we were OK with
> dropping 1.0.1 support when RHEL6 goes out of extended support
> (June 2024 per this thread, I didn't check it). Seems like we
> should have the same policy for RHEL7.
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 —
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
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()
1 - 100 of 161 matches
Mail list logo
