On Wed, Jul 31, 2024 at 07:01:38AM +, Bertrand Drouvot wrote:
> I share the same understanding and I think those can be removed.
>
> The patch LGTM.
That sounds about right. All the volatile references we have here
have been kept under the assumption that a memory barrier is required.
As we
On Tue, 6 Aug 2024 at 10:24, shveta malik wrote:
>
> On Tue, Aug 6, 2024 at 9:54 AM Amit Kapila wrote:
> >
> > On Tue, Aug 6, 2024 at 8:49 AM shveta malik wrote:
> > >
> > > > > > I was reviewing the design of patch003, and I have a query. Do we
> > > > > > need
> > > > > > to even start an app
> On 6 Aug 2024, at 07:43, Michael Paquier wrote:
> I am dubious that it is a good idea to remove
> this code knowing that we have a thread from a few months ago about
> the fact that we have folks complaining about AIX support and that we
> should bring it back:
According to upthread it is supp
On Wed, Jul 31, 2024 at 10:36:11AM +0800, Japin Li wrote:
> I think the forward declaration for heapam_methods variable in
> heapam_handler.c
> is unnecessary, right?
True. This can be removed because all the code paths using
heapam_methods are after its declaration, so duplicating it makes
litt
On Sun, Aug 04, 2024 at 01:02:22AM +0900, Michael Paquier wrote:
> On Fri, Aug 02, 2024 at 07:03:58PM +0300, Andrey M. Borodin wrote:
> > The test works fine with SQL interface “select
> > injection_points_load('get-new-multixact-id');”.
>
> Yes, just use a load() here to make sure that the DSM re
Hi Umar,
In the function of gss_read() if print the value of errno and SOCK_ERRNO
separately, I found the values are different:
*ret = pqsecure_raw_read(conn, recv_buffer, length);
if (*ret < 0)
{
printf("errno: %d\n", errno);
printf("result_errno: %d\n", SOCK_ERRNO);
...
errno: 0
result_errno:
constexpr is a keyword in C23. Rename a conflicting identifier for
future-proofing.
Obviously, C23 is way in the future, but this is a hard error that
prevents any further exploration. (To be clear: This only happens if
you explicitly select C23 mode. I'm not aware of a compiler where this
Hi,
> This looks pretty good to me. The only point that I think deserves more
> discussion is the return type. Does bytea make the most sense here? Or
> should we consider int/bigint?
Personally I would choose BYTEA in order to be consistent with sha*() functions.
It can be casted to TEXT if
On Monday, August 5, 2024 6:52 PM Amit Kapila wrote:
>
> On Sun, Aug 4, 2024 at 1:22 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Friday, August 2, 2024 7:03 PM Amit Kapila
> wrote:
> > >
> >
> > Here is the V11 patch set which addressed above and Kuroda-san[1]
> comments.
> >
>
> A few design-
On Wed, Jun 5, 2024 at 5:42 PM Richard Guo wrote:
> I found a bug in the v6 patch. The following query would trigger the
> Assert in make_restrictinfo that the given subexpression should not be
> an AND clause.
>
> select max(a) from t group by a > b and a = b having a > b and a = b;
>
> This is
On Tue, Aug 6, 2024 at 8:36 AM Michael Paquier wrote:
> On Tue, Aug 06, 2024 at 05:17:10AM +0300, Alexander Korotkov wrote:
> > The 0001 patch is intended to improve this situation. Actually, it's
> > not right to just put RecoveryInProgress() after
> > GetXLogReplayRecPtr(), because more wal cou
I ran a trial version of a memory leak detector called Deleaker on windows
and found some modules that are listed as having leaks. I ran the program
on Linux under valgrind and I do not see any leaks reported there. I have
attached the reported leaks on windows as windows_leaks.txt and valgrind
su
> On 6 Aug 2024, at 12:47, Michael Paquier wrote:
>
> Hmm. How about loading injection_points with shared_preload_libraries
> now that it has a _PG_init() thanks to 75534436a477 to take care of
> the initialization you need here? We could add two hooks to request
> some shmem based on a size
Hi hackers,
While working on [1], I came across what seems to be incorrect comments in
instr_time.h and an unneeded cast to int64.
Indeed, 03023a2664 represented time as an int64 on all platforms but forgot to
update the comment related to INSTR_TIME_GET_MICROSEC() and provided an
incorrect
comm
Hi,
On Mon, Aug 05, 2024 at 03:07:34PM -0500, Sami Imseih wrote:
>
> > yeah, we already have a few macros that access the .ticks, so maybe we
> > could add
> > 2 new ones, say:
> >
> > 1. INSTR_TIME_ADD_MS(t1, msec)
> > 2. INSTR_TIME_IS_GREATER(t1, t2)
> >
> > I think the less operations is d
Here are some review comments for the patch v20240805_2-0003.
==
doc/src/sgml/catalogs.sgml
nitpick - removed the word "either"
==
doc/src/sgml/ref/alter_subscription.sgml
I felt the discussions about "how to handle warnings" are a bit scattered:
e.g.1 - ALTER SUBSCRIPTION REFRESH PUBLI
On Mon, Aug 5, 2024 at 9:05 PM Junwang Zhao wrote:
>
> Hi Amul,
>
> Thanks for your review.
>
> On Mon, Aug 5, 2024 at 8:38 PM Amul Sul wrote:
> >
> > On Mon, Jul 15, 2024 at 11:19 AM Junwang Zhao wrote:
> > >
> >[...]
> > static Relation
> > -createPartitionTable(RangeVar *newPartName, Relatio
Hi hackers,
I was looking into XLogWrite() and saw the below comment. It cannot really
circle back in wal buffers without needing to call pg_write() since next
pages wouldn't be contiguous in memory. So it needs to write whenever it
reaches the end of wal buffers.
/*
> * Dump the set if this wi
hashvalidate(), which validates the signatures of support functions for
the hash AM, contains several hardcoded exceptions. For example,
hash/date_ops support function 1 is hashint4(), which would ordinarily
fail validation because the function argument is int4, not date. But
this works inter
On Tue, Aug 6, 2024 at 11:18 AM Alexander Korotkov
wrote:
> On Tue, Aug 6, 2024 at 8:36 AM Michael Paquier
wrote:
> > On Tue, Aug 06, 2024 at 05:17:10AM +0300, Alexander Korotkov wrote:
> > > The 0001 patch is intended to improve this situation. Actually, it's
> > > not right to just put Recover
On Tue, Aug 6, 2024 at 5:34 PM Amul Sul wrote:
>
> On Mon, Aug 5, 2024 at 9:05 PM Junwang Zhao wrote:
> >
> > Hi Amul,
> >
> > Thanks for your review.
> >
> > On Mon, Aug 5, 2024 at 8:38 PM Amul Sul wrote:
> > >
> > > On Mon, Jul 15, 2024 at 11:19 AM Junwang Zhao wrote:
> > > >
> > >[...]
> > >
Em ter., 6 de ago. de 2024 às 05:33, Rajesh Kokkonda <
rajeshk.kokko...@gmail.com> escreveu:
> I ran a trial version of a memory leak detector called Deleaker on windows
> and found some modules that are listed as having leaks. I ran the program
> on Linux under valgrind and I do not see any leak
On 06/08/2024 11:54, Bertrand Drouvot wrote:
Hi hackers,
While working on [1], I came across what seems to be incorrect comments in
instr_time.h and an unneeded cast to int64.
Indeed, 03023a2664 represented time as an int64 on all platforms but forgot to
update the comment related to INSTR_TIME
On Mon, 5 Aug 2024 at 18:05, shveta malik wrote:
>
> On Mon, Aug 5, 2024 at 11:04 AM vignesh C wrote:
> >
> > On Wed, 31 Jul 2024 at 14:39, shveta malik wrote:
> > >
> > > On Mon, Jun 10, 2024 at 5:00 PM vignesh C wrote:
> > > >
> > > > On Mon, 10 Jun 2024 at 12:24, Amul Sul wrote:
> > > > >
>
On Mon, 5 Aug 2024 at 13:34, Joel Jacobson wrote:
>
> Noted from 5e1f3b9eb:
> "While it adds some space on 32-bit machines, we aren't optimizing for that
> case anymore."
>
> In this case, the extra 32-bit numeric_mul code seems to be 89 lines of code,
> excluding comments.
> To me, this seems l
While browsing through all our global variables for the multithreading
effort, I noticed that our MD5 implementation in src/common/md5.c uses a
static buffer on big-endian systems, which makes it not thread-safe.
That's a bug because that function is also used in libpq.
This was introduced in
On Fri, Aug 2, 2024 at 7:07 PM Robert Haas wrote:
>
> On Fri, Apr 19, 2024 at 11:47 AM Robert Haas wrote:
> >
> [...]
> Here is a rebased version of the patch. No other changes since v1.
>
Here are two minor comments on this:
$ pg_combinebackup /tmp/backup_full/ /tmp/backup_incr2/
/tmp/backup_
On 8/6/24 07:48, Michael Paquier wrote:
> Hi all,
>
> dikkop has reported a failure with the regression tests of pg_combinebackup:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2024-08-04%2010%3A04%3A51
>
> That's in the test 003_timeline.pl, from dc212340058b:
> # Failed
Em ter., 6 de ago. de 2024 às 04:30, jian he
escreveu:
>
> you can also preview the attached screenshot to see the rendered effect.
>
Loved, except that the commit id does not help too much, so I don't think
we need it.
I think a numbered link would be better.
- Change functions to use a saf
I have noticed that ALTER TABLE supports multiple column actions
(ADD/DROP column etc), but does not support multiple column renaming.
See [1]
Here is small example of what im talking about:
```
db2=# create table tt();
CREATE TABLE
-- multiple column altering ok
db2=# alter table tt add column
On Tue, Aug 6, 2024 at 4:04 AM Peter Eisentraut wrote:
> constexpr is a keyword in C23. Rename a conflicting identifier for
> future-proofing.
>
> Obviously, C23 is way in the future, but this is a hard error that
> prevents any further exploration. (To be clear: This only happens if
> you expli
On Tue, Aug 6, 2024 at 9:57 AM Marcos Pegoraro wrote:
> Loved, except that the commit id does not help too much, so I don't think we
> need it.
> I think a numbered link would be better.
I think the commit ID is quite useful. If you're using git, you can do
"git show $COMMITID". If you're using
On Tue, Aug 6, 2024 at 8:23 AM Heikki Linnakangas wrote:
> While browsing through all our global variables for the multithreading
> effort, I noticed that our MD5 implementation in src/common/md5.c uses a
> static buffer on big-endian systems, which makes it not thread-safe.
> That's a bug because
Heikki Linnakangas writes:
> On 06/08/2024 11:54, Bertrand Drouvot wrote:
>> Please find attached a tiny patch to correct those and, in passing, remove
>> what
>> I think is an unneeded cast to int64.
> Applied, thanks!
I think this comment change is a dis-improvement. It's removed the
documen
On Thu, 11 Jul 2024 at 09:24, Yugo NAGATA wrote:
>
> On Tue, 2 Jul 2024 17:03:11 +0900
> Yugo NAGATA wrote:
>
> > On Sun, 31 Mar 2024 22:59:31 +0900
> > Yugo NAGATA wrote:
> > > >
> > > > Also, I added a comment on RelationIsIVM() macro persuggestion from
> > > > jian he.
> > > > In addition, I
On 2024-Aug-06, Kirill Reshke wrote:
> I have noticed that ALTER TABLE supports multiple column actions
> (ADD/DROP column etc), but does not support multiple column renaming.
> Looking closely on gram.y, the only reason for this is that RenameStmt
> is defined less flexible than alter_table_cmds
On 06/08/2024 17:20, Tom Lane wrote:
Heikki Linnakangas writes:
On 06/08/2024 11:54, Bertrand Drouvot wrote:
Please find attached a tiny patch to correct those and, in passing, remove what
I think is an unneeded cast to int64.
Applied, thanks!
I think this comment change is a dis-improvem
On Tue, Aug 6, 2024 at 10:02 AM jian he wrote:
>
> On Fri, Aug 2, 2024 at 1:09 AM Paul Jungwirth
> wrote:
> >
> > On 7/25/24 08:52, Paul Jungwirth wrote:
> > > Here is a patch moving the not-empty check into
> > > check_exclusion_or_unique_constraint. That is a more
> > > logical place for it th
Hi,
On Tue, Aug 06, 2024 at 05:49:32PM +0300, Heikki Linnakangas wrote:
> On 06/08/2024 17:20, Tom Lane wrote:
> > Heikki Linnakangas writes:
> > > On 06/08/2024 11:54, Bertrand Drouvot wrote:
> > > > Please find attached a tiny patch to correct those and, in passing,
> > > > remove what
> > > >
On Sat, Jul 27, 2024 at 4:04 AM Melanie Plageman
wrote:
>
> On Wed, Jul 24, 2024 at 8:19 AM John Naylor wrote:
> I ran my test with your patch (on my 64-bit system, non-assert build)
> and the result is great:
>
> master with my test (slightly modified to now use DELETE instead of
> UPDATE as me
On Tue, Aug 6, 2024, at 11:02 AM, Robert Haas wrote:
> On Tue, Aug 6, 2024 at 9:57 AM Marcos Pegoraro wrote:
> > Loved, except that the commit id does not help too much, so I don't think
> > we need it.
> > I think a numbered link would be better.
>
> I think the commit ID is quite useful. If yo
> On Aug 6, 2024, at 23:05, Robert Haas wrote:
> On Tue, Aug 6, 2024 at 8:23 AM Heikki Linnakangas wrote:
>>
>> This only affects big-endian systems that are compiled without OpenSSL.
>
> LGTM.
Nice catch, looks fine to me as well.
--
Michael
Hi,
On 2024-08-06 12:02:59 -0300, Euler Taveira wrote:
> Talking about the patch, do we want to rely on an external resource? I suggest
> that we use a postgresql.org subdomain. It can point to
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=$COMMIT
I wonder if we should make
Here's another batch of little changes in the same vein. Mostly
converting static bufs that are never modified to consts.
--
Heikki Linnakangas
Neon (https://neon.tech)
From 6dd5a4a413212a61d9a4f5b9db73e812c8b5dcbd Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Tue, 6 Aug 2024 17:58:29
Heikki Linnakangas writes:
> Hmm, ok I see. Then I propose:
> 1. Revert
> 2. Just fix the comment to say int64 instead of uint64.
Yeah, it's probably reasonable to specify the output as int64
not uint64 (especially since it looks like that's what the
macros actually produce).
Hi,
On 2024-08-06 18:13:56 +0300, Heikki Linnakangas wrote:
> From 6dd5a4a413212a61d9a4f5b9db73e812c8b5dcbd Mon Sep 17 00:00:00 2001
> From: Heikki Linnakangas
> Date: Tue, 6 Aug 2024 17:58:29 +0300
> Subject: [PATCH 1/5] Turn a few 'validnsps' static variables into locals
>
> There was no need
Hi,
On 2024-08-06 10:45:48 -0400, Alvaro Herrera wrote:
> On 2024-Aug-06, Kirill Reshke wrote:
>
> > I have noticed that ALTER TABLE supports multiple column actions
> > (ADD/DROP column etc), but does not support multiple column renaming.
>
> > Looking closely on gram.y, the only reason for thi
On Tue, Aug 06, 2024 at 04:04:01PM +0900, Michael Paquier wrote:
> On Wed, Jul 31, 2024 at 07:01:38AM +, Bertrand Drouvot wrote:
>> I share the same understanding and I think those can be removed.
>>
>> The patch LGTM.
>
> That sounds about right. All the volatile references we have here
> h
On Thu, 1 Aug 2024 23:41:18 +0500
Kirill Reshke wrote:
> On Thu, 1 Aug 2024 at 23:27, Jeff Davis wrote:
> > Relatedly, if we can EXPLAIN a CREATE MATERIALIZED VIEW, perhaps we
> > should be able to EXPLAIN a REFRESH MATERIALIZED VIEW, too?
> Sure
REFRESH MATERIALIZED VIEW consists of not only t
On Tue, 6 Aug 2024 at 21:06, Yugo Nagata wrote:
>
> On Thu, 1 Aug 2024 23:41:18 +0500
> Kirill Reshke wrote:
>
> > On Thu, 1 Aug 2024 at 23:27, Jeff Davis wrote:
> > > Relatedly, if we can EXPLAIN a CREATE MATERIALIZED VIEW, perhaps we
> > > should be able to EXPLAIN a REFRESH MATERIALIZED VIEW,
On Tue, Aug 06, 2024 at 11:04:41AM +0300, Aleksander Alekseev wrote:
> Perhaps we need get_int4() / get_int8() / get_numeric() as there seems
> to be a demand [1][2] and it will allow us to easily cast a `bytea`
> value to `integer` or `bigint`. This is probably another topic though.
Yeah, I was s
On Thu, Aug 1, 2024 at 9:19 AM Amul Sul wrote:
> > I think I would have made this pass context->show_progress to
> > progress_report() instead of the whole verifier_context, but that's an
> > arguable stylistic choice, so I'll defer to you if you prefer it the
> > way you have it. Other than that,
On Thu, 01 Aug 2024 13:34:51 -0700
Jeff Davis wrote:
> On Fri, 2024-08-02 at 00:13 +0500, Kirill Reshke wrote:
> > On Thu, 1 Aug 2024 at 23:27, Jeff Davis wrote:
> > >
> > > EXPLAIN ANALYZE CREATE MATERIALIZED VIEW doesn't go through
> > > ExecCreateTableAs(), but does use CreateIntoRelDestRece
On Tue, 6 Aug 2024 at 22:13, Yugo Nagata wrote:
>
> On Thu, 01 Aug 2024 13:34:51 -0700
> Jeff Davis wrote:
>
> > On Fri, 2024-08-02 at 00:13 +0500, Kirill Reshke wrote:
> > > On Thu, 1 Aug 2024 at 23:27, Jeff Davis wrote:
> > > >
> > > > EXPLAIN ANALYZE CREATE MATERIALIZED VIEW doesn't go throug
v5-0001-vaccum_delay-with-absolute-time-nanosleep.patch
Description: Binary data
v5 takes care of the latest comments by Bertrand.
Regards,
Sami
On Tue, Aug 6, 2024 at 5:36 AM Melih Mutlu wrote:
> I think that we don't have the "contiguous pages" constraint when writing
> anymore as we can do vectored IO. It seems unnecessary to write just because
> XLogWrite() is at the end of wal buffers.
> Attached patch uses pg_pwritev() instead of p
On Wed, 7 Aug 2024 02:13:04 +0900
Yugo Nagata wrote:
> On Thu, 01 Aug 2024 13:34:51 -0700
> Jeff Davis wrote:
>
> > On Fri, 2024-08-02 at 00:13 +0500, Kirill Reshke wrote:
> > > On Thu, 1 Aug 2024 at 23:27, Jeff Davis wrote:
> > > >
> > > > EXPLAIN ANALYZE CREATE MATERIALIZED VIEW doesn't go
On Wed, 2024-08-07 at 03:06 +0900, Yugo Nagata wrote:
> I'm sorry. After sending the mail, I found the patch didn't work.
> If we call RestrictSearchPath() before creating a relation, it tries
> to create the relation in pg_catalog and it causes an error.
Yeah, that's exactly the problem I ran int
Jeff Davis writes:
> As you point out in the other email, it's not easy to make that all
> work with REFRESH ... CONCURRENTLY, but perhaps it could work with
> CREATE MATERIALIZED VIEW and REFRESH (without CONCURRENTLY).
I'm not really sure I see the point of this, if it doesn't "just work"
with
On Tue, 06 Aug 2024 11:24:03 -0700
Jeff Davis wrote:
> On Wed, 2024-08-07 at 03:06 +0900, Yugo Nagata wrote:
> > I'm sorry. After sending the mail, I found the patch didn't work.
> > If we call RestrictSearchPath() before creating a relation, it tries
> > to create the relation in pg_catalog and
On Tue, Jun 18, 2024 at 02:25:46PM -0700, Andres Freund wrote:
> > > If not, we can just install the binaries distributed by the project, it's
> > > just more work to keep up2date that way.
> >
> > I guess you mean a separate line to copy choco's ccache.exe somewhere.
>
> I was thinking of alte
On 06/08/2024 18:16, Tom Lane wrote:
Heikki Linnakangas writes:
Hmm, ok I see. Then I propose:
1. Revert
2. Just fix the comment to say int64 instead of uint64.
Yeah, it's probably reasonable to specify the output as int64
not uint64 (especially since it looks like that's what the
macros a
On Sun, Aug 04, 2024 at 07:19:57PM +0100, Ilya Gladyshev wrote:
> -- End of review --
Thanks for the review. I've attempted to address all your feedback in v8
of the patch set. I think the names could still use some work, but I
wanted to get the main structure in place before trying to fix them.
On Tue, Jun 18, 2024 at 08:23:49AM -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> > On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > > That inplace150 patch turned out to be unnecessary. Contrary to the
> > > "noncritical resource releasing" comment
In a blog post [1], Bruce Momjian notes that expression indexes can
help with planning even if they're not used directly. But the examples
cited in that post are vague (i.e., they improve stats, but it's not
clear how they could change plans), and Bruce's answer to a comment
[2] suggests that this
On 06/08/2024 18:52, Andres Freund wrote:
On 2024-08-06 18:13:56 +0300, Heikki Linnakangas wrote:
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index 702a6c3a0b..2732d6bfc9 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -1155,7 +1155,7 @@ Proce
Maciek Sakrejda writes:
> In a blog post [1], Bruce Momjian notes that expression indexes can
> help with planning even if they're not used directly. But the examples
> cited in that post are vague (i.e., they improve stats, but it's not
> clear how they could change plans), and Bruce's answer to
On 06.08.24 17:13, Heikki Linnakangas wrote:
> --- a/src/backend/access/transam/xlogprefetcher.c
> +++ b/src/backend/access/transam/xlogprefetcher.c
> @@ -362,7 +362,7 @@ XLogPrefetcher *
> XLogPrefetcherAllocate(XLogReaderState *reader)
> {
> XLogPrefetcher *prefetcher;
> - static
On Tue, Aug 6, 2024 at 1:25 PM Tom Lane wrote:
> The planner has no info about the values of sqrt(x1), so you get a
> default estimate (one-third) of the selectivity of the WHERE clause.
> But watch this:
>
> regression=# create index on foo (sqrt(x1));
> CREATE INDEX
> regression=# analyze foo;
>
Maciek Sakrejda writes:
> Thanks, but I was asking specifically about _unused_ indexes
> (according to pg_stat_user_indexes). Bruce's blog post showed how they
> can still influence rowcount estimates, but can they do that (1) even
> if they don't end up being used by the query plan and (2) in a w
On 8/6/24 22:25, Tom Lane wrote:
> Maciek Sakrejda writes:
>> In a blog post [1], Bruce Momjian notes that expression indexes can
>> help with planning even if they're not used directly. But the examples
>> cited in that post are vague (i.e., they improve stats, but it's not
>> clear how they coul
On Tue, 2024-08-06 at 14:36 -0400, Tom Lane wrote:
> I'm not really sure I see the point of this, if it doesn't "just
> work"
> with all variants of C.M.V. It's not like you can't easily EXPLAIN
> the view's SELECT.
>
> If REFRESH M. V. does something different than CREATE, there would
> certainl
On Tue, 2024-07-30 at 12:13 -0700, Jeff Davis wrote:
> I found a couple issues with the later patches:
>
> * There was still some confusion about the default collation vs.
> datcollate/datctype for callers of wchar2char() and char2wchar()
> (those
> functions only work for libc). I introduced a ne
On Fri, 1 Mar 2024 at 14:48, Matthias van de Meent
wrote:
> Attached is version 15 of this patch, with the above issues fixed.
> It's also rebased on top of 655dc310 of this morning, so that should
> keep good for some time again.
Attached is version 16 now. Relevant changes from previous patch v
On Wed, Jul 24, 2024 at 05:49:41PM -0400, Matthew Kim wrote:
> Hi, I´ve attached a patch that fixes the make_date overflow. I´ve upgraded
> the patches accordingly to reflect Joseph´s committed fix.
cfbot is unhappy with this one on Windows [0], and I think I see why.
While the patch uses pg_mul_s
After some previous work here:
https://postgr.es/m/89475ee5487d795124f4e25118ea8f1853edb8cb.ca...@j-davis.com
we are less dependent on setlocale(), but it's still not completely
gone.
setlocale() counts as thread-unsafe, so it would be nice to eliminate
it completely.
The obvious answer is usel
On 06/08/2024 23:41, Peter Eisentraut wrote:
On 06.08.24 17:13, Heikki Linnakangas wrote:
> --- a/src/backend/access/transam/xlogprefetcher.c
> +++ b/src/backend/access/transam/xlogprefetcher.c
> @@ -362,7 +362,7 @@ XLogPrefetcher *
> XLogPrefetcherAllocate(XLogReaderState *reader)
>
Jeff Davis writes:
> But there are a couple problems:
> 1. I don't think it's supported on Windows.
Can't help with that, but surely Windows has some thread-safe way.
> 2. I don't see a good way to canonicalize a locale name, like in
> check_locale(), which uses the result of setlocale().
What
Hi Robert,
Thanks for reviewing.
Robert Haas , 6 Ağu 2024 Sal, 20:43 tarihinde şunu
yazdı:
> On Tue, Aug 6, 2024 at 5:36 AM Melih Mutlu wrote:
> > I think that we don't have the "contiguous pages" constraint when
> writing anymore as we can do vectored IO. It seems unnecessary to write
> just b
On Fri, 5 Jul 2024 at 18:48, Peter Geoghegan wrote:
>
> Attached patch teaches nbtree backwards scans to avoid needlessly
> relocking a previously read page/buffer at the point where we need to
> consider reading the next page (the page to the left).
+1, LGTM.
This changes the backward scan code
Please find attached a patch to enable data checksums by default.
Currently, initdb only enables data checksums if passed the
--data-checksums or -k argument. There was some hesitation years ago when
this feature was first added, leading to the current situation where the
default is off. However,
On 8/6/24 14:53, Tomas Vondra wrote:
> On 8/6/24 07:48, Michael Paquier wrote:
>> Hi all,
>>
>> dikkop has reported a failure with the regression tests of pg_combinebackup:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2024-08-04%2010%3A04%3A51
>>
>> That's in the test 003
Thanks a lot Jacob for helping update the tests and sorry for the late
reply.
Based on previous discussion, I remove the document patch, and start to
focus on the v1 simple OCSP logic by checking the leaf/Postgres server
certificate's status only
(0001-v1-WIP-OCSP-support-certificate-status-c
On Tue, 11 Jun 2024 at 10:58, Michail Nikolaev
wrote:
>
> Hello.
>
> I did the POC (1) of the method described in the previous email, and it looks
> promising.
>
> It doesn't block the VACUUM, indexes are built about 30% faster (22 mins vs
> 15 mins).
That's a nice improvement.
> Additional in
On Mon, Aug 5, 2024 at 11:24 PM Alena Rybakina
wrote:
> Ok, thank you for your work)
>
> I think we can leave only the two added libraries in the first patch,
> others are superfluous.
Thank you.
I also have fixed some grammar issues.
--
Regards,
Alexander Korotkov
Supabase
v32-0001-Transf
On Tue, Aug 6, 2024 at 1:12 PM Amit Kapila wrote:
>
> On Sat, Aug 3, 2024 at 1:21 AM Masahiko Sawada wrote:
> >
> > I found a bug in the memory counter update in reorderbuffer. It was
> > introduced by commit 5bec1d6bc5e, so pg17 and master are affected.
> >
> > In ReorderBufferCleanupTXN() we ze
On Tue, Aug 6, 2024 at 5:13 PM vignesh C wrote:
>
> On Mon, 5 Aug 2024 at 18:05, shveta malik wrote:
> >
> > On Mon, Aug 5, 2024 at 11:04 AM vignesh C wrote:
> > >
> > > On Wed, 31 Jul 2024 at 14:39, shveta malik wrote:
> > > >
> > > > On Mon, Jun 10, 2024 at 5:00 PM vignesh C wrote:
> > > > >
Dear Hou,
>
> Here is the V11 patch set which addressed above and Kuroda-san[1] comments.
>
Thanks for updating the patch. I read 0001 again and I don't have critical
comments for now.
I found some cosmetic issues (e.g., lines should be shorter than 80 columns) and
attached the fix patch. Feel
On Tue, Jul 23, 2024 at 11:19 AM Thomas Munro wrote:
> On Tue, Jul 23, 2024 at 1:44 AM Andrew Dunstan wrote:
> > I have an environment I can use for testing. But what exactly am I
> > testing? :-) Install a few "problem" language/region settings, switch
> > the system and ensure initdb runs ok?
Hi Vignesh,
This is mostly a repeat of my previous mail from a while ago [1] but
includes some corrections, answers, and more examples. I'm going to
try to persuade one last time because the current patch is becoming
stable, so I wanted to revisit this syntax proposal before it gets too
late to ch
On Mon, Aug 5, 2024 at 10:26 AM vignesh C wrote:
>
> On Thu, 1 Aug 2024 at 04:25, Peter Smith wrote:
> >
> > Hi Vignesh,
> >
> > I noticed that when replicating sequences (using the latest patches
> > 0730_2*) the subscriber-side checks the *existence* of the sequence,
> > but apparently it is n
On Tue, Aug 6, 2024 at 1:45 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, August 5, 2024 6:52 PM Amit Kapila wrote:
> >
> > On Sun, Aug 4, 2024 at 1:22 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Friday, August 2, 2024 7:03 PM Amit Kapila
> > wrote:
> > > >
> > >
> > > Here is the V11 pat
On Mon, Aug 5, 2024 at 9:15 AM Peter Smith wrote:
>
> Hi,
>
> Writing many new test case combinations has exposed a possible bug in
> patch 0001.
>
> In my previous post [1] there was questionable behaviour when
> replicating from a normal (not generated) column on the publisher side
> to a genera
Hi,
On Tue, Aug 06, 2024 at 12:36:44PM -0500, Sami Imseih wrote:
>
>
> v5 takes care of the latest comments by Bertrand.
>
Thanks!
Please find attached a rebase version (due to 39a138fbef) and in passing I
changed
one comment:
"add t in microseconds to a instr_time" -> "add t (in microseco
On Wed, Aug 7, 2024 at 7:42 AM Masahiko Sawada wrote:
>
> On Tue, Aug 6, 2024 at 1:12 PM Amit Kapila wrote:
> >
> > On Sat, Aug 3, 2024 at 1:21 AM Masahiko Sawada
> > wrote:
> > >
> > > I found a bug in the memory counter update in reorderbuffer. It was
> > > introduced by commit 5bec1d6bc5e, s
I think we could remove the TRACE_SORT macro.
The TRACE_SORT macro has guarded the availability of the trace_sort GUC
setting. But it has been enabled by default ever since it was
introduced in PostgreSQL 8.1, and there have been no reports that
someone wanted to disable it. So I think we cou
96 matches
Mail list logo
