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 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
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
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
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
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 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
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 Wed, Dec 4, 2024 at 4:04 PM Thomas Munro wrote:
> Thanks! Pushed. Let's see what the build farm says.
A couple of armv7 animals seemed to die in the Perl tests. Huh. Well
I know that Perl was sensitive to this stuff but it passed on 32 bit
CI (x86). I will try to reproduce that on local A
On Wed, Dec 4, 2024 at 7:39 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Wednesday, December 4, 2024 8:55 AM Michael Paquier
> wrote:
> >
>
> > Amit has concerns with other code paths that could be
> > similarly leaking. I'm not sure if this is worth waiting too long
> > based on how local the fix for
On Tue, Dec 3, 2024 at 10:34 PM Alvaro Herrera wrote:
>
> On 2024-Nov-29, Amit Kapila wrote:
>
> BTW it occurs to me that there might well be some sort of thundering
> herd problem if every process needs to run the check_hook when a SIGHUP
> is broadcast, and they'll all be waiting on that particu
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 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
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 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
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 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
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 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
> >
> 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
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
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
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
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
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 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
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 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
On Mon, Dec 4, 2023 at 2:27 PM Xiang Gao wrote:
>
> [v8 patch]
I have a couple quick thoughts on this:
1. I looked at a couple implementations of this idea, and found that
the constants used in the carryless multiply are tied to the length of
the blocks. With a lookup table we can do the 3-way a
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 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 Tue, Dec 03, 2024 at 02:45:22PM +0100, Alvaro Herrera wrote:
> We can put the new member at the end of the struct, it shouldn't damage
> anything even if they're using this struct -- which I find pretty
> unlikely. The only way that could break anything is if somebody is
> allocating/using arra
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
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 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 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
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 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
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 'BEGIN { warn = 0 } { print }/not available in font/ { warn = 1 }
>
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
Thanks to Álvaro and Tom for reviewing.
On Tue, Dec 03, 2024 at 01:01:29PM -0500, Tom Lane wrote:
> +/* special must-be-first options for dispatching to various subprograms */
> +typedef enum Subprogram
> +{
> + SUBPROGRAM_CHECK,
> + ... etc
>
> "Subprogram" doesn't quite seem like the ri
Peter Eisentraut writes:
> On 30.11.24 20:08, Tom Lane wrote:
>> ... I think we ought to nuke
>> that concept from orbit and just execute the schema elements in the
>> order presented. I looked at several iterations of the SQL standard
>> and cannot find any support for the idea that CREATE SCHEM
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.
--
Heikki Linnakangas
Neon (https://neon.tech)
From a24f69e0bcf38721e5ffe2c7b65f9901fa8b079d Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
On 26.11.24 20:04, Bruce Momjian wrote:
%.pdf: %.fo $(ALL_IMAGES)
- $(FOP) -fo $< -pdf $@
+ LANG=C $(FOP) -fo $< -pdf $@ 2>&1 | \
+ awk 'BEGIN { warn = 0 } { print }/not available in font/ { warn = 1 }
\
+ END { if (warn != 0) print("\nFound characters that cannot be
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 want me to put back the Latin1 characters in the SGML
files or leave them as HTML entities?
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
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
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 belongs
> to
> > the requested pid.
> >
>
> I find that a bit ... suspicio
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
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
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
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.
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
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 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
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
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 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
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
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
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 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:
> 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 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
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
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 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
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 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 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
-- 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-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
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 24 Nov 2024, at 14:48, Daniel Gustafsson wrote:
Any other opinions or should we proceed with the proposed GUC?
--
Daniel Gustafsson
> 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 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 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 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 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 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'
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 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
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 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 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
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
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!
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
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
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 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 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 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 #
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, 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 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
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
1 - 100 of 112 matches
Mail list logo
