Re: Doc: clarify the log message level of the VERBOSE option

On 2024-12-05 16:23, Yugo NAGATA wrote: - Prints a progress report as each table is clustered. + Prints a progress report as each table is clustered, + at INFO level. I feel like the comma could not be necessary here like the fix for the ANALYZE document, but it might be better

Re: shared-memory based stats collector - v70

Hi, On Thu, Dec 05, 2024 at 02:43:43PM +0900, Michael Paquier wrote: > On Wed, Dec 04, 2024 at 03:24:55PM +, Bertrand Drouvot wrote: > > Thanks! I've the feeling that something has to be fixed, see my comments in > > [1]. It might be that the failed assertion does not handle a "valid" > > sce

Re: Doc: clarify the log message level of the VERBOSE option

On Thu, 05 Dec 2024 10:39:22 +0900 Masahiro Ikeda wrote: > On 2024-12-04 21:08, Yugo Nagata wrote: > > This would prevent other users from make a misunderstanding as you did. > > > > I found the description on amvalidate also explains a message is > > output at INFO level. > > ( https://www.post

Re: Missing LWLock protection in pgstat_reset_replslot()

Hi, On Thu, Dec 05, 2024 at 01:26:38PM +0900, Michael Paquier wrote: > On Wed, Dec 04, 2024 at 03:20:03PM +, Bertrand Drouvot wrote: > > I need to think more about it but it seems to me that those values make > > sense, > > so maybe we should drop the entry for this particular case (shmem_exi

Re: generic plans and "initial" pruning

On Thu, Dec 5, 2024 at 2:20 AM Tomas Vondra wrote: > On 12/4/24 14:34, Amit Langote wrote: > > On Mon, Dec 2, 2024 at 3:36 AM Tomas Vondra wrote: > >> 0001 > >> > >> > >> 1) But if we don't expect this error to actually happen, do we really > >> need to make it ereport()? Maybe it should be

Re: simplify regular expression locale global variables

On 03.12.24 20:19, Jeff Davis wrote: 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 pat

Re: Pass ParseState as down to utility functions.

On Wed, Dec 04, 2024 at 03:31:47PM +0500, Kirill Reshke wrote: > On Sat, 30 Nov 2024 at 17:37, jian he wrote: >> So I guess bundling it into a single patch should be fine? > > Ok. I created CF entry for this patch. > > [0] https://commitfest.postgresql.org/51/5420/ Note that v3 of the patch is

Re: Possible integer overflow in bringetbitmap()

On Wed, Dec 04, 2024 at 02:05:10PM -0800, James Hunter wrote: > So, I think your patch should be, instead, to cast either "totalpages" > or "10" to "int64", in the return statement. totalpages is signed, and BlockNumber is unsigned. Hence in theory you could always fall into a trap once totalpage

Re: shared-memory based stats collector - v70

On Wed, Dec 04, 2024 at 03:24:55PM +, Bertrand Drouvot wrote: > Thanks! I've the feeling that something has to be fixed, see my comments in > [1]. It might be that the failed assertion does not handle a "valid" scenario. > > [1]: > https://www.postgresql.org/message-id/Z1BzI/eMTCOKA%2Bj6%40ip

Re: date_trunc invalid units with infinite value

On Sun, Dec 01, 2024 at 03:09:17PM -0500, Joseph Koshakow wrote: > When looking at the date_trunc function, I noticed that it wasn't > rejecting invalid units if the value was infinite. It's slightly > annoying to fix this, but we already do something very similar for > date_part. I have attached a

Re: NOT ENFORCED constraint feature

hi. accidentally hit segfault. create table c11 (a int not enforced); create table c11 (a int enforced); we can solve it via the following or changing SUPPORTS_ATTRS accordingly. diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c index 5ab44149e5..fe1116c092 10064

Re: Memory leak in WAL sender with pgoutput (v10~)

On Thu, Dec 05, 2024 at 04:31:56AM +, Zhijie Hou (Fujitsu) wrote: > I realized that this patch cannot be backpatched because it introduces a new > field into the public PGOutputData structure. Therefore, I think we may need > to > use Alvaro's version [1] for the back branches. > > [1] > htt

RE: Memory leak in WAL sender with pgoutput (v10~)

On Wednesday, December 4, 2024 7:39 PM Michael Paquier wrote: > > On Wed, Dec 04, 2024 at 06:42:55AM +, Zhijie Hou (Fujitsu) wrote: > > I can try to write a patch if no one else is working on this. > > If you have some room to write a patch, that would be really nice. > Thanks. No problem.

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Dec 5, 2024 at 4:29 PM Tom Lane wrote: > Thomas Munro writes: > > Ahh, correction, it does define it (or else perl would have > > complained), but it seems that meson magically puts it into the > > compiler command line without being asked. So it is defined without > > pg_config.h being

Re: Missing LWLock protection in pgstat_reset_replslot()

On Wed, Dec 04, 2024 at 03:20:03PM +, Bertrand Drouvot wrote: > I need to think more about it but it seems to me that those values make sense, > so maybe we should drop the entry for this particular case (shmem_exit()). The values reported in the central hash table make sense to me. What does

Re: Windows pg_basebackup unable to create >2GB pg_wal.tar tarballs ("could not close file: Invalid argument" when creating pg_wal.tar of size ~ 2^31 bytes)

Today while trying to figure out why CI didn't pick up a mistake but the build farm did, I learned a couple of interesting new-to-me facts that are relevant to this thread: 1. When meson builds on "Linux-like" systems (by which it means GCC or Clang detected, and MinGW is GCC), it jams -D_FILE_OF

Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY

On Thu, Dec 5, 2024 at 2:41 PM Amit Kapila wrote: > > On Thu, Dec 5, 2024 at 7:34 AM Peter Smith wrote: > > > > IIUC, these errors are intended for when there is *any* unpublished > > generated column found in the RI, and the RI might also have other > > columns in it generated or otherwise. So,

Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY

On Thu, Dec 5, 2024 at 7:34 AM Peter Smith wrote: > > IIUC, these errors are intended for when there is *any* unpublished > generated column found in the RI, and the RI might also have other > columns in it generated or otherwise. So, I think those error messages > saying "consists of" should be r

Re: Cannot find a working 64-bit integer type on Illumos

Thomas Munro writes: > On Thu, Dec 5, 2024 at 1:59 PM Thomas Munro wrote: >> I was trying to figure out how I missed this, and I think it might be >> that the meson build scripts didn't port AC_SYS_LARGEFILES. So if you >> build on a 32 bit Linux system with meson (like one of CI's tasks, and >>

Re: generic plans and "initial" pruning

On Thu, Dec 5, 2024 at 2:32 AM Tom Lane wrote: > Tomas Vondra writes: > > I'm not forcing you to do elog, if you think ereport() is better. I'm > > only asking because AFAIK the "policy" is that ereport is for cases that > > think can happen (and thus get translated), while elog(ERROR) is for > >

Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY

Hi, I was looking at the recently pushed code [1]. IMO the wording of some of those new error messages of function CheckCmdReplicaIdentity() is not quite correct. According to my understanding, and according also to Chat-GPT: -- The sentence "Replica identity consists of an unpublished genera

Re: [Bug] Heap Use After Free in parallel_vacuum_reset_dead_items Function

On Tue, Nov 26, 2024 at 4:53 PM John Naylor wrote: > Thanks for the report! I don't see any immediate evidence of deleterious > effects, but it's still sloppy. To reduce risk going forward, I think we > should always access this pointer via the struct rather than a separate copy, > quick attemp

Re: Doc: clarify the log message level of the VERBOSE option

On 2024-12-04 21:08, Yugo Nagata wrote: This would prevent other users from make a misunderstanding as you did. I found the description on amvalidate also explains a message is output at INFO level. ( https://www.postgresql.org/docs/devel/index-functions.html ) Problems should be reported wit

Re: Cannot find a working 64-bit integer type on Illumos

Thomas Munro writes: > If someone wants to define things like that before potentially > including system headers, they're not going about it the right way if > they're including our headers first (or anything at all not under > their direct control). But OK, I can work with the > not-broken-so-do

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Wed, Dec 4, 2024 at 9:27 PM vignesh C wrote: > ... > > Currently, replication slots are invalidated based on the > replication_slot_inactive_timeout only during a checkpoint. This means > that if the checkpoint_timeout is set to a higher value than the > replication_slot_inactive_timeout, slot

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Dec 5, 2024 at 1:59 PM Thomas Munro wrote: > I was trying to figure out how I missed this, and I think it might be > that the meson build scripts didn't port AC_SYS_LARGEFILES. So if you > build on a 32 bit Linux system with meson (like one of CI's tasks, and > also build farm animal adde

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Dec 5, 2024 at 10:03 AM Thomas Munro wrote: > The affected systems are mostly running ancient OSes, and lapwing is > 32 bit x86, so it's not only armv7. Current 32 bit x86 systems are > working fine. I was trying to figure out how I missed this, and I think it might be that the meson bui

Re: Introduce XID age and inactive timeout based replication slot invalidation

Hi Nisha, Here are my review comments for the v53* patch set // Patch v53-0001. == src/backend/replication/slot.c 1. + if (error_if_invalid && + s->data.invalidated != RS_INVAL_NONE) Looks like some unnecessary wrapping here. I think this condition can be on one line. //

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Dec 5, 2024 at 12:16 PM Tom Lane wrote: > In c.h, I'd put in a very explicit comment in front of pg_config.h. > Also, I don't like making it look like postgres_ext.h is of the > same ilk as the config headers, since it isn't. So maybe like > > /* > * These headers must be included before

Re: Collation & ctype method table, and extension hooks

On Mon, 2024-12-02 at 16:39 +0100, Andreas Karlsson wrote: > My patches: > > = v9-0002-Move-check-for-ucol_strcollUTF8-to-pg_locale_icu..patch Committed. > = v9-0003-Move-code-for-collation-version-into-provider-spe.patch > > Moves some code from pg_collate.c into provider specific files. I ag

Re: Make tuple deformation faster

Hi, On 2024-12-05 11:52:01 +1300, David Rowley wrote: > On Thu, 5 Dec 2024 at 03:51, Andres Freund wrote: > > Possibly stupid idea: Could we instead store the attributes *before* the > > main > > TupleDescData, with increasing "distance" for increased attnos? That way we > > wouldn't need to ca

Re: SCRAM pass-through authentication for postgres_fdw

On Wed, Dec 4, 2024 at 3:39 PM Jacob Champion wrote: > actual pass-through SCRAM (This was probably not a helpful way to describe what I'm talking about; the method here in the thread could be considered "actual pass-through SCRAM" as well. Proxied SCRAM, maybe?) --Jacob

Re: SCRAM pass-through authentication for postgres_fdw

On Wed, Dec 4, 2024 at 3:05 PM Jelte Fennema-Nio wrote: > I only see advantages over the > alternative, which is copying the plaintext password around. In case > of compromise of the server, only the salt+verifier has to be rotated, > not the actual user password. Sure, I'm not saying it's worse

Re: deferred writing of two-phase state files adds fragility

Hi, On 2024-12-04 12:04:47 -0500, Robert Haas wrote: > Let's suppose that you execute PREPARE TRANSACTION and, before the > next CHECKPOINT, the WAL record for the PREPARE TRANSACTION gets > corrupted on disk. This might seem like an unlikely scenario, and it > is, but we saw a case at EDB not too

Re: Make tuple deformation faster

On Wed, 4 Dec 2024 at 23:52, David Rowley wrote: > > On Thu, 5 Dec 2024 at 03:51, Andres Freund wrote: > > Possibly stupid idea: Could we instead store the attributes *before* the > > main > > TupleDescData, with increasing "distance" for increased attnos? That way we > > wouldn't need to calcu

Re: Cannot find a working 64-bit integer type on Illumos

Thomas Munro writes: > On Thu, Dec 5, 2024 at 10:58 AM Thomas Munro wrote: >> On Thu, Dec 5, 2024 at 10:55 AM Tom Lane wrote: >>> Could another way be to read pg_config.h before postgres_ext.h? >>> I think the current order was intentional, but maybe the >>> disadvantages outweigh the advantages

Re: SCRAM pass-through authentication for postgres_fdw

On Wed, 4 Dec 2024 at 23:11, Jacob Champion wrote: > It makes me a little uneasy to give users a reason to copy identical > salts/verifiers around... But for e.g. a loopback connection, it seems > like there'd be no additional risk. Is that the target use case? I don't think that necessarily has

Re: Proposal: Role Sandboxing for Secure Impersonation

On Wed, 4 Dec 2024 at 22:05, Robert Haas wrote: > I do think the protocol change is better. Fully agreed. But I now also know the herculean amount of effort that's necessary for that to happen, and I personally don't have the bandwidth to push that through anymore. So I'm definitely open to a SQL

Re: Make tuple deformation faster

On Thu, 5 Dec 2024 at 03:51, Andres Freund wrote: > Possibly stupid idea: Could we instead store the attributes *before* the main > TupleDescData, with increasing "distance" for increased attnos? That way we > wouldn't need to calculate any variable offsets. Of course the price would be > to have

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Dec 5, 2024 at 10:58 AM Thomas Munro wrote: > On Thu, Dec 5, 2024 at 10:55 AM Tom Lane wrote: > > Could another way be to read pg_config.h before postgres_ext.h? > > I think the current order was intentional, but maybe the > > disadvantages outweigh the advantages now. > > Yeah I was just

Re: Proposal: Role Sandboxing for Secure Impersonation

> On 4 Dec 2024, at 17:13, Eric Hanson wrote: > > On Mon, Dec 2, 2024 at 10:31 AM Wolfgang Walther > wrote: >> Eric Hanson: >> > a) Transaction ("local") Sandbox: >> > - SET LOCAL ROLE alice NO RESET; >> > - SET LOCAL ROLE alice WITHOUT RESET; [snip] >> > c) "Gu

Re: SCRAM pass-through authentication for postgres_fdw

On Wed, Dec 4, 2024 at 10:45 AM Matheus Alcantara wrote: > This is achieved by storing the SCRAM ClientKey and ServerKey obtained > during client authentication with the backend. These keys are then > used to complete the SCRAM exchange between the backend and the fdw > server, eliminating the nee

Re: Cannot find a working 64-bit integer type on Illumos

Thomas Munro writes: > On Thu, Dec 5, 2024 at 10:20 AM Tom Lane wrote: >> Another rather serious problem here is that we no longer provide >> macro PG_INT64_TYPE, which seems rather likely to break applications >> that were relying on it. That is part of our external API, we >> can't just remove

Re: Possible integer overflow in bringetbitmap()

On Tue, Nov 26, 2024 at 2:57 AM Evgeniy Gorbanyov wrote: > > Function bringetbitmap() in src/backend/access/brin/brin.c:560 returns type > int64. But the returned variable 'totalpages' is of type int. Maybe it makes > sense to change the type of variable 'totalpages' to int64 to avoid possible

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Dec 5, 2024 at 10:55 AM Tom Lane wrote: > I wrote: > > ... We need this header to be readable without > > any prior system headers, so I'm afraid we're all the way back to > > making configure derive the name of a 64-bit type. > > Could another way be to read pg_config.h before postgres_ex

Re: Cannot find a working 64-bit integer type on Illumos

I wrote: > ... We need this header to be readable without > any prior system headers, so I'm afraid we're all the way back to > making configure derive the name of a 64-bit type. Could another way be to read pg_config.h before postgres_ext.h? I think the current order was intentional, but maybe th

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Dec 5, 2024 at 10:20 AM Tom Lane wrote: > I wrote: > > So apparently, "off_t" was the same as "loff_t" before 962da900a, > > but it no longer is the same on 32-bit machines. > > OK, I see what is happening. On platforms that need it, we define > _FILE_OFFSET_BITS as 64 in pg_config.h to e

Re: Better error message when --single is not the first arg to postgres executable

Committed. -- nathan

Re: Cannot find a working 64-bit integer type on Illumos

I wrote: > So apparently, "off_t" was the same as "loff_t" before 962da900a, > but it no longer is the same on 32-bit machines. OK, I see what is happening. On platforms that need it, we define _FILE_OFFSET_BITS as 64 in pg_config.h to ensure that off_t is big enough. However, 962da900a did this

Re: Potential ABI breakage in upcoming minor releases

On Wed, Dec 04, 2024 at 08:29:57PM +0100, Peter Eisentraut wrote: > On 29.11.24 21:39, Noah Misch wrote: > > > I remembered where that's documented: > > > > > > https://wiki.postgresql.org/wiki/Committing_checklist#Maintaining_ABI_compatibility_while_backpatching > > I'd say the source tree's , >

Re: Proposal: Role Sandboxing for Secure Impersonation

On Wed, Dec 4, 2024 at 2:02 PM Joe Conway wrote: > However on that thread[1] Jelte and Robert expressed a preference to > accomplishing the goal via protocol changes. That is not my preference, > but it would be worth hearing from them how firm they are in their > resolve -- i.e. if we went down t

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Dec 5, 2024 at 8:41 AM Tom Lane wrote: > So apparently, "off_t" was the same as "loff_t" before 962da900a, > but it no longer is the same on 32-bit machines. Right, that's really weird. > (In any case, > if all machines that have copy_file_range define it like this, > perhaps we ought to

Benchmark function for uuidv7()

On Friday 29 November 2024 at 08:55:09 pm GMT+3, Masahiko Sawada wrote: On Fri, Nov 29, 2024 at 5:59 AM Sergey Prokhorenko wrote: > > > > Sergey Prokhorenko sergeyprokhore...@yahoo.com.au > > > On Friday 29 November 2024 at 09:19:33 am GMT+3, Masahiko Sawada > wrote: > > > On Thu, N

Re: Potential ABI breakage in upcoming minor releases

Peter Eisentraut writes: > On 29.11.24 21:39, Noah Misch wrote: >> I'd say the source tree's , >> which >> David Wheeler mentioned, is authoritative. It currently matches >> postgr.es/c/e54a42a. Let's update both or change that wiki heading to point >> to the authoritative doc section. > I don

Re: Cannot find a working 64-bit integer type on Illumos

Also ... grison and turaco are emitting warnings that were not there a couple of days ago: grison| 2024-12-04 17:10:09 | reconstruct.c:701:33: warning: passing argument 2 of 'copy_file_range' from incompatible pointer type [-Wincompatible-pointer-types] turaco| 2024-12-04 16:15

Re: Potential ABI breakage in upcoming minor releases

On 29.11.24 21:39, Noah Misch wrote: I remembered where that's documented: https://wiki.postgresql.org/wiki/ Committing_checklist#Maintaining_ABI_compatibility_while_backpatching I'd say the source tree's , which David Wheeler mentioned, is authoritative. It currently matches postgr.es/c/e54a

Re: Proposal: Role Sandboxing for Secure Impersonation

On 12/4/24 11:13, Eric Hanson wrote: Thanks all for the input so far.  I think we are the "usual suspects" of advocating for this feature. :) Yeah, I looked at the old thread and came to the same conclusion ;-) However on that thread[1] Jelte and Robert expressed a preference to accomplishing

