Here is v3. I removed CATALOG_VERSION_NO change, so this should be done by
the actual commiter.
--
Best regards,
Maxim Orlov.
v3-0002-Use-64-bit-multixact-offsets.patch
Description: Binary data
v3-0001-Use-64-bit-format-output-for-multixact-offsets.patch
Description: Binary data
v3-0003-Mak
On Sat, Sep 7, 2024 at 6:30 AM Jelte Fennema-Nio wrote:
>
> On Thu, 22 Aug 2024 at 21:34, Marcos Pegoraro wrote:
> > I understand your point, and agree with that for previous releases, but
> > since we have a month only for version 17, will this process work properly
> > until that date ?
> > I
On Fri, Sep 06, 2024 at 07:37:09PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Fri, Sep 06, 2024 at 06:36:53PM -0400, Tom Lane wrote:
> >> I feel like all of these are leaning heavily on users to get it right,
>
> > What do you have in mind? I see things for the pg_upgrade implementation
Noah Misch writes:
> On Fri, Sep 06, 2024 at 06:36:53PM -0400, Tom Lane wrote:
>> I feel like all of these are leaning heavily on users to get it right,
> What do you have in mind? I see things for the pg_upgrade implementation to
> get right, but I don't see things for pg_upgrade users to get r
On Fri, Sep 06, 2024 at 06:36:53PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Yes, that's one way to make it work. If we do it that way, it would be
> > critical to make the ALTER EXTENSION UPDATE run before anything uses the
> > index. Otherwise, we'll run new v18 "signed char" code on a v
Hi Tom
On 06.09.24 18:34, Tom Lane wrote:
> I think it'd be quite foolish to assume that every extant and future
> version of libxml2 will share this glitch. Probably should use
> logic more like pg_strip_crlf(), although we can't use that directly.
Makes sense. I Introduced this logic in the end
On Fri, 6 Sept 2024 at 19:04, Jonathan S. Katz wrote:
> Please see v2 attached. As per original note, please provide feedback
> before Mon, Sep 9 @ 12:00 UTC so we can begin the translation process.
The following sentence was part of the beta1 release announcement, but
is not part of this draft.
Noah Misch writes:
> Yes, that's one way to make it work. If we do it that way, it would be
> critical to make the ALTER EXTENSION UPDATE run before anything uses the
> index. Otherwise, we'll run new v18 "signed char" code on a v17 "unsigned
> char" data file. Running ALTER EXTENSION UPDATE ea
On Thu, 22 Aug 2024 at 21:34, Marcos Pegoraro wrote:
> I understand your point, and agree with that for previous releases, but since
> we have a month only for version 17, will this process work properly until
> that date ?
> I think a release notes is more read as soon as it is available than o
There was a mistake in my query, so the macOS speedup column was wrong
(was accidentally comparing Linux number with macOS master, sorry for
the noise). I also forgot to mention that you don't actually get the
speedup on PostgreSQL 17 on a Mac, because Peter only recently
implemented the needed re
On Fri, Sep 06, 2024 at 02:07:10PM -0700, Masahiko Sawada wrote:
> On Fri, Aug 30, 2024 at 8:10 PM Noah Misch wrote:
> > On Thu, Aug 29, 2024 at 03:48:53PM -0500, Masahiko Sawada wrote:
> > > On Sun, May 19, 2024 at 6:46 AM Noah Misch wrote:
> > > > If I were standardizing pg_trgm on one or the o
On Fri, Aug 30, 2024 at 8:10 PM Noah Misch wrote:
>
> On Thu, Aug 29, 2024 at 03:48:53PM -0500, Masahiko Sawada wrote:
> > On Sun, May 19, 2024 at 6:46 AM Noah Misch wrote:
> > > If I were standardizing pg_trgm on one or the other notion of "char", I
> > > would
> > > choose signed char, since I
Hi,
On 2024-09-05 01:37:34 +0800, 陈宗志 wrote:
> I hope there can be a high-level design document that includes a
> description, high-level architecture, and low-level design.
> This way, others can also participate in reviewing the code.
Yep, that was already on my todo list. The version I just po
Peter Eisentraut writes:
> hashvalidate(), which validates the signatures of support functions for
> the hash AM, contains several hardcoded exceptions.
> ...
> This patch removes those exceptions by providing new support functions
> that have the proper declared signatures. They internally sha
On Fri, Sep 06, 2024 at 03:22:48PM +0530, Nitin Motiani wrote:
> Thanks. I have no other comments.
https://commitfest.postgresql.org/49/5090/ remains in status="Needs review".
When someone moves it to status="Ready for Committer", I will commit
inplace090, inplace110, and inplace120 patches. If o
Alexander Cheshev writes:
> [ v4-0001-Support-wildcards-in-LISTEN-command.patch ]
I had not been paying much if any attention to this thread.
I assumed from the title that it had in mind to allow something like
LISTEN "foo%bar";
where the parameter would be interpreted similarly to a LIKE
On Fri, 6 Sept 2024 at 19:04, Jonathan S. Katz wrote:
>
> On 9/4/24 5:04 PM, Jonathan S. Katz wrote:
> > Hi,
> >
> > Attached is the draft of the PostgreSQL 17 release announcement. This is
> > a draft of the text that will go into the press kit, with the key
> > portions to review starting from t
On 9/4/24 5:04 PM, Jonathan S. Katz wrote:
Hi,
Attached is the draft of the PostgreSQL 17 release announcement. This is
a draft of the text that will go into the press kit, with the key
portions to review starting from the top of the document, up until the
"About PostgreSQL" section.
Please
Jim Jones writes:
> mmh... xmlDocContentDumpOutput seems to add a trailing newline in the
> end of a document by default, making the serialization of the same xml
> string with DOCUMENT and CONTENT different:
Does seem a bit inconsistent.
> Or should we in this case consider something like this
Hi,
On Fri, Sep 06, 2024 at 11:40:56AM -0400, Tom Lane wrote:
> I wrote:
> > Hmm, TimestampTzGetDatum is not a no-op on 32-bit machines. If you're
> > correct about this, why are our 32-bit BF animals not crashing? Are
> > we failing to test this code?
>
> Oh, I had the polarity backwards: this
I wrote:
> Hmm, TimestampTzGetDatum is not a no-op on 32-bit machines. If you're
> correct about this, why are our 32-bit BF animals not crashing? Are
> we failing to test this code?
Oh, I had the polarity backwards: this error doesn't result in trying
to dereference something that's not a point
Hi,
On Thu, Sep 05, 2024 at 02:14:47PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Sep 05, 2024 at 03:03:32PM +0200, Alvaro Herrera wrote:
> > So it seems to
> > me that storing one of these struct for "my backend stats" is wrong: I
> > think you should be using PgStat_BktypeIO instead (or m
Bertrand Drouvot writes:
> While working on the per backend I/O statistics patch ([1]), I noticed that
> there is an unnecessary call to TimestampTzGetDatum() in pg_stat_get_io() (
> as the reset_time is already a Datum).
Hmm, TimestampTzGetDatum is not a no-op on 32-bit machines. If you're
corr
On Fri, 6 Sept 2024 at 19:08, Ashutosh Bapat
wrote:
> The changes look better. A nitpick though. With their definitions
> changed, I think it's better to change the names of the functions
> since their purpose has changed. Right now they report the storage
> type and size used, respectively, at th
On Fri, 6 Sept 2024 at 18:30, Ashutosh Bapat
wrote:
> If the patches are applied in the order 0001, 0003 and 0002, the size
> of the structure remains 632 throughout. Patch 0003 does not affect
> the size of the structure by itself.
Yeah. I kept 0003 separate so it could be easily tested independ
On Fri, Sep 6, 2024 at 9:13 AM Heikki Linnakangas wrote:
> It's currently possible to have up to 2 * max_connections backends in
> the authentication phase. We would have to change that behaviour, or
> make the PGPROC array 2x larger.
I know I already said this elsewhere, but in case it got lost
On 04/09/2024 17:35, Andres Freund wrote:
On 2024-08-12 12:55:00 +0300, Heikki Linnakangas wrote:
From dc53f89edbeec99f8633def8aa5f47cd98e7a150 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Mon, 12 Aug 2024 10:59:04 +0300
Subject: [PATCH v4 4/8] Introduce a separate BackendType for d
On Fri, 6 Sept 2024 at 10:42, Dean Rasheed wrote:
>
> ... assuming that tgamma() and lgamma() behave according to spec ...
Nope, that was too much to hope for. Let's see if this fares any better.
Regards,
Dean
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
inde
On Thu, Sep 5, 2024 at 7:33 PM Tomas Vondra wrote:
>>> My $0.02 cents: the originating case that triggered those patches,
>>> actually started with LWLock/lock_manager waits being the top#1. The
>>> operator can cross check (join) that with a group by pg_locks.fastpath
>>> (='f'), count(*). So, I
On 28.08.24 10:19, Jim Jones wrote:
> Hi,
>
> While testing a feature reported by Pavel in this thread[1] I realized
> that elements containing whitespaces between them won't be indented with
> XMLSERIALIZE( ... INDENT)
>
mmh... xmlDocContentDumpOutput seems to add a trailing newline in the
end
On Thu, Aug 29, 2024 at 4:43 PM Amit Kapila wrote:
>
> On Fri, Aug 23, 2024 at 10:39 AM shveta malik wrote:
> >
> > Please find issues which need some thoughts and approval for
> > time-based resolution and clock-skew.
> >
> > 1)
> > Time based conflict resolution and two phase transactions:
> >
> The issue is simple, but I'll register this in commitfest just in case.
https://commitfest.postgresql.org/50/5243/
>
Hello!
While working on [1], I have found a small issue with correctness
of set_indexsafe_procflags usage in ReindexRelationConcurrently introduced
in [2].
> idx->safe = (indexRel->rd_indexprs == NIL && indexRel->rd_indpred == NIL);
It is always true because there are no RelationGetIndexExpressi
On Mon, 2 Sept 2024 at 18:22, Dilip Kumar wrote:
>
> On Mon, Sep 2, 2024 at 3:32 PM Amit Kapila wrote:
> >
> > On Mon, Sep 2, 2024 at 11:21 AM Dilip Kumar wrote:
> > >
> > > While working on some other code I noticed that in
> > > FindReplTupleInLocalRel() there is an assert [1] that seems to be
On Thu, 29 Aug 2024 at 16:53, Frédéric Yhuel
wrote:
>
>
> On 8/23/24 12:51, Frédéric Yhuel wrote:
> >
> >
> > On 8/23/24 12:02, Rafia Sabih wrote:
> >> On the other hand, this got me thinking about the purpose of this
> >> space information.
> >> If we want to understand that there's still some s
Hi,
Since 1bb2558046c, XLogFileRead() doesn't use the emode argument.
Also, since abf5c5c9a4f, XLogFileReadAnyTLI() is called just once
and emode is always DEBUG2. So, I think we can remove the emode
argument from these functions. I've atached the patch.
Regards,
Yugo Nagata
--
Yugo Nagata
di
CC'd hackers list.
On Wed, Sep 4, 2024 at 7:54 PM Tomas Vondra wrote:
>
> On 9/4/24 11:55, Junwang Zhao wrote:
> > ...
> >
> > ISTM that the JsonUniqueHashEntry.key point to an address later got
> > invalidated by enlargeStringInfo, we can resolve this by explicitly
> > pstrdup the key in the sam
Hi I am trying to install Postgresql 16 on my freebsd 14.1 by compiling it
hosted in an ec2 machine on AWS.
I am using GCC13 to compile the binaries and I keep on running into
*gcc13: fatal error: cannot read spec file './specs': Is a directory *Please
Help
here is the code of my bash script I
Hi hackers,
While working on the per backend I/O statistics patch ([1]), I noticed that
there is an unnecessary call to TimestampTzGetDatum() in pg_stat_get_io() (
as the reset_time is already a Datum).
Please find attached a tiny patch to remove this unnecessary call.
[1]:
https://www.postgre
Hello Richard,
06.09.2024 12:51, Richard Guo wrote:
Ah I see. label_sort_with_costsize is only used to label the Sort
node nicely for EXPLAIN, and usually we do not display the cost
numbers in regression tests.
In fact, I see the error with the following (EXPLAIN-less) query:
create table t (
On Fri, Sep 6, 2024 at 3:34 AM Noah Misch wrote:
>
> On Thu, Sep 05, 2024 at 07:10:04PM +0530, Nitin Motiani wrote:
> > On Thu, Sep 5, 2024 at 1:27 AM Noah Misch wrote:
> > > On Wed, Sep 04, 2024 at 09:00:32PM +0530, Nitin Motiani wrote:
> > > > Assert(rel->ri_needsLockTagTuple ==
> > > > IsIn
On 04/09/2024 17:35, Andres Freund wrote:
On 2024-08-12 12:55:00 +0300, Heikki Linnakangas wrote:
+Running the tests
+=
+
+NOTE: You must have given the --enable-tap-tests argument to configure.
+
+Run
+make check
+or
+make installcheck
+You can use "make installcheck" if
On Fri, Sep 6, 2024 at 5:27 PM Richard Guo wrote:
> On Fri, Sep 6, 2024 at 5:00 PM Alexander Lakhin wrote:
> > static void
> > label_sort_with_costsize(PlannerInfo *root, Sort *plan, double limit_tuples)
> (I'm a little surprised that this does not cause any plan diffs in the
> regression tests.
On Wed, 4 Sept 2024 at 19:21, Tom Lane wrote:
>
> >> I'm not sure why you are doing the testing for special values (NaN etc.)
> >> yourself when the C library function already does it. For example, if I
> >> remove the isnan(arg1) check in your dlgamma(), then it still behaves
> >> the same in al
> On 4 Sep 2024, at 17:34, David Rowley wrote:
>
> On Wed, 4 Sept 2024 at 20:24, Daniel Gustafsson wrote:
>> Not mandatory at all, but since you were prepping a typo backpatch anyways I
>> figured these could join to put a small dent in reducing risks for future
>> backports.
>
> I think this i
On Fri, Sep 6, 2024 at 5:00 PM Alexander Lakhin wrote:
> static void
> label_sort_with_costsize(PlannerInfo *root, Sort *plan, double limit_tuples)
> {
> ...
> cost_sort(&sort_path, root, NIL,
>lefttree->total_cost,
>plan->plan.disabled_nodes,
>
Hello Robert,
21.08.2024 17:29, Robert Haas wrote:
I went ahead and committed these patches. ...
Please take a look at the following code:
static void
label_sort_with_costsize(PlannerInfo *root, Sort *plan, double limit_tuples)
{
...
cost_sort(&sort_path, root, NIL,
lefttree-
On Fri, Sep 6, 2024 at 1:34 PM Amit Langote wrote:
> On Fri, Sep 6, 2024 at 12:07 PM Amit Langote wrote:
> > On Thu, Sep 5, 2024 at 9:58 PM Amit Langote wr
> > Pushed.
>
> Reverted 0002-0004 from both master and REL_17_STABLE due to BF failures.
>
> 0002-0003 are easily fixed by changing the new
> The changes look better. A nitpick though. With their definitions
> changed, I think it's better to change the names of the functions
> since their purpose has changed. Right now they report the storage
> type and size used, respectively, at the time of calling the function.
> With this patch, th
On Fri, Sep 6, 2024 at 9:22 AM David Rowley wrote:
> Maybe instead of inventing a very pessimistic part prune Hash Join, it
> might be better to make the above work without the LATERAL + OFFSET 0
> by creating the parameterized paths Seq Scan paths. That's going to be
> an immense help when the no
On Fri, Sep 6, 2024 at 11:32 AM Tatsuo Ishii wrote:
>
> > Thanks for making the adjustments to this.
> >
> > I don't think there is any need to call tuplestore_updatemax() from
> > within writetup_heap(). That means having to update the maximum space
> > used every time a tuple is written to disk.
51 matches
Mail list logo
