Re: First draft of PG 17 release notes

On Sat, 11 May 2024 at 17:32, Andy Fan wrote: > Do you think we need to add the following 2 items? > > - 9f133763961e280d8ba692bcad0b061b861e9138 this is an optimizer > transform improvement. I think this should be in the release notes. Suggest: * Allow correlated IN subqueries to be

Re: First draft of PG 17 release notes

Hello Bruce, > I have committed the first draft of the PG 17 release notes; you can > see the results here: > > https://momjian.us/pgsql_docs/release-17.html Thank you for working on this! > I welcome feedback. For some reason it was an easier job than usual. Do you think we need to

Re: WAL record CRC calculated incorrectly because of underlying buffer modification

11.05.2024 07:25, Thomas Munro wrote: On Sat, May 11, 2024 at 4:00 PM Alexander Lakhin wrote: 11.05.2024 06:26, Thomas Munro wrote: Perhaps a no-image, no-change registered buffer should not be including an image, even for XLR_CHECK_CONSISTENCY? It's actually useless for consistency checking

Re: WAL record CRC calculated incorrectly because of underlying buffer modification

On Sat, May 11, 2024 at 4:00 PM Alexander Lakhin wrote: > 11.05.2024 06:26, Thomas Munro wrote: > > Perhaps a no-image, no-change registered buffer should not be > > including an image, even for XLR_CHECK_CONSISTENCY? It's actually > > useless for consistency checking too I guess, this issue

Re: WAL record CRC calculated incorrectly because of underlying buffer modification

Hello Thomas and Andres, Thank you for looking at this! 11.05.2024 06:26, Thomas Munro wrote: On Sat, May 11, 2024 at 3:57 AM Andres Freund wrote: On 2024-05-10 16:00:01 +0300, Alexander Lakhin wrote: and discovered that XLogRecordAssemble() calculates CRC over a buffer, that might be

Re: WAL record CRC calculated incorrectly because of underlying buffer modification

On Sat, May 11, 2024 at 3:57 AM Andres Freund wrote: > On 2024-05-10 16:00:01 +0300, Alexander Lakhin wrote: > > and discovered that XLogRecordAssemble() calculates CRC over a buffer, > > that might be modified by another process. > > If, with "might", you mean that it's legitimate for that

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

Mark Dilger writes: > Regardless of which of 1..4 you pick, I think it could all do with more > regression test coverage. Indeed. If we have no regression tests that reach this code, it's folly to touch it at all, but most especially so post-feature-freeze. I think the *first* order of

Why is citext/regress failing on hamerkop?

For example, 'i'::citext = 'İ'::citext fails to be true. It must now be using UTF-8 (unlike, say, Drongo) and non-C ctype, given that the test isn't skipped. This isn't the first time that we've noticed that Windows doesn't seem to know about İ→i (see [1]), but I don't think anyone has explained

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

> On May 10, 2024, at 12:05 PM, Alexander Korotkov wrote: > > The only bt_target_page_check() caller is > bt_check_level_from_leftmost(), which overrides state->target in the > next iteration anyway. I think the patch is just refactoring to > eliminate the confusion pointer by Peter

Re: Support tid range scan in parallel?

On Fri, 10 May 2024 at 05:16, Cary Huang wrote: > I understand that the regression tests for parallel ctid range scan is a > bit lacking now. It only has a few EXPLAIN clauses to ensure parallel > workers are used when tid ranges are specified. They are added as > part of select_parallel.sql

Re: Use generation memory context for tuplestore.c

Thanks for having a look at this. On Sat, 11 May 2024 at 04:34, Dmitry Dolgov <9erthali...@gmail.com> wrote: > Do I understand correctly, that the efficiency of generation memory > context could be measured directly via counting number of malloc/free > calls? In those experiments I've conducted

Re: First draft of PG 17 release notes