SCRAM pass-through authentication for postgres_fdw

Hi, The attached a patch enables SCRAM authentication for postgres_fdw connections without requiring plain-text password on user mapping properties. This is achieved by storing the SCRAM ClientKey and ServerKey obtained during client authentication with the backend. These keys are then used

Re: deferred writing of two-phase state files adds fragility

Robert Haas writes: > On Wed, Dec 4, 2024 at 12:19 PM Tom Lane wrote: >> Could we fix it so ROLLBACK TRANSACTION removes the GID from the >> list of prepared xacts that need to be written out? Then we'd >> no longer have a pending requirement to read the broken WAL record. > That would be nice,

Re: deferred writing of two-phase state files adds fragility

On Wed, Dec 4, 2024 at 12:58 PM Tom Lane wrote: > Robert Haas writes: > > On Wed, Dec 4, 2024 at 12:19 PM Tom Lane wrote: > >> Could we fix it so ROLLBACK TRANSACTION removes the GID from the > >> list of prepared xacts that need to be written out? Then we'd > >> no longer have a pending requir

Re: deferred writing of two-phase state files adds fragility

On Wed, Dec 4, 2024 at 12:19 PM Tom Lane wrote: > > You can't execute COMMIT > > TRANSACTION or ROLLBACK TRANSACTION, so there's now way to resolve the > > prepared transaction. > > Could we fix it so ROLLBACK TRANSACTION removes the GID from the > list of prepared xacts that need to be written ou

