On 2024-Oct-08, Tom Lane wrote:
> Alvaro Herrera writes:
> > ... This is because ColumnDef->inhcount is a 32-bit int, but
> > Form_pg_attribute->attinhcount is int16, so we didn't break the overflow
> > test for ColumnDef inhcount, but attinhcount has overflowed
Per a review comment on the not-null constraint patch from Jian He, I
played a bit with the various inhcount variables in the tree, with this
simple test which creates a child table and 2^16+1 parents:
for i in `seq 1 $((2 ** 16+1))`; do echo "create table parent_$i (a int);";
done | psql
(echo
On 2024-Oct-03, Robert Haas wrote:
> One general thing to think about is that we really document very
> little about EXPLAIN. That might not be good, but we should consider
> whether it will look strange if we document a bunch of stuff about
> this and still don't talk about anything else.
I comp
On 2024-Oct-06, Tom Lane wrote:
> Soumyadeep Chakraborty writes:
> > Attached is a simple patch to directly use heap scan routines in
> > vac_update_datfrozenxid(), avoiding the multilayer overhead from the
> > sysscan infrastructure.
Though if there's anybody with a Postgres fork using catalog
On 2024-Oct-03, jian he wrote:
> I thought SearchSysCacheCopyAttNum is expensive.
> Relation->rd_att is enough for checking attnotnull.
>
> What do you think of the following refactoring of set_attnotnull?
Eh, sure, why not. I mean, I expect that this is going to be barely
noticeable performanc
On 2024-Oct-02, Alvaro Herrera wrote:
> On 2024-Oct-02, jian he wrote:
>
> > On Tue, Oct 1, 2024 at 11:20 PM Alvaro Herrera
> > wrote:
> > after v7, still not bullet-proof. as before, pg_dump/restore will fail
> > for the following:
> >
> > drop ta
On 2024-Oct-02, jian he wrote:
> On Tue, Oct 1, 2024 at 11:20 PM Alvaro Herrera
> wrote:
> >
> > On 2024-Oct-01, jian he wrote:
> >
> > > create table t2 (a int primary key constraint foo not null no inherit);
> > > primary key cannot coexist with n
On 2024-Oct-01, jian he wrote:
> create table t2 (a int primary key constraint foo not null no inherit);
> primary key cannot coexist with not-null no inherit?
> here t2, pg_dump/restore will fail.
Yeah, this needs to throw an error. If you use a table constraint, it
does fail as expected:
cre
Hello,
On 2024-Sep-27, Amit Langote wrote:
> On Fri, Sep 27, 2024 at 2:52 AM Alvaro Herrera
> wrote:
> > While studying a review note from Jian He on not-null constraints, I
> > came across some behavior introduced by commit 9139aa19423b[1] that I
> > think is mistaken
e out, that might indicate the fun part is too ambitious." (John Naylor)
https://postgr.es/m/CAFBsxsG4OWHBbSDM%3DsSeXrQGOtkPiOEOuME4yD7Ce41NtaAD9g%40mail.gmail.com
>From 885383c384bf6c58bb7a65e9744b3cbe078c76d8 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Thu, 26 Sep 2024 19:37:50 +0200
Sub
On 2024-Sep-26, jian he wrote:
> +-- a PK in parent must have a not-null in child that it can mark inherited
> +create table inh_parent (a int primary key);
> +create table inh_child (a int primary key);
> +alter table inh_child inherit inh_parent; -- nope
> +alter table inh_child alter a set not
On 2024-Sep-25, jian he wrote:
> copy from src/test/regress/sql/index_including.sql
> -- Unique index and unique constraint
> CREATE TABLE tbl_include_unique1 (c1 int, c2 int, c3 int, c4 box);
> INSERT INTO tbl_include_unique1 SELECT x, 2*x, 3*x, box('4,4,4,4')
> FROM generate_series(1,10) AS x;
>
On 2024-Sep-24, Alvaro Herrera wrote:
> On 2024-Sep-24, Alexander Kuznetsov wrote:
>
> > is there anything else we can help with or discuss in order to apply this
> > fix?
>
> I don't think so, it seems a no-brainer to me and there are no
> objections. I'
On 2024-Sep-24, Alexander Kuznetsov wrote:
> Hello,
>
> is there anything else we can help with or discuss in order to apply this fix?
I don't think so, it seems a no-brainer to me and there are no
objections. I'll get it pushed tomorrow.
--
Álvaro Herrera PostgreSQL Developer — htt
On 2024-Sep-24, jian he wrote:
> sql-createtable.html
> SECTION: LIKE source_table [ like_option ... ]
> INCLUDING CONSTRAINTS
> CHECK constraints will be copied. No distinction is made between
> column constraints and table constraints. Not-null constraints are
> always copied to the new table.
>
On 2024-Sep-24, jian he wrote:
> static void
> set_attnotnull(List **wqueue, Relation rel, AttrNumber attnum, bool recurse,
>LOCKMODE lockmode)
> {
> What do you think of the above refactor?
> (I intentionally deleted empty new line)
Looks nicer ... but you know what? After spen
On 2024-Sep-24, jian he wrote:
> static Oid
> StoreRelNotNull(Relation rel, const char *nnname, AttrNumber attnum,
> bool is_validated, bool is_local, int inhcount,
> bool is_no_inherit)
> {
> OidconstrOid;
> Assert(attnum > InvalidAttrNumber);
>
Hi Magnus,
On 2024-Sep-23, Magnus Holmgren wrote:
> We've set allow_system_table_mods = on so that we could rename
> pg_database and in its place put a custom view that only lists the
> databases the current user has CONNECT privileges to. This is because
> 1) we allow customers direct (read onl
On 2024-Sep-20, jian he wrote:
> about set_attnotnull.
>
> we can make set_attnotnull look less recursive.
> instead of calling find_inheritance_children,
> let's just one pass, directly call find_all_inheritors
> overall, I think it would be more intuitive.
>
> please check the attached refac
On 2024-Sep-20, Tender Wang wrote:
> By the way, the v3 failed applying on Head(d35e293878)
> git am v3-0001-Catalog-not-null-constraints.patch
> Applying: Catalog not-null constraints
> error: patch failed: doc/src/sgml/ref/create_table.sgml:77
Yeah, there's a bunch of conflicts in current mast
On 2024-Sep-20, Tender Wang wrote:
> jian he 于2024年9月20日周五 11:34写道：
>
> > another bug.
> > I will dig later, just want to share it first.
> >
> > minimum producer:
> > drop table if exists pp1,cc1, cc2,cc3;
> > create table pp1 (f1 int );
> > create table cc1 () inherits (pp1);
> > create table
On 2024-Sep-19, jian he wrote:
> still based on v3.
> in src/sgml/html/ddl-partitioning.html
> << Both CHECK and NOT NULL constraints of a partitioned table are always
> inherited by all its partitions.
> CHECK constraints that are marked NO INHERIT are not allowed to be
> created on partitioned t
y
ATT_PARTITIONED_TABLE, not ATT_TABLE anymore. The ATT_TABLE cases are
useless anyway, because they're rejected by transformPartitionCmd.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
>From eab048c9c7e01df46b0d98d68507c98d9fa187c1 Mon Sep 17 00:00:00 2001
Fro
On 2024-Sep-18, Jelte Fennema-Nio wrote:
> It seems a shame to remove those links from the HTML view where they
> look acceptable and which most people will use, just because they look
> bad in the pdf. And honestly, they don't even look that terrible in
> the PDF imo.
Eh, someday maybe we should
On 2024-Sep-17, Bruce Momjian wrote:
> I think trying to add text to each item is both redundant and confusing,
> because I am guessing that many people will not even know what a commit
> is, and will be confused by clicking on the link.
Uh, I 100% disagree that Postgres users reading the release
On 2024-Sep-11, Bruce Momjian wrote:
> An interesting idea would be to report all function signature changes
> in each major release in some way.
Hmm, extension authors are going to realize this as soon as they try to
compile, so it doesn't seem necessary. Having useful APIs _added_ is a
differe
On 2024-Sep-16, Bruce Momjian wrote:
> We could try:
>
>Add backend support for injection points (Michael Paquier) §1 §2 §3 §4
>
> and maybe only add numbers if there is more than one commit.
Well, this reads like references to sections 1, 2, 3 and 4, but they
aren't that, and probably such
On 2024-Sep-16, Jim Jones wrote:
> * The value of "Current User" does not match the function current_user()
> --- as one might expcect. It is a little confusing, as there is no
> mention of "Current User" in the docs. In case this is the intended
> behaviour, could you please add it to the docs?
On 2024-Sep-14, Hunaid Sohail wrote:
> I agree that both messages should be printed together. IMO the message
> "You are connected to database..." should be printed at the top, no?
> Because it shows important info that the user may be interested to see
> first. Then we can combine the ssl message
On 2024-Sep-12, Pavel Borisov wrote:
> Hi, Maxim!
>
> Previously we accessed offsets in shared MultiXactState without locks as
> 32-bit read is always atomic. But I'm not sure it's so when offset become
> 64-bit.
> E.g. GetNewMultiXactId():
>
> nextOffset = MultiXactState->nextOffset;
> is outsi
On 2024-Sep-12, jian he wrote:
> ---exampleA
> drop table pp1,cc1, cc2;
> create table pp1 (f1 int);
> create table cc1 (f2 text, f3 int) inherits (pp1);
> create table cc2(f4 float) inherits(pp1,cc1);
> alter table pp1 alter column f1 set not null;
> execute constr_meta('{pp1,cc1, cc2}');
>
> --
On 2024-Sep-11, jian he wrote:
> On Wed, Sep 11, 2024 at 2:18 AM Alvaro Herrera
> wrote:
> >
> > Hello, here's a v2 of this patch. I have fixed --I think-- all the
> > issues you and Tender Wang reported (unless I declined a fix in some
> > previous email).
Hello,
I noticed that these two items in the current notes are separate:
Allow specification of partitioned table
access methods (Justin Pryzby, Soumyadeep Chakraborty,
Michael Paquier)
Add DEFAULT setting for ALTER TABLE
.
On 2024-Sep-10, Jim Jones wrote:
> Is \conninfo+ no longer supposed to return the results in tabular form?
> At least it wasn't the case till v28.
I suspect the reason it's no longer a table is that it was previously a
query (which is easily printed as a table by calling printQuery) and now
it's
On 2024-Sep-02, Tender Wang wrote:
> The attached patch adds List *nnconstraints, which store the not-null
> definition, in struct CreateStmt. This makes me a little confused
> about List *constraints in struct CreateStmt. Actually, the List
> constraints store ckeck constraint, and it will be b
On 2024-Sep-09, jian he wrote:
> bold idea. print out the constraint name: violates not-null constraint \"%s\"
> for the following code:
> ereport(ERROR,
> (errcode(ERRCODE_NOT_NULL_VIOLATION),
> errmsg("null value in column \"%s\" o
On 2024-Sep-10, Jelte Fennema-Nio wrote:
> I think as an extension author there are usually three types of
> changes that are relevant:
>
> 1. New APIs/hooks that are meant for extension authors
> For 1, I think adding them to the release notes makes total sense,
> especially if the new APIs are
On 2024-Sep-05, Bruce Momjian wrote:
> That seems more infrastructure/extension author stuff which isn't
> normally mentioned in the release notes. I think such people really
> need to look at all the commit messages.
Are you saying all extension authors should be reading the complete git
log fo
On 2024-Sep-03, Bertrand Drouvot wrote:
> Cons is probably allocating shared memory space that might not be used (
> sizeof(PgStat_IO) is 16392 so that could be a concern for a high number of
> unused connection). OTOH, if a high number of connections is not used that
> might
> be worth to reduce
On 2024-Aug-30, Greg Sabino Mullane wrote:
> I normally wouldn't mention my blog entries here, but this one was about
> the hackers mailing list, so wanted to let people know about it in case you
> don't follow Planet Postgres. I scanned the last year's worth of posts and
> gathered the most used
On 2024-Aug-28, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Hmm, I don't see the issue. It's an uncommon sentence structure, but it
> > was there before this patch, and it's correct AFAICS. If you grep for
> > "which see ", you'll find some more examples of that.
>
> I didn't check the g
On 2024-Aug-23, Michael Paquier wrote:
> On Tue, Aug 20, 2024 at 12:30:35PM -0400, Alvaro Herrera wrote:
> > Yeah, I like this option. Injection points require to be explicitly
> > enabled in configure, so skipping that test when injection_points can't
> > be found
On 2024-Aug-22, Tender Wang wrote:
> I apply the v14 patch on branch REL_14_STABLE. I run this thread issue and I
> find below error.
> [...]
> ERROR: cache lookup failed for constraint 16400
>
> I haven't look into details to find out where cause above error.
Right, we try to drop the constrai
On 2024-Aug-22, Michael Paquier wrote:
> On Wed, Aug 21, 2024 at 01:55:06PM -0400, Alvaro Herrera wrote:
> > Also, maybe it'd make sense for stats to be globally enabled, and that
> > only the tests that require it would disable them? (It's probably easy
&
On 2024-Aug-19, Alvaro Herrera wrote:
> I haven't pushed it yet, mostly because of being unsure about not doing
> anything for the oldest branches (14 and back).
Last night, after much mulling on this, it occurred to me that one easy
way out of this problem for the old branches, wit
On 2024-Aug-21, Michael Paquier wrote:
> From fd8ab7b6845a2c56aa2c8d9c60f404f6b3407338 Mon Sep 17 00:00:00 2001
> From: Michael Paquier
> Date: Wed, 21 Aug 2024 15:16:06 +0900
> Subject: [PATCH 2/3] injection_point: Add injection_points.stats
> This GUC controls if statistics should be used or n
On 2024-Aug-20, Jehan-Guillaume de Rorthais wrote:
> I'm back on this issue as well. I start poking at this patch to review it,
> test it, challenge it and then report here.
>
> I'll try to check if some other issues might have lost/forgot on they way as
> well.
Thanks, much appreciated, looking
On 2023-Oct-27, Ryo Matsumura (Fujitsu) wrote:
> Hi hackers,
>
> I found that 'make update-po' for PGXS does not work.
> Even if execute 'make update-po', but xx.po.new is not generated.
> I don't test and check for meson build system, but I post it tentatively.
>
> I attached patch and test set
On 2024-Aug-21, Michael Paquier wrote:
> I see that you've gone the way with the SQL function doing a load().
> Would it be worth switching the test to rely on the two macros for
> load and caching instead? I've mentioned that previously but never
> got down to present a patch for the sake of thi
Hi. I noticed chipmunk is failing in configure:
checking whether the C compiler works... no
configure: error: in `/home/pgbfarm/buildroot/HEAD/pgsql.build':
configure: error: C compiler cannot create executables
You may want to give it a look.
Thanks!
--
Álvaro Herrera PostgreSQL Deve
On 2024-Aug-19, Andrey M. Borodin wrote:
> > On 5 Jul 2024, at 23:18, Andrey M. Borodin wrote:
> >
> > Alvaro, please find attached the test.
> > I’ve addressed some Michael’s comments in a nearby thread: removed
> > extra load, made injection point names lowercase, fixed some grammar
> > issues
On 2024-Aug-20, Tom Lane wrote:
> We do, however, need to preserve the property that installcheck
> works after install-world. I'm starting to think that maybe
> the 041 test should be hacked to silently skip if it doesn't
> find injection_points available.
Yeah, I like this option. Injection p
On 2024-Aug-19, Bertrand Drouvot wrote:
> diff --git a/src/include/common/relpath.h b/src/include/common/relpath.h
> index 6f006d5a93..a6cb091635 100644
> --- a/src/include/common/relpath.h
> +++ b/src/include/common/relpath.h
> @@ -33,6 +33,10 @@ typedef Oid RelFileNumber;
> #define TABLESPACE_V
On 2024-Aug-20, Tender Wang wrote:
> > As I understand, this fix needs to be applied all the way back to 12,
> > because the overall functionality is that old. However, in branches 14
> > and back, the patch doesn't apply cleanly, because of the changes we
> > made in commit f4566345cf40 :-( I'm
On 2024-Aug-14, Bertrand Drouvot wrote:
> Out of curiosity, checking the sizes of affected files (O2, no debug):
>
> with patch:
>
>textdata bss dec hex filename
> 30304 0 8 303127668
> src/backend/replication/logical/reorderbuffer.o
> without patch:
>
Hello,
On 2024-Aug-14, Jelte Fennema-Nio wrote:
> The following removed comments seems useful to keep (I realize I
> already removed them in a previous version of the patch, but I don't
> think I did that on purpose)
> [...]
Ah, yeah, I agree. I put them back, and pushed 0005, 6 and 7 as a
sing
I gave another look to the remaining patches; here they are again. I
propose some changes:
- to 0005 I change your pqTraceOutputEncryptionRequestResponse()
function name to pqTraceOutputCharResponse and instead of attaching
the "Response" literal in the outpuer to the name given in the
func
On 2024-Aug-06, Kyotaro Horiguchi wrote:
> After a recent commit f80b09bac8, make update-po fails with "missing
> required files". The commit moved some files to fe_utils but this
> change was not reflected in pg_basebackup's nls.mk. The attached patch
> fixes this issue.
Thanks, pushed!
--
Álv
On 2024-Aug-10, Jelte Fennema-Nio wrote:
> On Sat, 10 Aug 2024 at 01:08, Alvaro Herrera wrote:
> > I propose something like the attached, but it's as yet untested. What
> > do you think?
>
> Looks good, but I haven't tested it yet either.
I tested the SASL ex
On 2024-Aug-06, Michael Paquier wrote:
> On Tue, Aug 06, 2024 at 10:21:23AM +0900, Kyotaro Horiguchi wrote:
> > After a recent commit f80b09bac8, make update-po fails with "missing
> > required files". The commit moved some files to fe_utils but this
> > change was not reflected in pg_basebackup's
l progreso." (Ernesto Hernández-Novich)
>From 4a26851519266d31624ad9e332bd89483d7280a2 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Fri, 9 Aug 2024 19:05:08 -0400
Subject: [PATCH] libpq: Trace frontend authentication challenges
If tracing was enabled during connection startup, these messages would
previously be lis
Pushed 0002 and 0003. On the latter: I decided against using int32 to
print the request identifiers; by splitting into two int16's, we see
that the numbers match the values in the PG_PROTOCOL() declarations:
2024-08-09 17:37:38.364622 F 8 SSLRequest 1234 5679
and
2024-08-09
nough already.
[1] https://postgr.es/m/20240807.icgykv5yrql5@alvherre.pgsql
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
"World domination is proceeding according to plan" (Andrew Morton)
>From 4937a327afd51cddfdad7e01f3ccd9493b893bab Mon Sep 17 00:
On 2024-Aug-07, Robert Haas wrote:
> I really wish there was some way to fix commit messages. I had a typo
> in mine today, too.
We could use git notes. The UI is a bit inconvenient (they have to be
pushed and pulled separately from commits), but they seem useful enough.
https://initialcommit.c
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
Hello,
On 2024-Aug-02, Kyotaro Horiguchi wrote:
> I found that pg_createsubscriber doesn't use NLS files. This is due to
> the wrong reference name "pg_createsubscriber" being passed to
> set_pglocale_pgservice(). It should be "pg_basebackup" instead. See
> the attached patch.
Absolutely right.
On 2024-Jul-26, Junwang Zhao wrote:
> There is a bug report[0] Tender comments might be the same
> issue as this one, but I tried Alvaro's and mine patch, neither
> could solve that problem, I did not tried Tender's earlier patch
> thought. I post the test script below in case you are interested.
On 2024-Jul-25, Alexander Kuznetsov wrote:
Hello Alexander,
> In src/backend/commands/trigger.c:4031, there is an
> afterTriggerAddEvent() function. The variable chunk is assigned the
> value of events->tail at line 4050. Subsequently, chunk is compared to
> NULL at lines 4051 and 4079, indicatin
On 2024-Jul-24, Alvaro Herrera wrote:
> be-secure-openssl.c:(.text+0x1f8c): undefined reference to `ERR_new'
> be-secure-openssl.c:(.text+0x1fa4): undefined reference to `ERR_set_debug'
> be-secure-openssl.c:(.text+0x1fb8): undefined reference to `ERR_set_error'
>
Hello
A couple of days ago, PG buildfarm member cisticola started failing:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=cisticola&br=HEAD
The failures[1] are pretty mysterious:
make[3]:
\347\246\273\345\274\200\347\233\256\345\275\225\342\200\234/home/postgres/buildfarm/HEAD/pgsq
On 2024-Jul-22, Melanie Plageman wrote:
> On Sun, Jul 21, 2024 at 5:04 PM Tom Lane wrote:
> > I note also that the PG_TEST_EXTRA approach has caused xid_wraparound
> > to get next-to-zero buildfarm coverage. If that test is actually
> > capable of revealing problems, we're unlikely to find out
On 2024-Jul-16, Alvaro Herrera wrote:
> On 2024-Jul-16, Alvaro Herrera wrote:
>
> > Maybe we can disable this test specifically on Cygwin. We could do that
> > by creating a postgres_fdw_cancel.sql file, with the current output for
> > all platforms, and a "S
on Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Fri, 19 Jul 2024 15:12:38 +0200
Subject: [PATCH] Fix partition detach on tables with FKs to partitioned tables
---
src/backend/commands/tablecmds.c | 49 +---
1 file changed, 38 insertions(+), 11 deletions(-)
diff -
On 2024-Jul-18, David HJ wrote:
> As a long-time PostgreSQL user, I've increasingly run into issues with the
> 63-byte limit for identifiers, particularly table names. This limit, while
> historically sufficient, is becoming a significant pain point in modern
> database design and usage.
This has
On 2024-Jul-16, Alvaro Herrera wrote:
> Maybe we can disable this test specifically on Cygwin. We could do that
> by creating a postgres_fdw_cancel.sql file, with the current output for
> all platforms, and a "SELECT version() ~ 'cygwin' AS skip_test" query,
>
On 2024-Jul-16, Alexander Lakhin wrote:
> I've managed to reproduce this issue in my Cygwin environment by running
> the postgres_fdw test in a loop (10 iterations are enough to get the
> described effect). And what I'm seeing is that a query-cancelling backend
> is stuck inside pgfdw_xact_callbac
On 2024-Jul-11, Nathan Bossart wrote:
> I'm imagining something like this:
>
> struct timespec delay;
> TimestampTz end_time;
>
> end_time = TimestampTzPlusMilliseconds(GetCurrentTimestamp(), msec);
>
> do
> {
> longsecs;
> int microsecs;
>
>
On 2024-Jul-09, Antonin Houska wrote:
> Alvaro Herrera wrote:
>
> > > Is your plan to work on it soon or should I try to write a draft patch? (I
> > > assume this is for PG >= 18.)
> >
> > I don't have plans for it, so if you have resources, please g
On 2024-Jul-04, Mohab Yaser wrote:
> can you send me a link to download this version on windows as I didn't find
> anything other than the one I already have downloaded
Well,
https://packages.msys2.org/package/flex
has 2.6.4. I don't know what GnuWin32 is, but it looks abandoned.
--
Álvaro He
On 2024-Jul-04, Yugo NAGATA wrote:
> On Thu, 4 Jul 2024 11:06:03 +0200
> Jelte Fennema-Nio wrote:
>
> > On Thu, 4 Jul 2024 at 06:46, Yugo NAGATA wrote:
> > > Attached is a small patch to fix a comment on PQcancelErrorMessage.
> >
> > Oops, copy paste mistake on my part I guess. New comment LGT
Okay, so I've pushed the last version after confirming with Alexander
that it works on the Windows x86 machine. I hope nothing breaks now in
the buildfarm.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
On 2024-Jul-04, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Wed, Jul 3, 2024 at 8:46 PM Steve Lau wrote:
> >> While reading the source code, I noticed comments like "-cim 9/10/89".
>
> > It's the initials of the person who, back in 1989, wrote the preceding
> > comments
>
> Right.
>
On 2024-Jul-02, Andres Freund wrote:
> On 2024-07-01 21:12:25 +0200, Alvaro Herrera wrote:
> > On 2024-Jul-01, Andres Freund wrote:
> > I'm pretty sure the Microsoft docs I linked to are saying it must be
> > aligned.
>
> I don't think so:
> https://lea
On 2024-Jul-01, Alvaro Herrera wrote:
> On 2024-Jul-01, Andres Freund wrote:
>
> > On 2024-07-01 11:10:24 +0200, Alvaro Herrera wrote:
> > > In the meantime I noticed that pg_attribute_aligned() is not supported
> > > in every platform/compiler, so for safety
On 2024-Jul-01, Ranier Vilela wrote:
> > - charname[MAXPGPATH + 1];
> > + charname[MAXPGPATH];/* backup label name */
> >
> > With the introduced use of strlcpy, why do we need to change this field?
> >
> The part about being the only reference in the entire cod
Hello,
Thanks for your attention here.
On 2024-Jul-01, Andres Freund wrote:
> On 2024-07-01 11:10:24 +0200, Alvaro Herrera wrote:
> > In the meantime I noticed that pg_attribute_aligned() is not supported
> > in every platform/compiler, so for safety sake I think it's better
On 2024-Jul-01, Tom Lane wrote:
> Alvaro Herrera writes:
> > Maybe we can do something like this,
>
> > +#if MAXIMUM_ALIGNOF >= 8
> > uint64 currval;
>
> This should probably be testing the alignment of int64 specifically,
> rather than assumin
On 2024-Jul-01, Stepan Neretin wrote:
> I have one notice:
> ERROR: value out of range: overflow. I think we need to add information
> about the available ranges in the error message
I think this is a project of its own. The error comes from calling
float_overflow_error(), which is a generic ro
Maybe we can do something like this,
diff --git a/src/include/port/atomics.h b/src/include/port/atomics.h
index 78987f3154..f6fa90bad8 100644
--- a/src/include/port/atomics.h
+++ b/src/include/port/atomics.h
@@ -580,7 +580,20 @@ pg_atomic_sub_fetch_u64(volatile pg_atomic_uint64 *ptr,
int64 sub_)
On 2024-Jul-01, Tom Lane wrote:
> Alvaro Herrera writes:
> >> because the failed assertion is:
> >> #ifndef PG_HAVE_ATOMIC_U64_SIMULATION
> >> AssertPointerAlignment(&currval, 8);
> >> #endif
>
> Perhaps this assertion is what is wrong?
Breisgau, Deutschland — https://www.EnterpriseDB.com/
"La gente vulgar sólo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"
>From 9d240e90f87bf8b53bd5d92b623e33419db64717 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Mon, 1 Jul 2024 10:41:06 +0200
Subject:
On 2024-Jun-30, Joel Jacobson wrote:
> However, I can imagine other crypto algorithms might require larger factors,
> as well as other scientific research use cases, such as astronomy and physics,
> that could desire storage of numeric values of very high precision.
FWIW I was talking to some peo
> diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
> index 233b7b1cc9..df766cdec1 100644
> --- a/src/backend/parser/parse_expr.c
> +++ b/src/backend/parser/parse_expr.c
> @@ -3583,6 +3583,7 @@ coerceJsonFuncExpr(ParseState *pstate, Node *expr,
> Node *res;
Hi
On 2024-Jun-29, Alexander Lakhin wrote:
> --- stderr ---
> TRAP: failed Assert("TYPEALIGN(8, (uintptr_t)(&currval)) ==
> (uintptr_t)(&currval)"), File: "...\src\include\port/atomics.h", Line: 597,
> PID: 7556
> child process was t
On 2024-Jun-26, Nathan Bossart wrote:
> On Fri, Jun 21, 2024 at 04:01:55PM -0500, Nathan Bossart wrote:
> > On Fri, Jun 21, 2024 at 11:22:05AM +0200, Jelte Fennema-Nio wrote:
> >> 0001 is some cleanup after f4b54e1ed9
> >
> > Oops. I'll plan on committing this after the 17beta2 release freeze is
On 2024-Jun-25, David G. Johnston wrote:
> On Tue, Jun 25, 2024 at 9:50 PM David Rowley wrote:
> > FWIW, I disagree that we need to write anything about that in this
> > part of the documentation. I think any argument for doing this could
> > equally be applied to something like re-iterating wh
On 2024-Jun-25, Tom Lane wrote:
> Daniel Gustafsson writes:
> > However, since Andrew is actively aiming to replace all of this shortly,
> > should
> > we wait a see where that lands to avoid having to backport another library
> > change?
>
> I would like to see what he comes up with ... but i
On 2024-Jun-24, Robert Haas wrote:
> Is "tighten up what the superuser can do" on our list of objectives?
> Personally, I think we should be focusing mostly, and maybe entirely,
> on letting non-superusers do more things, with appropriate security
> controls. The superuser can ultimately do anythi
On 2024-Jun-19, Peter Geoghegan wrote:
> On Wed, Jun 19, 2024 at 1:00 PM Yura Sokolov wrote:
> > So it is quite different code paths, and one could not be used
> > to decline or justify other.
>
> The point is that we shouldn't need to rely on what is formally a
> hint. It might be useful to use
On 2024-Jun-14, Anton A. Melnikov wrote:
> Hello!
>
> The src/backend/access/heap/README.tuplock says about HEAP_XMAX_INVALID bit
> that "Any tuple with this bit set does not have a valid value stored in XMAX."
>
> Found that FreezeMultiXactId() tries to process such an invalid multi xmax
> and
1 - 100 of 2642 matches
Mail list logo