On Fri, May 10, 2024 at 05:31:33PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Fri, May 10, 2024 at 06:50:54PM +0200, Jelte Fennema-Nio wrote: > >> There are two commits that I think would benefit from being listed > >> (but maybe they are already listed and I somehow missed them, or

Re: First draft of PG 17 release notes

Bruce Momjian writes: > On Fri, May 10, 2024 at 06:50:54PM +0200, Jelte Fennema-Nio wrote: >> There are two commits that I think would benefit from being listed >> (but maybe they are already listed and I somehow missed them, or they >> are left out on purpose for some reason): > I looked at

Re: First draft of PG 17 release notes

On Fri, May 10, 2024 at 06:50:54PM +0200, Jelte Fennema-Nio wrote: > On Thu, 9 May 2024 at 06:04, Bruce Momjian wrote: > > > > I have committed the first draft of the PG 17 release notes; you can > > see the results here: > > > > https://momjian.us/pgsql_docs/release-17.html > > Great

Re: Augmenting the deadlock message with application_name

On Fri, May 10, 2024 at 08:10:58PM +, Karoline Pauls wrote: > On Friday, 10 May 2024 at 20:17, Bruce Momjian > wrote: > > > > log_line_prefix supports application name --- why would you not use > > that? > > > > log_line_prefix is effective in the server log. This change is mostly > about

Re: Augmenting the deadlock message with application_name

Karoline Pauls writes: > On Friday, 10 May 2024 at 20:17, Bruce Momjian wrote: >> log_line_prefix supports application name --- why would you not use >> that? > log_line_prefix is effective in the server log. This change is mostly about > improving the message sent back to the client. While

Re: pg_sequence_last_value() for unlogged sequences on standbys

On Wed, May 08, 2024 at 11:01:01AM +0900, Michael Paquier wrote: > On Tue, May 07, 2024 at 02:39:42PM -0500, Nathan Bossart wrote: >> Okay, phew. We can still do something like v3-0002 for v18. I'll give >> Michael a chance to comment on 0001 before committing/back-patching that >> one. > >

Re: First draft of PG 17 release notes

Mhd Enviado desde Outlook para Android From: Bruce Momjian Sent: Friday, May 10, 2024 4:47:04 PM To: Daniel Verite Cc: PostgreSQL-development Subject: Re: First draft of PG 17 release notes On Fri, May 10, 2024 at 06:29:11PM +0200,

Re: Augmenting the deadlock message with application_name

On Friday, 10 May 2024 at 20:17, Bruce Momjian wrote: > > log_line_prefix supports application name --- why would you not use > that? > log_line_prefix is effective in the server log. This change is mostly about improving the message sent back to the client. While the server log is also

Re: BitmapHeapScan streaming read user and prelim refactoring

On Thu, May 2, 2024 at 5:37 PM Tomas Vondra wrote: > > > > On 4/24/24 22:46, Melanie Plageman wrote: > > On Tue, Apr 23, 2024 at 6:43 PM Tomas Vondra > > wrote: > >> > >> On 4/23/24 18:05, Melanie Plageman wrote: > >>> The patch with a fix is attached. I put the test in > >>>

Re: First draft of PG 17 release notes

On Fri, May 10, 2024 at 06:29:11PM +0200, Daniel Verite wrote: > Bruce Momjian wrote: > > > have committed the first draft of the PG 17 release notes; you can > > see the results here: > > > > https://momjian.us/pgsql_docs/release-17.html > > In the psql items, I'd suggest

Re: open items

On Fri, May 10, 2024 at 7:14 AM Alvaro Herrera wrote: > A possible complaint is that the upgrade mechanics which are mostly in > pg_dump with some pieces in pg_upgrade are not very explicitly > documented. There are already comments in all relevant places, but > perhaps an overall picture is

Re: open items

On Fri, May 10, 2024 at 8:48 AM Melanie Plageman wrote: > Sorry, yes, the trivial fix has been done for a while. There is one > outstanding feedback on the patch: an update to one of the comments > suggested by Tomas. I got distracted by trying to repro and fix a bug > from the section "live

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

> On May 10, 2024, at 11:42 AM, Pavel Borisov wrote: > > IMO 0003 doesn't introduce nor fixes a bug. It loads rightpage into a local > variable, rather that to a BtreeCheckState that can have another users of > state->target afterb uniqueness check in the future, but don't have now. So >

Re: Augmenting the deadlock message with application_name

On Thu, May 9, 2024 at 11:44:03PM +, Karoline Pauls wrote: > As we know, the deadlock error message isn't the most friendly one. All the > client gets back is process PIDs, transaction IDs, and lock types. You have to > check the server log to retrieve lock details. This is tedious. > > In

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

On Fri, May 10, 2024 at 8:35 PM Mark Dilger wrote: > > On May 10, 2024, at 5:10 AM, Pavel Borisov wrote: > > On Fri, 10 May 2024 at 12:39, Alexander Korotkov > > wrote: > > On Fri, May 10, 2024 at 3:43 AM Tom Lane wrote: > > > Alexander Korotkov writes: > > > > The revised patchset is

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

On Fri, 10 May 2024, 22:42 Pavel Borisov, wrote: > Hi, Mark! > > > On Fri, 10 May 2024, 21:35 Mark Dilger, > wrote: > >> >> >> > On May 10, 2024, at 5:10 AM, Pavel Borisov >> wrote: >> > >> > Hi, Alexander! >> > >> > On Fri, 10 May 2024 at 12:39, Alexander Korotkov >> wrote: >> > On Fri, May

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

Hi, Mark! On Fri, 10 May 2024, 21:35 Mark Dilger, wrote: > > > > On May 10, 2024, at 5:10 AM, Pavel Borisov > wrote: > > > > Hi, Alexander! > > > > On Fri, 10 May 2024 at 12:39, Alexander Korotkov > wrote: > > On Fri, May 10, 2024 at 3:43 AM Tom Lane wrote: > > > Alexander Korotkov writes:

Re: Bug: PGTYPEStimestamp_from_asc() in ECPG pgtypelib

Hi Tom, Thank you for comment. >> At current implementation, PGTYPEStimestamp_from_asc returns -1. > It looks to me like it returns 0 ("noresult"). Where are you seeing -1? I took a mistake. Sorry. PGTYPEStimestamp_from_asc returns 0(noresult). PGTYPEStimestamp_fmt_asc given 'noresult' returns

Augmenting the deadlock message with application_name

As we know, the deadlock error message isn't the most friendly one. All the client gets back is process PIDs, transaction IDs, and lock types. You have to check the server log to retrieve lock details. This is tedious. In one of my apps I even added a deadlock exception handler on the app side

Re: wrong comment in libpq.h

It looks like this wording "prototypes for functions in" is used many times in src/include/, in many cases equally inaccurately, so I would suggest creating a more comprehensive patch for this. I noticed this "prototypes for functions in" in many header files and briefly checked them. It

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

> On May 10, 2024, at 5:10 AM, Pavel Borisov wrote: > > Hi, Alexander! > > On Fri, 10 May 2024 at 12:39, Alexander Korotkov wrote: > On Fri, May 10, 2024 at 3:43 AM Tom Lane wrote: > > Alexander Korotkov writes: > > > The revised patchset is attached. I applied cosmetical changes. I'm >

Re: First draft of PG 17 release notes

On Thu, 9 May 2024 at 06:04, Bruce Momjian wrote: > > I have committed the first draft of the PG 17 release notes; you can > see the results here: > > https://momjian.us/pgsql_docs/release-17.html Great work! There are two commits that I think would benefit from being listed (but maybe

Re: Use generation memory context for tuplestore.c

On Sat, 4 May 2024 at 04:02, David Rowley wrote: > > On Sat, 4 May 2024 at 03:51, Matthias van de Meent > wrote: > > Was a bump context considered? If so, why didn't it make the cut? > > If tuplestore_trim is the only reason why the type of context in patch > > 2 is a generation context, then

Re: Use generation memory context for tuplestore.c

> On Sat, May 04, 2024 at 01:55:22AM +1200, David Rowley wrote: > (40af10b57 did this for tuplesort.c, this is the same, but for tuplestore.c) An interesting idea, thanks. I was able to reproduce the results of your benchmark and get similar conclusions from the results. > Using generation has

Re: First draft of PG 17 release notes

Bruce Momjian wrote: > have committed the first draft of the PG 17 release notes; you can > see the results here: > > https://momjian.us/pgsql_docs/release-17.html In the psql items, I'd suggest mentioning https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=90f5178

Re: Fix parallel vacuum buffer usage reporting

On Fri, May 10, 2024 at 7:26 PM Nazir Bilal Yavuz wrote: > > Hi, > > Thank you for working on this! > > On Wed, 1 May 2024 at 06:37, Masahiko Sawada wrote: > > > > Thank you for further testing! I've pushed the patch. > > I realized a behaviour change while looking at 'Use pgBufferUsage for >

Re: WAL record CRC calculated incorrectly because of underlying buffer modification

Hi, On 2024-05-10 16:00:01 +0300, Alexander Lakhin wrote: > and discovered that XLogRecordAssemble() calculates CRC over a buffer, > that might be modified by another process. If, with "might", you mean that it's legitimate for that buffer to be modified, I don't think so. The bug is that

Re: Fix parallel vacuum buffer usage reporting

Hi, On Fri, 10 May 2024 at 16:55, Nazir Bilal Yavuz wrote: > > Hi, > > On Fri, 10 May 2024 at 16:21, Nazir Bilal Yavuz wrote: > > > > Hi, > > > > On Fri, 10 May 2024 at 14:49, Alena Rybakina > > wrote: > > > > > > Hi! I could try to check it with the test, but I want to ask you about > > >

End-of-cycle code beautification tasks

Per src/tools/RELEASE_CHANGES, we still have some routine tasks to finish before beta1: * Run mechanical code beautification tools: pgindent, pgperltidy, and "make reformat-dat-files" (complete steps from src/tools/pgindent/README) * Renumber any manually-assigned OIDs between 8000 and

Re: Bug: PGTYPEStimestamp_from_asc() in ECPG pgtypelib

"Ryo Matsumura (Fujitsu)" writes: >> But how come we haven't noticed that >> before? Have you added a setlocale() call somewhere? > I didn't notice to this point. > I added setlocale() to ECPG in my local branch. > I will test again after removing it. > It looks to me like existing ECPG code

Serverside SNI support in libpq

SNI was brought up the discussions around the ALPN work, and I have had asks for it off-list, so I decided to dust off an old patch I started around the time we got client-side SNI support but never finished (until now). Since there is discussion and thinking around how we handle SSL right now I

Re: Fix parallel vacuum buffer usage reporting

Hi, On Fri, 10 May 2024 at 16:21, Nazir Bilal Yavuz wrote: > > Hi, > > On Fri, 10 May 2024 at 14:49, Alena Rybakina wrote: > > > > Hi! I could try to check it with the test, but I want to ask you about > > details, because I'm not sure that I completely understand the test case. > > > > You

Re: Direct SSL connection with ALPN and HBA rules

On 29/04/2024 22:32, Jacob Champion wrote: On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas wrote: There is a small benefit with sslmode=prefer if you connect to a server that doesn't support SSL, though. With sslnegotiation=direct, if the server rejects the direct SSL connection, the

Re: First draft of PG 17 release notes

On Fri, May 10, 2024 at 01:54:30PM +0530, Bharath Rupireddy wrote: > On Thu, May 9, 2024 at 9:34 AM Bruce Momjian wrote: > > > > I have committed the first draft of the PG 17 release notes; you can > > see the results here: > > > > https://momjian.us/pgsql_docs/release-17.html > > > > It

Re: open items

> On 10 May 2024, at 14:48, Melanie Plageman wrote: > > On Thu, May 9, 2024 at 3:28 PM Robert Haas wrote: >> >> Just a few reminders about the open items list at >> https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items -- >> >> * Incorrect Assert in heap_end/rescan for BHS. Either the

Re: SQL:2011 application time

I have committed the v2-0001-Fix-ON-CONFLICT-DO-NOTHING-UPDATE-for-temporal-in.patch from this (confusingly, there was also a v2 earlier in this thread), and I'll continue working on the remaining items. On 09.05.24 06:24, Paul Jungwirth wrote: Here are a couple new patches, rebased to

Re: Fix parallel vacuum buffer usage reporting

Hi, On Fri, 10 May 2024 at 14:49, Alena Rybakina wrote: > > Hi! I could try to check it with the test, but I want to ask you about > details, because I'm not sure that I completely understand the test case. > > You mean that we need to have two backends and on one of them we deleted > the tuples

WAL record CRC calculated incorrectly because of underlying buffer modification

Hello hackers, I've investigated a recent buildfarm failure: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dodo=2024-05-02%2006%3A40%3A36 where the test failed due to a CRC error: 2024-05-02 17:08:18.401 ACST [3406:7] LOG:  incorrect resource manager data checksum in record at

Re: open items

On Thu, May 9, 2024 at 3:28 PM Robert Haas wrote: > > Just a few reminders about the open items list at > https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items -- > > * Incorrect Assert in heap_end/rescan for BHS. Either the description > of this item is inaccurate, or we've been unable to

Re: pgsql: Fix overread in JSON parsing errors for incomplete byte sequence

On 2024-May-10, Alvaro Herrera wrote: > Not sure what's going on here, or why it fails for me while the > buildfarm is all happy. Ah, I ran 'git clean -dfx' and now it works correctly. I must have had an incomplete rebuild. -- Álvaro Herrera PostgreSQL Developer —

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

Hi, Alexander! On Fri, 10 May 2024 at 12:39, Alexander Korotkov wrote: > On Fri, May 10, 2024 at 3:43 AM Tom Lane wrote: > > Alexander Korotkov writes: > > > The revised patchset is attached. I applied cosmetical changes. I'm > > > going to push it if no objections. > > > > Is this really

Re: pgsql: Fix overread in JSON parsing errors for incomplete byte sequence

On 2024-May-09, Michael Paquier wrote: > Fix overread in JSON parsing errors for incomplete byte sequences I'm getting this error in the new test: t/002_inline.pl 1/? # Failed test 'incomplete UTF-8 sequence, chunk size 3: correct error output' # at t/002_inline.pl

Re: Fix parallel vacuum buffer usage reporting

Hi! I could try to check it with the test, but I want to ask you about details, because I'm not sure that I completely understand the test case. You mean that we need to have two backends and on one of them we deleted the tuples before vacuum called the other, do you? On 10.05.2024 13:25,

Re: Parallel CREATE INDEX for GIN indexes

On 5/10/24 07:53, Andy Fan wrote: > > Tomas Vondra writes: > >>> I guess both of you are talking about worker process, if here are >>> something in my mind: >>> >>> *btbuild* also let the WORKER dump the tuples into Sharedsort struct >>> and let the LEADER merge them directly. I think this aim

Re: open items

On 2024-May-09, Robert Haas wrote: > * not null constraints break dump/restore. I asked whether all of the > issues had been addressed here and Justin Pryzby opined that the only > thing that was still relevant for this release was a possible test > case change, which I would personally consider

Re: Use pgBufferUsage for block reporting in analyze

On Fri, May 10, 2024 at 10:54:07AM +0200, Anthonin Bonnefoy wrote: > This patch replaces those Vacuum specific variables by pgBufferUsage > in analyze. This makes VacuumPage{Hit,Miss,Dirty} unused and removable. > This commit removes both their calls in bufmgr and their declarations. Hmm, yeah,

Re: Fix parallel vacuum buffer usage reporting

Hi, Thank you for working on this! On Wed, 1 May 2024 at 06:37, Masahiko Sawada wrote: > > Thank you for further testing! I've pushed the patch. I realized a behaviour change while looking at 'Use pgBufferUsage for block reporting in analyze' thread [1]. Since that change applies here as well,

Re: consider -Wmissing-variable-declarations

On 09/05/2024 12:23, Peter Eisentraut wrote: In [0] I had noticed that we have no automated verification that global variables are declared in header files. (For global functions, we have this through -Wmissing-prototypes.) As I mentioned there, I discovered the Clang compiler option

Re: gcc 12.1.0 warning

Hi, On Tue, 23 Apr 2024 at 19:59, Andres Freund wrote: > > > Which seems entirely legitimate. ISTM that guc_var_compare() ought to only > cast the pointers to the key type, i.e. char *. And incidentally that does > prevent the warning. > > The reason it doesn't happen in newer versions of

Use pgBufferUsage for block reporting in analyze

Hi, Analyze logs within autovacuum uses specific variables VacuumPage{Hit,Miss,Dirty} to track the buffer usage count. However, pgBufferUsage already provides block usage tracking and handles more cases (temporary tables, parallel workers...). Those variables were only used in two places, block

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

On Fri, May 10, 2024 at 3:43 AM Tom Lane wrote: > Alexander Korotkov writes: > > The revised patchset is attached. I applied cosmetical changes. I'm > > going to push it if no objections. > > Is this really suitable material to be pushing post-feature-freeze? > It doesn't look like it's fixing

Re: First draft of PG 17 release notes

On Thu, May 9, 2024 at 9:34 AM Bruce Momjian wrote: > > I have committed the first draft of the PG 17 release notes; you can > see the results here: > > https://momjian.us/pgsql_docs/release-17.html > > It will be improved until the final release. The item count is 188, > which is

Re: Parallel CREATE INDEX for GIN indexes

Tomas Vondra writes: >> I guess both of you are talking about worker process, if here are >> something in my mind: >> >> *btbuild* also let the WORKER dump the tuples into Sharedsort struct >> and let the LEADER merge them directly. I think this aim of this design >> is it is potential to

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

Hi, Tom! On Fri, 10 May 2024, 04:43 Tom Lane, wrote: > Alexander Korotkov writes: > > The revised patchset is attached. I applied cosmetical changes. I'm > > going to push it if no objections. > > Is this really suitable material to be pushing post-feature-freeze? > It doesn't look like it's