Re: generic plans and "initial" pruning

Tomas Vondra writes: > I'm not forcing you to do elog, if you think ereport() is better. I'm > only asking because AFAIK the "policy" is that ereport is for cases that > think can happen (and thus get translated), while elog(ERROR) is for > cases that we believe shouldn't happen. The proposed cod

Re: [18] Unintentional behavior change in commit e9931bfb75

Peter Eisentraut writes: > On 02.12.24 23:25, Tom Lane wrote: >> Well, also for compatibility with our SQL parser's understanding >> of identifier lowercasing. > Maybe that was relevant before the "name" type got its own collation? downcase_identifier doesn't give a fig about name's collation.

Re: generic plans and "initial" pruning

On 12/4/24 14:34, Amit Langote wrote: > Hi Tomas, > > On Mon, Dec 2, 2024 at 3:36 AM Tomas Vondra wrote: >> Hi, >> >> I took a look at this patch, mostly to familiarize myself with the >> pruning etc. I have a bunch of comments, but all of that is minor, >> perhaps even nitpicking - with prior

Re: deferred writing of two-phase state files adds fragility

Robert Haas writes: > Let's suppose that you execute PREPARE TRANSACTION and, before the > next CHECKPOINT, the WAL record for the PREPARE TRANSACTION gets > corrupted on disk. This might seem like an unlikely scenario, and it > is, but we saw a case at EDB not too long ago. > To a first approxim

