On Tue, Dec 3, 2024 at 12:31 PM Shlok Kyal wrote:
>
> The changes look good to me. I have included it in the updated patch.
>
The patch looks mostly good to me. I have updated the docs, comments,
and some other cosmetic changes. Please see attached and let me know
what you think.
--
With Regard
Hello hackers,
Here's a WIP patch that started on a bugs thread[1].
Problem #1: You can have two databases with different encodings, and
they both pretend that pg_database, pg_authid, pg_db_role_setting etc
are in the local database encoding. That doesn't work too well:
non-ASCII text can be re
On 29.11.24 20:30, Thomas Munro wrote:
On Fri, Nov 29, 2024 at 11:12 PM Thomas Munro wrote:
I was thinking about that ECPG stuff: I bet real applications prefer
to use int64_t etc directly too instead of long, the worst type in C.
I wondered if the embedded SQL standard might know about that the
On 30.11.24 00:42, Thomas Munro wrote:
On Fri, Nov 29, 2024 at 11:12 PM Thomas Munro wrote:
New idea: let's just redefine PRI...{32,64,PTR} on that platform,
instead of modifying snprintf.c.
D'oh, that's not going to fly. gettext() would replace % with
the system's PRId64, so we can't avoid
On Tue, Dec 3, 2024 at 4:03 PM Alvaro Herrera wrote:
>
> If you don't like the idea of a static memcxt in the one block where
> it's needed, I propose to store a new memcxt in PGOutputData, to be used
> exclusively for publications, with a well defined lifetime.
>
+1. This sounds like a way to pr
On Mon, 2 Dec 2024 at 15:25, Konstantin Knizhnik wrote:
>
> Hi hackers,
>
> Attached script reproduces the problem with incorrect results of `select
> count(*)` (it returns larger number of records than really available in the
> table).
> It is not always reproduced, so you may need to repeat it
On Tue, Dec 3, 2024 at 4:08 PM Alvaro Herrera wrote:
>
> Hello,
>
> On 2024-Dec-03, Ashutosh Bapat wrote:
>
> > For one of the earlier versions, I had reported a large memory
> > consumption in all cases and increase in planning time for Assert
> > enabled builds. How does the latest version perfo
On 03.12.24 13:00, Amul Sul wrote:
create table t(a int);
alter table t ADD CONSTRAINT the_constraint CHECK (a > 0) NOT ENFORCED;
insert into t select -1;
select conname, contype,condeferrable,condeferred, convalidated,
conenforced,conkey,connoinherit
frompg_constraint
where conrelid = 't'
On 28.11.24 10:35, Peter Eisentraut wrote:
On 12.11.24 17:08, Peter Eisentraut wrote:
On 11.11.24 12:37, jian he wrote:
On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut
wrote:
New patch version. I've gone through the whole thread again and looked
at all the feedback and various bug reports
On Thu, 28 Nov 2024 at 22:09, Alena Rybakina wrote:
>
> Hi!
>
> On 27.11.2024 16:36, Matthias van de Meent wrote:
>> On Wed, 27 Nov 2024 at 14:22, Alena Rybakina
>> wrote:
>>> Sorry it took me so long to answer, I had some minor health complications
>>>
>>> On 12.11.2024 23:00, Peter Geoghegan w
On 2024-Dec-02, Alvaro Herrera wrote:
> Oh, you're right, this was unintentional and unnoticed. I'll push this
> shortly, to both 17 and master.
Pushed, thanks Christophe and Bertrand.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
It does it in a really, rea
Hi,
On 2024-12-03 13:37:48 +0300, Anton A. Melnikov wrote:
> Found a place in the code of this patch that is unclear to me:
> https://github.com/postgres/postgres/blob/1acf10549e64c6a52ced570d712fcba1a2f5d1ec/src/backend/utils/activity/pgstat.c#L1658
>
> Owing assert() the next if() should never
On Tue, Dec 03, 2024 at 10:16:35AM +0900, Michael Paquier wrote:
> On Mon, Dec 02, 2024 at 04:10:22PM -0500, Robert Haas wrote:
>> Donning my asbestos underwear, I remain yours faithfully,
>
> Thanks for taking the time to compile all that. That's really nice.
+1, I always look forward to the bl
On Tue, Dec 3, 2024 at 10:37 AM Nathan Bossart wrote:
> On Tue, Dec 03, 2024 at 10:16:35AM +0900, Michael Paquier wrote:
> > On Mon, Dec 02, 2024 at 04:10:22PM -0500, Robert Haas wrote:
> >> Donning my asbestos underwear, I remain yours faithfully,
> >
> > Thanks for taking the time to compile all
> Raghuveer, would you mind rebasing this patch set now that the SSE4.2 patch is
> committed?
Rebased to master branch.
Raghuveer
v8-0001-Add-a-Postgres-SQL-function-for-crc32c-benchmarki.patch
Description: v8-0001-Add-a-Postgres-SQL-function-for-crc32c-benchmarki.patch
v8-0002-Refactor-cons
> On Thu, Nov 28, 2024 at 08:36:47PM GMT, Kirill Reshke wrote:
>
> Hi! Can you please send a rebased version of this?
Sure, here it is.
>From 2de1af6489d46449b2884a9194515cd1090d5e8c Mon Sep 17 00:00:00 2001
From: Dmitrii Dolgov <9erthali...@gmail.com>
Date: Tue, 3 Dec 2024 14:55:45 +0100
Subject:
Hi,
On Mon, 2 Dec 2024 at 22:27, Peter Eisentraut wrote:
>
> On 02.12.24 11:50, Nazir Bilal Yavuz wrote:
> > I applied your patches and the cube example worked. But when I edited
> > 'test_json_parser_perf.c' and 'test_json_parser_incremental.c', meson
> > did not rebuild. I used the 'meson test
On Tue, Dec 3, 2024 at 12:17 PM Michael Paquier wrote:
>
> So how about the attached that introduces a FreePublication() matching
> with GetPublication(), used to do the cleanup? Feel free to comment.
>
As you would have noted I am fine with the fix on these lines but I
suggest holding it till w
On Tue, Dec 03, 2024 at 02:01:00PM +0530, Amit Kapila wrote:
> As you would have noted I am fine with the fix on these lines but I
> suggest holding it till we conclude the memory context point raised by
> me today. It is possible that we are still leaking some memory in
> other related scenarios.
Hi!
Found a place in the code of this patch that is unclear to me:
https://github.com/postgres/postgres/blob/1acf10549e64c6a52ced570d712fcba1a2f5d1ec/src/backend/utils/activity/pgstat.c#L1658
Owing assert() the next if() should never be performed, but the comment above
says the opposite.
Is thi
Peter Geoghegan writes:
> On Mon, Dec 2, 2024 at 10:15 AM Matthias van de Meent
> wrote:
>> The running theory is that bitmap executor nodes incorrectly assume
>> that the rows contained in the bitmap all are still present in the
>> index, and thus assume they're allowed to only check the visibil
Hi,
On 2024-12-02 11:07:38 -0500, Peter Geoghegan wrote:
> Clearly it would be wildly impractical to do the "buffer pin interlock
> against TID recycling" thing in the context of bitmap scans.
That's certainly true if we do the VM check at the time of the bitmap heap
scan.
What if we did it when
Hi,
On Fri, Nov 29, 2024 at 08:52:13PM +0500, Kirill Reshke wrote:
> On Fri, 29 Nov 2024 at 20:20, Bertrand Drouvot
> wrote:
> > On Fri, Nov 29, 2024 at 11:23:12AM +0500, Kirill Reshke wrote:
> > > If we don’t have the relation OID when writing buffers out, can we
> > > just store oid to bufferta
On 2024-Dec-03, Michael Paquier wrote:
> So how about the attached that introduces a FreePublication() matching
> with GetPublication(), used to do the cleanup? Feel free to comment.
I think this doubles down on bad design in the logical replication code,
or at least it goes against what we do a
Hello,
On 2024-Dec-03, Ashutosh Bapat wrote:
> For one of the earlier versions, I had reported a large memory
> consumption in all cases and increase in planning time for Assert
> enabled builds. How does the latest version perform in those aspects?
I don't think planning time in assert-enabled
Hi,
The documentation seems to overlook the rewrite condition
when executing ALTER TABLE ADD COLUMN.
The current document states that a volatile DEFAULT will
trigger a rewrite of the table and its indexes. However, the
table and its indexes will also be rewritten when an IDENTITY
column is added
On 27.11.24 16:35, Justin Pryzby wrote:
On Wed, Nov 27, 2024 at 04:33:25PM +0100, Peter Eisentraut wrote:
On 26.11.24 14:56, Justin Pryzby wrote:
Since 811af9786b, the palloc'd idxkey's seem to be leaking/accumulating
throughout the command.
I noticed this on the master branch while running AN
On 12/2/24 10:46, Richard Guo wrote:
On Wed, Nov 27, 2024 at 5:45 PM Richard Guo wrote:
I ended up using 'under the same lowest nulling outer join' to
keep consistent with the wording used elsewhere. Please see the
updated patch attached.
Commit e032e4c7d computes the nullingrel data for eac
Hi,
Here is an updated version of the patch which fixes a few small bugs,
including making sure it checks the update permission plus a bug found
by Joel Jacobsson when it was called by SPI.
Andreas
From 21ccc735d9d261278564a98d8d2d8137485cd758 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Hi,
On Tue, 3 Dec 2024 at 04:05, Michael Paquier wrote:
>
> On Mon, Dec 02, 2024 at 01:50:57PM +0300, Nazir Bilal Yavuz wrote:
> > On Mon, 2 Dec 2024 at 13:11, Peter Eisentraut wrote:
> >> Is there any reason this was not done yet?
> >
> > This looks useful. I am not sure why this was not done b
On Tuesday, December 3, 2024 4:43 AM Alvaro Herrera
wrote:
>
> On 2024-Dec-02, Amit Kapila wrote:
> > > you call anything that loads a Publication depending on how the
> > > caller caches its data. So I would still choose for modifying the
> > > structure on HEAD removing the pstrdup() for the
I ran into $subject and it can be reproduced with the query below.
create temp table tbl_rs(a int, b int);
insert into tbl_rs select i, i from generate_series(1,10)i;
analyze tbl_rs;
set enable_nestloop to off;
set enable_hashagg to off;
select * from tbl_rs t1
where (select a from tbl_rs t2
Hi,
I'd like to clarify the log message level of the VERBOSE option
because I misunderstood that VACUUM VERBOSE messages cannot be
printed in the server log.
Although the hint is mentioned in "Table 19.2. Message Severity Levels",
it is not addressed for other commands.
INFO Provides information
On Wed, 2 Oct 2024 at 10:29, Michael Paquier wrote:
>
> Rebased as v29 due to an OID conflict.
Hi!
Looks like this needs another rebase
--
Best regards,
Kirill Reshke
On Wed, 30 Oct 2024 at 12:01, Yushi Ogiwara
wrote:
>
> I made a new patch (skip_xid_correctly.diff) that incorporates the
> points we discussed:
>
> 1. Fix the issue that consume_xids consumes nxids+1 XIDs.
> 2. Update lastxid when calling GetTopFullTransactionId() to support
> nxids==1 case.
> 3.
On Tue, Dec 3, 2024, at 09:52, Andreas Karlsson wrote:
> Hi,
>
> Here is an updated version of the patch which fixes a few small bugs,
> including making sure it checks the update permission plus a bug found
> by Joel Jacobsson when it was called by SPI.
+1 for this feature.
This seems especial
On Tue, 3 Dec 2024 at 09:29, jian he wrote:
>
> On Tue, Nov 5, 2024 at 6:30 PM Nishant Sharma
> wrote:
> >
> > Thanks for the v2 patch!
> >
> > I see v1 review comments got addressed in v2 along with some
> > further improvements.
> >
> > 1) v2 Patch again needs re-base.
> >
> > 2) I think we nee
On 2024-11-18 Mo 9:25 AM, Yan Chengpeng wrote:
Dear PostgreSQL Hackers,
*Problem Description*
I encountered an issue with the B-Tree ordering of `jsonb` values.
According to the PostgreSQL documentation[1], the ordering should
follow this precedence:
`Object > Array > Boolean > Number > S
-- check constraints
CREATE TABLE gtest20 (a int PRIMARY KEY, b int GENERATED ALWAYS AS (a
* 2) VIRTUAL CHECK (b < 50));
INSERT INTO gtest20 (a) VALUES (10); -- ok
INSERT INTO gtest20 (a) VALUES (30); -- violates constraint
ALTER TABLE gtest20 ALTER COLUMN b SET EXPRESSION AS (a * 100); --
viol
On 2024-Dec-03, Amit Kapila wrote:
> On Tue, Dec 3, 2024 at 4:03 PM Alvaro Herrera wrote:
> >
> > If you don't like the idea of a static memcxt in the one block where
> > it's needed, I propose to store a new memcxt in PGOutputData, to be used
> > exclusively for publications, with a well defined
> On 25 Jul 2024, at 19:51, Jacob Champion
> wrote:
The attached rebased version adds proper list reset, a couple of bugfixes
around cert loading and the ability to set ssl_passhprase_command (and reload)
in the hosts file.
> Matt Caswell appears to be convinced that SSL_set_SSL_CTX() is
> fund
> On 24 Nov 2024, at 14:48, Daniel Gustafsson wrote:
Any other opinions or should we proceed with the proposed GUC?
--
Daniel Gustafsson
On 12/3/24 08:59, Daniel Gustafsson wrote:
On 24 Nov 2024, at 14:48, Daniel Gustafsson wrote:
Any other opinions or should we proceed with the proposed GUC?
I'm good with it. Did you want to commit or would you rather I do it?
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Data
On Mon, Dec 2, 2024 at 2:18 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I've asked about that in linux-mm [1]. To my surprise, the
> recommendations were to stick to creating a large mapping in advance,
> and slice smaller mappings out of that, which could be resized later.
> The OOM score sh
On Mon, Dec 2, 2024 at 6:42 AM Michael Christofides
wrote:
> Are you mostly seeing query plans that have stumped other people already (eg
> second or third line support), so perhaps seeing more complex plans than the
> average user?
Yes. :-)
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Dec 3, 2024 at 11:57 AM Michael Paquier wrote:
>
> On Tue, Dec 03, 2024 at 09:50:42AM +0530, Amit Kapila wrote:
> > But that suits the current design more. We allocate PGOutputData and
> > other contexts in that structure in a "Logical decoding context". A
> > few of its members (publicati
On Tuesday, December 3, 2024 4:28 PM Amit Kapila
wrote:
>
> On Tue, Dec 3, 2024 at 11:57 AM Michael Paquier
> wrote:
> >
> > On Tue, Dec 03, 2024 at 09:50:42AM +0530, Amit Kapila wrote:
> > > But that suits the current design more. We allocate PGOutputData and
> > > other contexts in that struc
hi.
1. Does postgresql support building an extension in a separate directory
from the source files? For example, is this design officially
supported?
~$ mkdir -p $(BUILDDIR)
~$ make -C $(BUILDDIR) -f $(SRCDIR)/Makefile USE_PGXS=1 all
2. If so, what is the correct way to bui
On Wed, 6 Mar 2024 at 02:22, Thomas Munro wrote:
>
> On Sat, Dec 2, 2023 at 3:30 PM Thomas Munro wrote:
> > On Sat, Dec 2, 2023 at 2:18 PM Thomas Munro wrote:
> > > On Fri, Dec 1, 2023 at 6:13 PM Justin Pryzby wrote:
> > > > $ kill -9 2524495; sleep 0.05; pg_ctl -D ./pgdev.dat1 stop -m fast #
On Mon, Dec 2, 2024 at 8:18 PM Peter Geoghegan wrote:
> Attached is a refined version of a test case I posted earlier on [2],
> decisively proving that GiST index-only scans are in fact subtly
> broken. Right now it fails, showing a wrong answer to a query. The
> patch adds an isolationtest test c
In 025584a168a4b3002e19350bb8db0ebf1fd10235, which shipped with v17, I
changed the way that a base backup decides whether files have
checksums. At the time, I thought this was harmless refactoring, but
it turns out that it was better than harmless. The old way can cause
pg_basebackup failures. To r
On Tue, Dec 3, 2024 at 11:19 AM Joe Conway wrote:
> While I know you said "you will do you" when it comes to your annual
> blog, there are a number of similar efforts -- top of mind is the
> analysis done (as I understand it) by Daniel Gustafsson and Claire
> Giordano [1], as well as ongoing/recur
Hi,
On 2024-12-02 11:10:56 +0100, Peter Eisentraut wrote:
> I have noticed that under meson many tests don't have dependencies on the
> build artifacts that they are testing. As an example among many, if you
> make a source code change in contrib/cube/cube.c (see patch 0001 for a demo)
> and then
On 25.10.24 10:16, Andreas Karlsson wrote:
On 10/15/24 8:12 AM, Peter Eisentraut wrote:
We currently have
static PG_Locale_Strategy pg_regex_strategy;
static pg_locale_t pg_regex_locale;
static Oid pg_regex_collation;
but after the recent improvements to pg_locale_t handling, w
Is this supported on any of the public cloud managed postgres services?
On Tue, Dec 3, 2024 at 10:23 AM Robert Haas wrote:
> On Thu, Sep 10, 2015 at 3:43 AM, Kyotaro HORIGUCHI
> wrote:
> > Generated lwlocknames.[ch] don't have header comment because
> > generate-lwlocknames.pl writes them into
On 12/3/24 10:44, Robert Haas wrote:
On Tue, Dec 3, 2024 at 10:37 AM Nathan Bossart wrote:
On Tue, Dec 03, 2024 at 10:16:35AM +0900, Michael Paquier wrote:
> On Mon, Dec 02, 2024 at 04:10:22PM -0500, Robert Haas wrote:
>> Donning my asbestos underwear, I remain yours faithfully,
>
> Thanks for
Here's what I have staged for commit. I didn't like how v4 added the ERROR
to ParseLongOption(), so in v5 I've moved it to the callers of
ParseLongOption(), which is where the existing option validation lives.
This results in a bit of code duplication, but IMHO that's better than
adding nonobvious
On 2024-Nov-29, Amit Kapila wrote:
> I tried it on my Windows machine and noticed that ReplicationSlotCtl
> is NULL for syslogger, so the problem doesn't occur. The reason is
> that we don't attach to shared memory in syslogger, so ideally
> ReplicationSlotCtl should be NULL. Because we inherit ev
On 2024-Dec-03, Nathan Bossart wrote:
> +Subprogram
> +parse_subprogram(const char *name)
> +{
Please add a comment atop this function. Also, I don't think it should
go at the end of the file; maybe right after main() is a more
appropriate location?
> +/* special must-be-first options for dispa
On Tue, Dec 03, 2024 at 03:46:16PM +, Devulapalli, Raghuveer wrote:
>> Raghuveer, would you mind rebasing this patch set now that the SSE4.2 patch
>> is
>> committed?
>
> Rebased to master branch.
Thanks! cfbot is showing a couple of errors [0] [1] [2]. 32-bit Linux is
failing to compile
On 12/3/24 20:09, Rahila Syed wrote:
>
> Hi,
>
>
>
>
> > 4) I wonder if the function needs to return PID. I mean, the
> caller
> > knows which PID it is for, so it seems rather unnecessary.
> >
> > Perhaps it can be used to ascertain that the information indeed
>
On Tue, Dec 3, 2024 at 09:03:37PM +0100, Peter Eisentraut wrote:
> On 03.12.24 04:13, Bruce Momjian wrote:
> > On Mon, Dec 2, 2024 at 09:33:39PM -0500, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Now that we have a warning about non-emittable characters in the PDF
> > > > build, do you w
On Tue, Dec 03, 2024 at 11:39:43AM -0500, Robert Haas wrote:
> If we want a narrower and thus less-risky fix, we could consider just
> adjusting this code here:
>
> segmentno = atoi(segmentpath + 1);
> if (segmentno == 0)
> ereport(ERROR,
>
> On 3 Dec 2024, at 15:04, Joe Conway wrote:
>
> On 12/3/24 08:59, Daniel Gustafsson wrote:
>>> On 24 Nov 2024, at 14:48, Daniel Gustafsson wrote:
>> Any other opinions or should we proceed with the proposed GUC?
>
> I'm good with it. Did you want to commit or would you rather I do it?
No worr
Hi,
On 2024-12-03 22:06:59 +0200, Heikki Linnakangas wrote:
> I spotted some more remnants of the "snapshot too old" feature that was
> removed in v17. Barring objections, I will commit the attached patch to tidy
> up.
Most of this I agree with. But I'm not sure just removing the toast snapshot
s
Andres Freund writes:
> On 2024-12-03 22:06:59 +0200, Heikki Linnakangas wrote:
>> I spotted some more remnants of the "snapshot too old" feature that was
>> removed in v17. Barring objections, I will commit the attached patch to tidy
>> up.
> Most of this I agree with. But I'm not sure just remo
On Wed, Dec 04, 2024 at 11:05:43AM +0530, Amit Kapila wrote:
> On Wed, Dec 4, 2024 at 7:39 AM Zhijie Hou (Fujitsu)
> wrote:
>> It appears there is an additional memory leak caused by allocating
>> publication
>> names within the CacheMemoryContext, as noted in [1]. And it can also be
>> fixed b
On 04/12/2024 03:24, Tom Lane wrote:
Andres Freund writes:
On 2024-12-03 22:06:59 +0200, Heikki Linnakangas wrote:
I spotted some more remnants of the "snapshot too old" feature that was
removed in v17. Barring objections, I will commit the attached patch to tidy
up.
Most of this I agree wi
On Wednesday, December 4, 2024 2:22 PM Michael Paquier
wrote:
>
> On Wed, Dec 04, 2024 at 11:05:43AM +0530, Amit Kapila wrote:
> > On Wed, Dec 4, 2024 at 7:39 AM Zhijie Hou (Fujitsu)
> wrote:
> >> It appears there is an additional memory leak caused by allocating
> >> publication names within t
Dmitry Dolgov писал(а) 2024-12-02 16:39:
On Tue, Oct 08, 2024 at 09:24:15AM GMT, Alexander Pyhalov wrote:
Attaching rebased patches.
Just to let you know, looks like CFBot tests are red again, but this
time there are some unexpected differences in some test query plan.
Hi, updated patches. T
Konstantin Knizhnik writes:
> postgres=# create table t(x integer unique);
> CREATE TABLE
> postgres=# insert into t values (null),(null);
> INSERT 0 2
> postgres=# select count(distinct x) from t;
> count
> ---
> 0
> (1 row)
> postgres=# select array_agg(distinct x) from t;
> array
On 04/12/2024 9:03 am, Tom Lane wrote:
Konstantin Knizhnik writes:
postgres=# create table t(x integer unique);
CREATE TABLE
postgres=# insert into t values (null),(null);
INSERT 0 2
postgres=# select count(distinct x) from t;
count
---
0
(1 row)
postgres=# select array_agg(dist
On Tuesday, December 3, 2024, Konstantin Knizhnik
wrote:
>
> Is it only me who consider that current behavior of array_agg(distinct)
> contradicts to interpretation of nulls in other cases ("null" is something
> like "unknown" which means that we can not say weather two nulls are the
> same or not
hi.
heap_create_with_catalog argument (cooked_constraints):
passed as NIL in function {create_toast_table, make_new_heap}
passed as list_concat(cookedDefaults,old_constraints) in DefineRelation
in DefineRelation we have function call:
MergeAttributes
heap_create_with_catalog
StoreConstraints
Sto
On Wed, Dec 4, 2024 at 2:24 AM Peter Eisentraut wrote:
> This patch looks good to me.
Thanks! Pushed. Let's see what the build farm says.
> In meson.build, this comment seems to be misplaced by accident:
Oops, fixed.
> In c.h, you include instead of . Is there a
> reason for that?
was al
On Tue, Dec 3, 2024 at 03:58:20PM -0500, Bruce Momjian wrote:
> On Tue, Dec 3, 2024 at 09:05:45PM +0100, Peter Eisentraut wrote:
> > On 26.11.24 20:04, Bruce Momjian wrote:
> > > %.pdf: %.fo $(ALL_IMAGES)
> > > - $(FOP) -fo $< -pdf $@
> > > + LANG=C $(FOP) -fo $< -pdf $@ 2>&1 | \
> > > + awk 'B
On Tue, Dec 3, 2024 at 5:58 AM Daniel Gustafsson wrote:
> > Have you seen any weird behavior like this on your end? I'm starting
> > to doubt my test setup...
>
> I've not been able to reproduce any behaviour like what you describe.
Hm, v2 is different enough that I'm going to need to check my no
Hi!
b36fbd9f8d message says that inconsistency may still be possible because
statistics are not completely consistent for a single scan of
pg_stat_replication_slots under concurrent replication slot drop or
creation activity.
Seems there is a reproduction of such a case via isolation test.
Pleas
On Tue, Dec 3, 2024, at 7:41 PM, Michael Paquier wrote:
> On Tue, Dec 03, 2024 at 02:45:22PM +0100, Alvaro Herrera wrote:
> > If we don't want to accept that risk (for which I see no argument, but
> > happy to be proven wrong), I would suggest to use the foreach-pfree
> > pattern Michael first prop
Michel Pelletier writes:
> Here's a WIP patch for a pgexpanded example in src/test/modules.
I didn't look at your patch yet, but in the meantime here's an update
that takes the next step towards what I promised.
0001-0003 are the same as before, with a couple of trivial changes
to rebase them up
On Tue, Dec 03, 2024 at 09:46:06PM -0300, Euler Taveira wrote:
> Although, Debian code search [1] says this data structure is not used outside
> PostgreSQL, I wouldn't risk breaking third-party extensions during a minor
> upgrade (even if it is known that such data structure is from that particular
On 03.12.2024 18:07, Andres Freund wrote:
Hi,
On 2024-12-03 13:37:48 +0300, Anton A. Melnikov wrote:
Found a place in the code of this patch that is unclear to me:
https://github.com/postgres/postgres/blob/1acf10549e64c6a52ced570d712fcba1a2f5d1ec/src/backend/utils/activity/pgstat.c#L1658
Owi
Hi hackers!
Is it only me who consider that current behavior of array_agg(distinct)
contradicts to interpretation of nulls in other cases ("null" is
something like "unknown" which means that we can not say weather two
nulls are the same or not). This is why it is allowed to insert multiple
n
On 30.11.24 20:08, Tom Lane wrote:
2. transformCreateSchemaStmtElements is of the opinion that it's
responsible for ordering the schema elements in a way that will work,
but it just about completely fails at that task. Ordering the objects
by kind is surely not sufficient, and adding CREATE DOMA
> On 3 Dec 2024, at 17:41, Robert Haas wrote:
>
> On Tue, Dec 3, 2024 at 11:19 AM Joe Conway wrote:
>> While I know you said "you will do you" when it comes to your annual
>> blog, there are a number of similar efforts -- top of mind is the
>> analysis done (as I understand it) by Daniel Gustafs
Hi,
Summary of Changes:
According to the postgresql-17 requirements
https://www.postgresql.org/docs/17/install-requirements.html
the minimum required version of openssl is 1.0.2.
In that version, the naming convention on windows is still
ssleay32.[lib|dll] and
libeay32.[lib|dll] instead of libssl
On Tue, 2024-12-03 at 17:06 +0100, Peter Eisentraut wrote:
> But it doesn't remove pg_regex_collation, only pg_regex_strategy. So
> I
> have split my v2 into two patches, the first removes
> pg_regex_collation
> and the second removes pg_regex_strategy. The first patch is useful
> on
> its own
On Tue, Dec 03, 2024 at 10:06:59PM +0200, Heikki Linnakangas wrote:
> -/* --
> - * init_toast_snapshot
> - *
> - * Initialize an appropriate TOAST snapshot. We must use an MVCC snapshot
> - * to initialize the TOAST snapshot; since we don't know which one to use,
> - * just use the o
I wrote:
> Pushed; I'll await hake's next run with interest.
hake didn't like that, but after adding -D__EXTENSIONS__ per
https://illumos.org/man/7/standards
it seems happy again. Its configure results are the same as
beforehand, and the warning about shmdt() is gone.
reg
On Wed, Dec 4, 2024 at 5:33 PM Tom Lane wrote:
> hake didn't like that, but after adding -D__EXTENSIONS__ per
> https://illumos.org/man/7/standards
> it seems happy again. Its configure results are the same as
> beforehand, and the warning about shmdt() is gone.
Cool. I was wondering if it was
Thomas Munro writes:
> Cool. I was wondering if it was going to break on some of our recent
> POSIX 2008 stuff (thread-safe bits and pieces) next, given
> _POSIX_C_SOURCE=200112L. It certainly does know about 2008 too, so it
> looks like the man page might be out of date.
Do you want to try se
On Fri, Nov 29, 2024 at 6:13 PM Peter Eisentraut wrote:
>
> - Added support for virtual columns in trigger column lists. (For that,
> I renamed ExecInitStoredGenerated() to ExecInitGenerated(), which
> handles the computation of ri_extraUpdatedCols.)
>
why not duplicate some code from ExecInitSt
Andres Freund writes:
> On 2024-12-02 17:42:33 -0500, Tom Lane wrote:
>> I'll proceed with improving that (in master only, don't think we need it in
>> back branches, at least not today) unless somebody pushes back soon.
> +1
Pushed; I'll await hake's next run with interest.
Nathan Bossart writes:
> Here's what I have staged for commit.
In addition to Alvaro's comments:
+/* special must-be-first options for dispatching to various subprograms */
+typedef enum Subprogram
+{
+ SUBPROGRAM_CHECK,
+ ... etc
"Subprogram" doesn't quite seem like the right name
On Fri, Nov 22, 2024 at 6:44 PM Thomas Munro wrote:
> I'm not sure if we'd ever know if we broke MinGW + msvcrt.dll in the
> back branches, ie if any computer actually existing on earth would
> ever compile and run the second branch, and if so, be used for serious
> database work and then be able
Hi hackers!
I'd stumbled upon the discussion [1] on TPC-DS query performance,
looked into code that caused this behavior and saw that partial hash,
merge and nested loop paths are discarded regardless of costs
if they have more pathkeys.
I've excluded the pathkey chain length condition from the p
> Thanks! cfbot is showing a couple of errors [0] [1] [2].
Oh yikes, the CI had passed with an earlier version. Wonder if I made a mess of
the rebase. I will take a look and fix them.
Raghuveer
On Wednesday, December 4, 2024 8:55 AM Michael Paquier
wrote:
>
> On Tue, Dec 03, 2024 at 09:46:06PM -0300, Euler Taveira wrote:
> > Although, Debian code search [1] says this data structure is not used
> outside
> > PostgreSQL, I wouldn't risk breaking third-party extensions during a minor
> >
Hello,
It has been over a decade since the discussion of this email. I would like
to know if there has been any proposal regarding the eviction of
relcache/syscache.
We have recently encountered a similar memory problem: relcache/syscache
keeps growing for the reason that connections have been re
On Wed, Dec 4, 2024 at 7:04 AM Robert Haas wrote:
> On Fri, Nov 22, 2024 at 6:44 PM Thomas Munro wrote:
> > I'm not sure if we'd ever know if we broke MinGW + msvcrt.dll in the
> > back branches, ie if any computer actually existing on earth would
> > ever compile and run the second branch, and i
1 - 100 of 112 matches
Mail list logo