Re: checksum verification code breaks backups in v16-

Robert Haas writes: > On Wed, Dec 4, 2024 at 11:10 AM Nathan Bossart > wrote: >> D'oh, sorry. Even so, I think I'd still vote for back-patching the v17 >> commit that inadvertently fixed this. > Gotcha. Let's see if anyone else votes. +1 for a back-patch of 025584a16. It's made it through a

Re: [18] Unintentional behavior change in commit e9931bfb75

On 02.12.24 23:25, Tom Lane wrote: Jeff Davis writes: The behavior is commented (commit 176d5bae1d) in formatting.c: * ... When using the default * collation, we apply the traditional Postgres behavior that * forces ASCII-style treatment of I/i, but in non-default * collatio

Re: CVE-2024-10979 - Does this affect Postgres built without --with-perl option?

On Wed, Dec 4, 2024 at 10:07 AM Mark Hill wrote: > Does the CVE-2024-10979 affect Postgres that is NOT built with the > --with-perl option? > > It requires the attacker being able to write and get executed a PL function in the server written in pl/perl. That is impossible if the server hasn't b

deferred writing of two-phase state files adds fragility

Let's suppose that you execute PREPARE TRANSACTION and, before the next CHECKPOINT, the WAL record for the PREPARE TRANSACTION gets corrupted on disk. This might seem like an unlikely scenario, and it is, but we saw a case at EDB not too long ago. To a first approximation, the world ends. You can'

CVE-2024-10979 - Does this affect Postgres built without --with-perl option?

Does the CVE-2024-10979 affect Postgres that is NOT built with the --with-perl option? Thanks, Mark

Re: UUID v7

> On 2 Dec 2024, at 11:00, Masahiko Sawada wrote: > > The monotonicity of generated UUIDv7 is guaranteed only within a > single backend. I've addressed all items, except formatting a table... I can't build docs to make a reasonable judgement if the table looks OK. Changes: - restored leakpro

Re: Add pg_stat_progress_rewrite view.

Hello, On 2024-Dec-04, Kirill Reshke wrote: > Recently, one administrator asked me how to monitor the progress of > his ALTER TABLE... ALTER COLUMN TYPE bigint. > > That leads me to believe that consumers might benefit from having an > API to track the table change process. I agree that trackin

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

> On 3 Dec 2024, at 22:56, Daniel Gustafsson wrote: > >> 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 i

Re: checksum verification code breaks backups in v16-

On Wed, Dec 4, 2024 at 11:10 AM Nathan Bossart wrote: > D'oh, sorry. Even so, I think I'd still vote for back-patching the v17 > commit that inadvertently fixed this. Gotcha. Let's see if anyone else votes. -- Robert Haas EDB: http://www.enterprisedb.com

Re: Remove remnants of "snapshot too old"

On Wed, Dec 04, 2024 at 09:55:43AM +0200, Heikki Linnakangas wrote: > On 04/12/2024 03:24, Tom Lane wrote: >> Andres Freund writes: >> > Most of this I agree with. But I'm not sure just removing the toast >> > snapshot >> > stuff is good - we've had a bunch of bugs where we don't hold a snapshot

XMLDocument (SQL/XML X030)

Hi, I'd like to propose the implementation of XMLDocument (SQL/XML X030).It basically returns an XML document from a given XML expression, e.g. SELECT   xmldocument(     xmlelement(NAME foo,   xmlattributes(42 AS att),   xmlelement(NAME bar,     xmlconcat('va', 'lue'))     )   );

Re: SQL:2011 application time

On 12/4/24 03:15, Peter Eisentraut wrote: I did some more work on this approach, with the attached patches resulting.  This is essentially what I'm describing above, which in turn is a variation of your patch v45-0001-Fix-logical- replication-for-temporal-tables.patch, with your tests added at t

Re: Proposal: Role Sandboxing for Secure Impersonation

On Mon, Dec 2, 2024 at 10:31 AM Wolfgang Walther wrote: > Eric Hanson: > > a) Transaction ("local") Sandbox: > > - SET LOCAL ROLE alice NO RESET; > > - SET LOCAL ROLE alice WITHOUT RESET; > > - BEGIN AS ROLE alice; > > > > Transaction-level sandboxes have the benefit that a pooler can simply > >

Re: plperl version on the meson setup summary screen

On 2024-11-29 Fr 3:26 AM, Nazir Bilal Yavuz wrote: Hi, On Fri, 29 Nov 2024 at 08:40, Zharkov Roman wrote: Hello, On 2024-11-27 21:50, Andrew Dunstan wrote: it should give the same answer Sometimes "version" and "api_versionstring" are different. Here are two simple examples from my window

Re: checksum verification code breaks backups in v16-

On Wed, Dec 04, 2024 at 09:29:50AM -0500, Robert Haas wrote: > On Tue, Dec 3, 2024 at 5:26 PM Nathan Bossart > wrote: >> I'm only seeing this code in pg_checksums. Is that what you are proposing >> to change? > > No. This code is present in src/backend/backup/basebackup.c in REL_16_STABLE. D'o

Re: [PATCH] SVE popcount support

On Wed, Dec 04, 2024 at 08:51:39AM -0600, Malladi, Rama wrote: > Thank you, Kirill, for the review and the feedback. Please find inline my > reply and an updated patch. Thanks for the updated patch. I have a couple of high-level comments. Would you mind adding this to the commitfest system (https

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

On 12/4/24 10:57, Joe Conway wrote: On 12/4/24 10:01, Daniel Gustafsson wrote: On 4 Dec 2024, at 15:52, Joe Conway wrote: On 12/4/24 09:45, Daniel Gustafsson wrote: On 4 Dec 2024, at 15:40, Joe Conway wrote: On 12/4/24 09:33, Daniel Gustafsson wrote: since OpenSSL 1.1.1 cannot operate in FI

Re: shared-memory based stats collector - v70

Hi, On Wed, Dec 04, 2024 at 04:00:53AM +0300, Anton A. Melnikov wrote: > > 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/postg

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

On 12/4/24 10:01, Daniel Gustafsson wrote: On 4 Dec 2024, at 15:52, Joe Conway wrote: On 12/4/24 09:45, Daniel Gustafsson wrote: On 4 Dec 2024, at 15:40, Joe Conway wrote: On 12/4/24 09:33, Daniel Gustafsson wrote: since OpenSSL 1.1.1 cannot operate in FIPS mode. I don't think that is corre

Re: Missing LWLock protection in pgstat_reset_replslot()

Hi, On Wed, Dec 04, 2024 at 03:45:13AM +0300, Anton A. Melnikov wrote: > 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 > creatio

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

> On 4 Dec 2024, at 15:52, Joe Conway wrote: > > On 12/4/24 09:45, Daniel Gustafsson wrote: >>> On 4 Dec 2024, at 15:40, Joe Conway wrote: >>> On 12/4/24 09:33, Daniel Gustafsson wrote: since OpenSSL 1.1.1 cannot operate in FIPS mode. >>> I don't think that is correct. The RHEL 8 openssl wh

Add pg_stat_progress_rewrite view.

Hi hackers! Recently, one administrator asked me how to monitor the progress of his ALTER TABLE... ALTER COLUMN TYPE bigint. That leads me to believe that consumers might benefit from having an API to track the table change process. PFA draft patch adding number of tuples (tuples_processed) that

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

On 12/4/24 09:45, Daniel Gustafsson wrote: On 4 Dec 2024, at 15:40, Joe Conway wrote: On 12/4/24 09:33, Daniel Gustafsson wrote: since OpenSSL 1.1.1 cannot operate in FIPS mode. I don't think that is correct. The RHEL 8 openssl which was FIPS 140-2 validated is 1.1.1k. See: https://csrc.ni

Re: Make tuple deformation faster

Hi, On 2024-12-05 01:42:36 +1300, David Rowley wrote: > On Tue, 3 Dec 2024 at 16:54, David Rowley wrote: > > After making some last-minute cosmetic adjustments, I've just pushed > > the 0001 patch. > > So that commit broke all of the debug_parallel_query = regress > buildfarm animals. Seems we

Re: Index AM API cleanup

On 27.11.24 13:57, Peter Eisentraut wrote: I think, however, that we should rename RowCompareType.  Otherwise, it's just going to be confusing forevermore.  I suggest to rename it simply to CompareType. I'm going to try to code up the gist support on top of this patch set to make sure that it

Re: add support for the old naming libs convention on windows (ssleay32.lib and libeay32.lib)

> On 2 Dec 2024, at 22:12, Darek Ślusarczyk wrote: > 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] > a

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

> On 4 Dec 2024, at 15:40, Joe Conway wrote: > > On 12/4/24 09:33, Daniel Gustafsson wrote: >> since OpenSSL 1.1.1 cannot operate in FIPS mode. > > I don't think that is correct. The RHEL 8 openssl which was FIPS 140-2 > validated is 1.1.1k. See: > > https://csrc.nist.gov/CSRC/media/projects/c

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

On 12/4/24 09:33, Daniel Gustafsson wrote: since OpenSSL 1.1.1 cannot operate in FIPS mode. I don't think that is correct. The RHEL 8 openssl which was FIPS 140-2 validated is 1.1.1k. See: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-po

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

On Wed, Dec 4, 2024 at 9:33 AM Daniel Gustafsson wrote: > > The comment suggests to me that if the user happened to be using > > OpenSSL 1.1.1 and CheckLegacyCryptoMode() was called, the expected > > outcome would be an error, but it will just return. > > I think I know what you mean, but just to

Re: Eager aggregation, take 3

On Sun, Nov 10, 2024 at 7:52 PM Richard Guo wrote: > Hmm, currently we only consider grouped aggregation for eager > aggregation. For grouped aggregation, the window function's > arguments, as well as the PARTITION BY expressions, must appear in the > GROUP BY clause. That is to say, the depname

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

On Wed, Dec 4, 2024 at 8:54 AM Daniel Gustafsson wrote: > Looking over this again I realized it's a bit silly to fall back on > FIPS_mode() > when EVP_default_properties_is_fips_enabled isn't available since that would > only be OpenSSL versions before 3.0 (and since we don't support 1.0.2 then n

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

> On 4 Dec 2024, at 15:28, Robert Haas wrote: > > On Wed, Dec 4, 2024 at 8:54 AM Daniel Gustafsson wrote: >> Looking over this again I realized it's a bit silly to fall back on >> FIPS_mode() >> when EVP_default_properties_is_fips_enabled isn't available since that would >> only be OpenSSL vers

Re: checksum verification code breaks backups in v16-

On Tue, Dec 3, 2024 at 5:26 PM Nathan Bossart wrote: > 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); > >

Re: Guidance Needed for Testing PostgreSQL Patch (CF-5044)

On 2024-12-04 We 3:07 AM, postgresql_contributors wrote: Hi pg_hackers, I hope you are doing well. I am working on reviewing PostgreSQL community tickets and started with the patch cf/5044. This patch is in the branch cf/5044, and I pulled the code to test it. Here’s what I have done so far:

Re: Serverside SNI support in libpq

> On 4 Dec 2024, at 01:43, Jacob Champion > wrote: > > 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. > >

  1   2   >