RE: [16Beta1][doc] pgstat: Track time of the last scan of a relation

Hi, David. > I've now pushed this change. Thank you so much. -Original Message- From: David Rowley Sent: Monday, June 5, 2023 2:37 PM To: Shinoda, Noriyoshi (PN Japan FSIP) Cc: PostgreSQL-development ; dp...@pgadmin.org; and...@anarazel.de; br...@momjian.us; v...@postgresfriends.org S

Re: Mark a transaction uncommittable

On Sat, Apr 22, 2023 at 8:01 AM Gurjeet Singh wrote: > > This is a proposal for a new transaction characteristic. I haven't > written any code, yet, and am interested in hearing if others may find > this feature useful. Please see attached the patch that introduces this new feature. The patch inc

Re: Mark a transaction uncommittable

On Mon, 2023-06-05 at 00:22 -0700, Gurjeet Singh wrote: > On Sat, Apr 22, 2023 at 8:01 AM Gurjeet Singh wrote: > > > > This is a proposal for a new transaction characteristic. I haven't > > written any code, yet, and am interested in hearing if others may find > > this feature useful. > > Please

Re: pgbench - adding pl/pgsql versions of tests

On Fri, 24 Mar 2023 22:17:33 + Cary Huang wrote: > The following review has been posted through the commitfest application: > make installcheck-world: not tested > Implements feature: tested, passed > Spec compliant: not tested > Documentation:not tested The patc

Re: [PATCH] Slight improvement of worker_spi.c example

Hi Michael, Thanks for your feedback. > + * The order of PushActiveSnapshot() and SPI_connect() is not really > + * important. > > FWIW, looking at the patch, I don't think that this is particularly > useful. Fair enough, here is the corrected patch. -- Best regards, Aleksander Ale

Re: RFC: Logging plan of the running query

On 2023-06-03 02:51, James Coleman wrote: Hello, Thanks for working on this patch! On Thu, Dec 8, 2022 at 12:10 AM torikoshia wrote: BTW, since this patch depends on ProcessInterrupts() and EXPLAIN codes which is used in auto_explain, I'm feeling that the following discussion also applies

Re: PG 16 draft release notes ready

Hello, On Thu, 18 May 2023 16:49:47 -0400 Bruce Momjian wrote: > I have completed the first draft of the PG 16 release notes. You can > see the output here: Thanks for the release notes. > > https://momjian.us/pgsql_docs/release-16.html > > I will adjust it to the feedback I receive;

Re: Partial aggregates pushdown

fujii.y...@df.mitsubishielectric.co.jp писал 2023-06-02 06:54: Hi Mr.Bruce, hackers. I updated the patch. The following is a list of comments received on the previous version of the patch and my update to them in this version of the patch. Hi. I've looked through the last version of the patc

RE: Adding percentile metrics to pg_stat_statements module

Hello While looking at slow queries on pg_stat_statements. I was looking for percentile fields.. If we are worried about CPU cost, maybe it could be useful to turn in on when you have a high stddev_exec_time for the query ? Regards, De : Adrien Nayrat Envo

Re: [PoC] pg_upgrade: allow to upgrade publisher node

On Mon, 22 May 2023 at 15:50, Hayato Kuroda (Fujitsu) wrote: > > Dear Wang, > > Thank you for reviewing! PSA new version. > > > For patches 0001 > > > > 1. The latest patch set fails to apply because the new commit (0245f8d) in > > HEAD. > > I didn't notice that. Thanks, fixed. > > > 2. In file p

Re: Do we want a hashset type?

On Fri, Jun 2, 2023, at 10:01, Ants Aasma wrote: > Have you looked at roaring bitmaps? There is a pg_roaringbitmap > extension [1] already available that offers very fast unions, > intersections and membership tests over integer sets. I used it to get > some pretty impressive performance results fo

Re: [PoC] Improve dead tuple storage for lazy vacuum

Hi, On Tue, May 23, 2023 at 7:17 PM John Naylor wrote: > > I wrote: > > the current insert/delete paths are quite complex. Using bitmap heap scan > > as a motivating use case, I hope to refocus complexity to where it's most > > needed, and aggressively simplify where possible. > > Sometime in t

Re: Avoid unncessary always true test (src/backend/storage/buffer/bufmgr.c)

Em dom., 4 de jun. de 2023 às 23:37, Richard Guo escreveu: > > On Sun, Jun 4, 2023 at 8:42 PM Ranier Vilela wrote: > >> Hi, >> >> Per Coverity. >> >> At function ExtendBufferedRelShared, has a always true test. >> eb.rel was dereferenced one line above, so in >> if (eb.rel) is always true. >> >>

RE: [PATCH] Reuse Workers and Replication Slots during Logical Replication

On Thu, Jun 1, 2023 6:54 PM Melih Mutlu wrote: > > Hi, > > I rebased the patch and addressed the following reviews. > Thanks for updating the patch. Here are some comments on 0001 patch. 1. - ereport(LOG, - (errmsg("logical replication table synchronization worker

Re: Avoid unncessary always true test (src/backend/storage/buffer/bufmgr.c)

Em seg., 5 de jun. de 2023 às 08:06, Ranier Vilela escreveu: > Em dom., 4 de jun. de 2023 às 23:37, Richard Guo > escreveu: > >> >> On Sun, Jun 4, 2023 at 8:42 PM Ranier Vilela wrote: >> >>> Hi, >>> >>> Per Coverity. >>> >>> At function ExtendBufferedRelShared, has a always true test. >>> eb.re

Re: Adding SHOW CREATE TABLE

On Thu, 1 Jun 2023 at 18:57, Kirk Wolak wrote: > Can this get turned into a Patch? Were you offering this code up for others > (me?) to pull, and work into a patch? > [If I do the patch, I am not sure it gives you the value of reducing what > CITUS has to maintain. But it dawns on > me that yo

Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

Thanks to Imseih and Sami at AWS for reporting this. The original case comes from an upgrade I've been trying to complete for a couple of months now, since RDS started supporting 15 with a 15.2 release. The process has been slow and painful because, originally, there was a bug on the RDS side that

Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

Edit error above, I said that dependency tracking "does not seem to work." Not what I mean, it works great...It just does not seem to work for me with any of the upgrade options. >

Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

Morris de Oryx writes: > Can anyone suggest a path forward for me with the upgrade to PG 15? Apply this patch: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ca9e79274938d8ede07d9990c2f6f5107553b524 or more likely, pester RDS to do so sooner than the next quarterly releases.

Re: postgres_fdw: wrong results with self join + enable_nestloop off

Hi, On Fri, Jun 2, 2023 at 9:31 PM Nishant Sharma wrote: > I also agree that Richard's patch is better. As it fixes the issue at the > backend and does not treat pseudoconstant as local condition. > > I have tested Richard's patch and observe that it is resolving the problem. > Patch looks good

Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

Well *that *was quick. Thank you! Imseih, Sami what are the chances of getting RDS to apply this patch? Postgres 15 was released nearly 8 months ago, and it would be great to get onto it. Thanks On Mon, Jun 5, 2023 at 3:01 PM Tom Lane wrote: > Morris de Oryx writes: > > Can anyone suggest a p

[PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH

This makes "make check" work on Mac OS X. Without this patch, on Mac OS X a default "./configure; make; make check" fails with errors like: dyld[65265]: Library not loaded: /usr/local/pgsql/lib/libpq.5.dylib Referenced from: <59A2EAF9-6298-3112-BEDB-EA9A62A9DB53> /Users/evan.jones/postgresql-cle

QUAL Pushdown causes ERROR on syntactically and semantically correct SQL Query

I have reworked the case of BUG #17842 to include the data and the questions for further investigation. qualstest_data contais the data export with --insert (to test it on other DB systems) qualstest_query contains the failing query and a short introduction to the data. The problem is NOT to

Let's make PostgreSQL multi-threaded

I spoke with some folks at PGCon about making PostgreSQL multi-threaded, so that the whole server runs in a single process, with multiple threads. It has been discussed many times in the past, last thread on pgsql-hackers was back in 2017 when Konstantin made some experiments [0]. I feel that

Re: QUAL Pushdown causes ERROR on syntactically and semantically correct SQL Query

On Mon, Jun 5, 2023, 07:40 Hans Buschmann wrote: > I have reworked the case of BUG #17842 to include the data and the > questions for further investigation. > > > The problem is NOT to correct the query to a working case, but to show a > fundamental problem with qual pushdown. > The optimization

Re: QUAL Pushdown causes ERROR on syntactically and semantically correct SQL Query

Hans Buschmann writes: > I have reworked the case of BUG #17842 to include the data and the questions > for further investigation. This wasn't a bug before, and it still isn't. Postgres doesn't guarantee anything about the order of execution of a query's WHERE and JOIN clauses, and we do not in

Re: Let's make PostgreSQL multi-threaded

Heikki Linnakangas writes: > I spoke with some folks at PGCon about making PostgreSQL multi-threaded, > so that the whole server runs in a single process, with multiple > threads. It has been discussed many times in the past, last thread on > pgsql-hackers was back in 2017 when Konstantin made

Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

On Sun, Jun 4, 2023 at 1:41 PM Tom Lane wrote: > Kirk Wolak writes: > .. to strings of other lengths. So the new output (before 016107478 > fixed it) is > > pg_dump: warning: could not resolve dependency loop among these items: > pg_dump: detail: FUNCTION a_f (ID 216 OID 40532) > pg_dump: deta

Re: Docs: Encourage strong server verification with SCRAM

On Sat, Jun 3, 2023 at 2:50 PM Michael Paquier wrote: > Took me some time to get back to it, but applied this way. Thanks all! --Jacob

[PATCH] hstore: Fix parsing on Mac OS X: isspace() is locale specific

This patch fixes a rare parsing bug with unicode characters on Mac OS X. The problem is that isspace() on Mac OS X changes its behaviour with the locale. Use scanner_isspace instead, which only returns true for ASCII whitespace. It appears other places in the Postgres code have already run into thi

Re: Let's make PostgreSQL multi-threaded

On Mon Jun 5, 2023 at 9:51 AM CDT, Heikki Linnakangas wrote: > # Global variables > > We have a lot of global and static variables: > > $ objdump -t bin/postgres | grep -e "\.data" -e "\.bss" | grep -v > "data.rel.ro" | wc -l > 1666 > > Some of them are pointers to shared memory structures and can

Re: Let's make PostgreSQL multi-threaded

On 05/06/2023 11:18, Tom Lane wrote: Heikki Linnakangas writes: I spoke with some folks at PGCon about making PostgreSQL multi-threaded, so that the whole server runs in a single process, with multiple threads. It has been discussed many times in the past, last thread on pgsql-hackers was back

Re: PG 16 draft release notes ready

On Mon, Jun 5, 2023 at 05:33:51PM +0900, Yugo NAGATA wrote: > Hello, > > On Thu, 18 May 2023 16:49:47 -0400 > Bruce Momjian wrote: > > > I have completed the first draft of the PG 16 release notes. You can > > see the output here: > > Thanks for the release notes. > > > > > https://momj

Re: Let's make PostgreSQL multi-threaded

On 05/06/2023 11:28, Tristan Partin wrote: On Mon Jun 5, 2023 at 9:51 AM CDT, Heikki Linnakangas wrote: # Extensions A lot of extensions also contain global variables or other things that break in a multi-threaded environment. We need a way to label extensions that support multi-threading. And

RFC: Adding \history [options] [filename] to psql (Snippets and Shared Queries)

Everyone, After recently deep diving on some readline features and optimizing my bash environment to have a static set of "snippets" that I can always find... it takes just a couple of history API calls to add some interesting features for those that want them. The result of adding 3-4 such

Re: Implement generalized sub routine find_in_log for tap test

On Sun, 4 Jun 2023 at 03:51, Michael Paquier wrote: > > On Mon, May 29, 2023 at 07:49:52AM +0530, vignesh C wrote: > > Thanks for the comment, the attached v3 version patch has the changes > > for the same. > > -if (find_in_log( > - $node, $log_offset, > - qr/peer authe

Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

Reminds me to say a *big* *thank you* to everyone involved in and contributing to Postgres development for making error messages which are so good. For a programmer, error text is a primary UI. Most Postgres errors and log messages are clear and sufficient. Even when they're a bit obscure, they alw

Re: Partial aggregates pushdown

On Mon, Jun 5, 2023 at 12:00:27PM +0300, Alexander Pyhalov wrote: > Note that after these changes "select sum()" will fail for certain cases, > when remote server version is not the latest. In other cases we tried > to preserve compatibility. Should we have a switch for a foreign server to > turn

Re: Let's make PostgreSQL multi-threaded

On 05/06/2023 11:18, Tom Lane wrote: > Heikki Linnakangas writes: >> I spoke with some folks at PGCon about making PostgreSQL multi-threaded, >> so that the whole server runs in a single process, with multiple >> threads. It has been discussed many times in the past, last thread on >> pgsql-hacker

Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

Another suggestion for AWS/RDS: Expose *all of the logs in the upgrade tool chain*. If I'd had all of the logs at the start of this, I'd have been able to track down the issue myself quite quickly. Setting up that simple case database took me less than an hour today. Without the logs, it's been imp

Re: Add test module for Table Access Method

On Sat, Jun 3, 2023 at 7:42 PM Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > Hi all, > > During the PGCon Unconference session about Table Access Method one missing item pointed out is that currently we lack documentation and examples of TAM. > > So in order to improve things a bi

Re: pg_collation.collversion for C.UTF-8

On Fri, 2023-05-26 at 10:43 -0700, Jeff Davis wrote: > We still need to consider backwards compatibility. If someone has a > collation with locale name C.UTF-8 in an earlier version, any change > to > the interpretation of that locale name after an upgrade carries a > corruption risk. The risks are

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 5, 2023 at 01:26:00PM -0300, Ranier Vilela wrote: > On 05/06/2023 11:18, Tom Lane wrote: > > For the record, I think this will be a disaster. There is far too much > > code that will get broken, largely silently, and much of it is not > > under our control. > > I fully agreed with Tom

Simplify pg_collation.collversion for Windows libc

Hi, Currently the libc collation version for Windows has two components coming from the NLSVERSIONINFOEX structure [1] dwNLSVersion and dwDefinedVersion So we get version numbers looking like this (with 16 beta1): postgres=# select collversion,count(*) from pg_collation group by collversion; c

Re: Docs: Encourage strong server verification with SCRAM

On 6/5/23 11:22 AM, Jacob Champion wrote: On Sat, Jun 3, 2023 at 2:50 PM Michael Paquier wrote: Took me some time to get back to it, but applied this way. Thanks all! +1; thank you! Jonathan OpenPGP_signature Description: OpenPGP digital signature

Re: Let's make PostgreSQL multi-threaded

Em seg., 5 de jun. de 2023 às 13:42, Bruce Momjian escreveu: > On Mon, Jun 5, 2023 at 01:26:00PM -0300, Ranier Vilela wrote: > > On 05/06/2023 11:18, Tom Lane wrote: > > > For the record, I think this will be a disaster. There is far too much > > > code that will get broken, largely silently, an

Re: Let's make PostgreSQL multi-threaded

nOn Mon, Jun 5, 2023 at 05:51:57PM +0300, Heikki Linnakangas wrote: > # Restart on crash > > If a backend process crashes, postmaster terminates all other backends and > restarts the system. That's hard (impossible?) to do safely if everything > runs in one process. We can continue have a separat

Re: Let's make PostgreSQL multi-threaded

On 05/06/2023 12:26, Ranier Vilela wrote: First, it is not clear what are the benefits of architecture change? Performance? I doubt it makes much performance difference, at least not initially. It might help a little with backend startup time, and maybe some other things. And might reduce th

Re: Let's make PostgreSQL multi-threaded

On 05/06/2023 13:10, Bruce Momjian wrote: nOn Mon, Jun 5, 2023 at 05:51:57PM +0300, Heikki Linnakangas wrote: # Restart on crash If a backend process crashes, postmaster terminates all other backends and restarts the system. That's hard (impossible?) to do safely if everything runs in one proc

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 5, 2023 at 12:25 PM Heikki Linnakangas wrote: > We currently bend over backwards to make all allocations fixed-sized in > shared memory. You learn to live with that, but a lot of things would be > simpler if you could allocate and free in shared memory more freely. > It's no panacea,

Re: Let's make PostgreSQL multi-threaded

On 6/5/23 11:33 AM, Heikki Linnakangas wrote: On 05/06/2023 11:18, Tom Lane wrote: Heikki Linnakangas writes: I spoke with some folks at PGCon about making PostgreSQL multi-threaded, so that the whole server runs in a single process, with multiple threads. It has been discussed many times in t

Re: Let's make PostgreSQL multi-threaded

On 05/06/2023 13:32, Merlin Moncure wrote: Would this help with oom killer in linux? Hmm, I guess the OOM killer would better understand what Postgres is doing, it's not very smart about accounting shared memory. You still wouldn't want the OOM killer to kill Postgres, though, so I think you'

Re: pg_collation.collversion for C.UTF-8

Jeff Davis wrote: > > For libc: this change may affect any user who happened to have > > LANG=C.UTF-8 in their environment at initdb time, which is probably a > > lot of users, and some buildfarm members. However, the average risk > > seems to be much lower, because we've gone a long tim

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 5, 2023 at 08:29:16PM +0300, Heikki Linnakangas wrote: > On 05/06/2023 13:10, Bruce Momjian wrote: > > nOn Mon, Jun 5, 2023 at 05:51:57PM +0300, Heikki Linnakangas wrote: > > > # Restart on crash > > > > > > If a backend process crashes, postmaster terminates all other backends and >

Re: Partial aggregates pushdown

Bruce Momjian писал 2023-06-05 19:26: On Mon, Jun 5, 2023 at 12:00:27PM +0300, Alexander Pyhalov wrote: Note that after these changes "select sum()" will fail for certain cases, when remote server version is not the latest. In other cases we tried to preserve compatibility. Should we have a sw

Re: RFC: Logging plan of the running query

On Mon, Jun 5, 2023 at 4:30 AM torikoshia wrote: > > On 2023-06-03 02:51, James Coleman wrote: > > Hello, > > > > Thanks for working on this patch! Sure thing! I'm *very interested* in seeing this available, and I think it paves the way for some additional features later on... > > On Thu, Dec 8,

Re: Let's make PostgreSQL multi-threaded

On 05/06/2023 14:04, Bruce Momjian wrote: On Mon, Jun 5, 2023 at 08:29:16PM +0300, Heikki Linnakangas wrote: I don't think there would be any new class of errors that would cause server restarts. In theory, having a separate address space for each backend gives you some protection. In practice,

Re: Add the ability to limit the amount of memory that can be allocated to backends.

On Mon, 2023-05-22 at 08:42 -0400, reid.thomp...@crunchydata.com wrote: More followup to the above. > > I experimented on my system regarding > "The simple query select * from generate_series(0, 1000) shows roughly > 18.9 % degradation on my test server." > > My laptop: > 32GB ram > 11th G

Re: Let's make PostgreSQL multi-threaded

On 2023-06-05 Mo 11:18, Tom Lane wrote: Heikki Linnakangas writes: I spoke with some folks at PGCon about making PostgreSQL multi-threaded, so that the whole server runs in a single process, with multiple threads. It has been discussed many times in the past, last thread on pgsql-hackers was b

Re: Cleaning up nbtree after logical decoding on standby work

On Sun, May 28, 2023 at 7:49 PM Heikki Linnakangas wrote: > IMO this makes sense for v16. These new arguments were introduced in > v16, so if we have second thoughts, now is the right time to change > them, before v16 is released. It will reduce the backpatching effort in > the future; if we apply

Re: Let's make PostgreSQL multi-threaded

Hi In the long run, a single-process architecture makes it easier to have > shared catalog caches, plan cache, etc. which can improve performance. > And it can make it easier to launch helper threads for things where > worker processes would be too heavy-weight. But those benefits will > require m

Re: Do we want a hashset type?

On Mon, Jun 5, 2023, at 01:44, Tomas Vondra wrote: > Anyway, I hacked together a trivial set backed by an open addressing > hash table: > > https://github.com/tvondra/hashset > > It's super-basic, providing just some bare minimum of functions, but > hopefully good enough for experiments. > > - ha

Re: Let's make PostgreSQL multi-threaded

On 6/5/23 14:51, Andrew Dunstan wrote: On 2023-06-05 Mo 11:18, Tom Lane wrote: Heikki Linnakangas writes: I spoke with some folks at PGCon about making PostgreSQL multi-threaded, so that the whole server runs in a single process, with multiple threads. It has been discussed many times in the

Re: Mark a transaction uncommittable

On Mon, Jun 5, 2023 at 12:32 AM Laurenz Albe wrote: > > On Mon, 2023-06-05 at 00:22 -0700, Gurjeet Singh wrote: > > On Sat, Apr 22, 2023 at 8:01 AM Gurjeet Singh wrote: > > > > > > This is a proposal for a new transaction characteristic. I haven't > > > written any code, yet, and am interested in

Re: Mark a transaction uncommittable

On Sat, Apr 22, 2023 at 4:33 PM Julien Rouhaud wrote: > > Hi, > > On Sat, Apr 22, 2023 at 12:53:23PM -0400, Isaac Morland wrote: > > > > I have an application for this: creating various dev/test versions of data > > from production. > > > > Start by restoring a copy of production from backup. Then

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 5, 2023 at 8:18 AM Tom Lane wrote: > For the record, I think this will be a disaster. There is far too much > code that will get broken, largely silently, and much of it is not > under our control. > While I've long been in favor of a multi-threaded implementation, now in my old age

Inconsistent results with libc sorting on Windows

Hi, While trying pg16beta1 libc collations on Windows, I noticed that UTF-8 text sorts sometimes differently across invocations with the same locales, which is wrong since these collations are deterministic. The OS is Windows 10 Home, version 10.0.19045 Build 19045, self-built 16beta1 with VS Com

Tracking commit LSNs of tuple xmins for read txns

Hi everyone, When a transaction reads tuples from the heap, I would like to keep track of the maximum commit LSN of the xmin transactions of tuples as they are read. For e.g., consider a transaction T that reads tuples [t1, t2, t3] with respective xmins [700, 705, 702] and respective commit LSNs [

Re: Inconsistent results with libc sorting on Windows

On 6/5/23 18:07, Daniel Verite wrote: While trying pg16beta1 libc collations on Windows, I noticed that UTF-8 text sorts sometimes differently across invocations with the same locales, which is wrong since these collations are deterministic. Also, it does not occur at all if parallel scan is

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 5, 2023 at 09:30:28PM +0300, Heikki Linnakangas wrote: > If one process writes over shared memory that it shouldn't, it can cause a > crash in that process or some other process that reads it. Same with > multiple threads, no difference there. > > With a single process, one thread can

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 5, 2023 at 4:26 PM Bruce Momjian wrote: > I remember we used to have macros we called before we modified critical > parts of shared memory, and if a process exited while in those blocks, > the server would restart. Unfortunately, I can't find that in the code > now. Isn't that what w

Re: Partial aggregates pushdown

On Fri, Jun 2, 2023 at 03:54:06AM +, fujii.y...@df.mitsubishielectric.co.jp wrote: > Hi Mr.Bruce, hackers. > > I updated the patch. > The following is a list of comments received on the previous version of the > patch > and my update to them in this version of the patch. This thread starte

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 5, 2023 at 04:50:11PM -0700, Peter Geoghegan wrote: > On Mon, Jun 5, 2023 at 4:26 PM Bruce Momjian wrote: > > I remember we used to have macros we called before we modified critical > > parts of shared memory, and if a process exited while in those blocks, > > the server would restart

Re: Let's make PostgreSQL multi-threaded

On 6/5/23 2:07 PM, Jonah H. Harris wrote: > On Mon, Jun 5, 2023 at 8:18 AM Tom Lane > wrote: > > For the record, I think this will be a disaster.  There is far too much > code that will get broken, largely silently, and much of it is not > under our control.

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 5, 2023 at 5:15 PM Bruce Momjian wrote: > > Isn't that what we call a critical section? They effectively "promote" > > any ERROR (e.g., from an OOM) into a PANIC. > Yes, sorry, critical sections is what I was remembering. My question is > whether all unexpected backend exits should b

Re: Simplify pg_collation.collversion for Windows libc

On Mon, Jun 5, 2023 at 12:56 PM Daniel Verite wrote: > postgres=# select collversion,count(*) from pg_collation group by > collversion; > collversion | count > ---+--- >| 5 > 1539.5,1539.5 | 1457 > (2 rows) > > According to [1] the second number is obsolete

Re: Let's make PostgreSQL multi-threaded

>> For the record, I think this will be a disaster. There is far too >> much >> code that will get broken, largely silently, and much of it is not >> under our control. >> >> > > > If we were starting out today we would probably choose a threaded > implementation. But movin

Re: Inconsistent results with libc sorting on Windows

On Tue, Jun 6, 2023 at 10:08 AM Daniel Verite wrote: > Also, it does not occur at all if parallel scan is disabled. Could this be a clue that it is failing to be transitive?

Re: Inconsistent results with libc sorting on Windows

On Tue, Jun 6, 2023 at 1:30 PM Thomas Munro wrote: > On Tue, Jun 6, 2023 at 10:08 AM Daniel Verite wrote: > > Also, it does not occur at all if parallel scan is disabled. > > Could this be a clue that it is failing to be transitive? That vaguely rang a bell for me... and then I remembered this

Re: Improve join_search_one_level readibilty (one line change)

謝東霖 于2023年6月3日周六 23:21写道： > Hello hackers > > Attached is my first patch for PostgreSQL, which is a simple one-liner > that I believe can improve the code. > > In the "join_search_one_level" function, I noticed that the variable > "other_rels_list" always refers to "joinrels[1]" even when the (le

RE: Reload configuration more frequently in apply worker.

On Monday, June 5, 2023 8:03 AM Amit Kapila wrote: > > On Wed, May 17, 2023 at 8:34 AM Amit Kapila > wrote: > > > > On Wed, May 17, 2023 at 7:18 AM Zhijie Hou (Fujitsu) > > wrote: > > > > > > > > > The attached tap test shows how the failure happened. > > > > > > > I haven't yet tried to reprod

Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH

Hi, On Mon, Jun 05, 2023 at 09:47:30AM -0400, Evan Jones wrote: > This makes "make check" work on Mac OS X. Without this patch, on Mac OS X a > default "./configure; make; make check" fails with errors like: > > dyld[65265]: Library not loaded: /usr/local/pgsql/lib/libpq.5.dylib > Referenced fr

Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH

Julien Rouhaud writes: > On Mon, Jun 05, 2023 at 09:47:30AM -0400, Evan Jones wrote: >> This makes "make check" work on Mac OS X. Without this patch, on Mac OS X a >> default "./configure; make; make check" fails with errors like: >> ... >> The reason is that at some point, Mac OS X started removi

Re: Implement generalized sub routine find_in_log for tap test

On Sun, Jun 4, 2023 at 3:51 AM Michael Paquier wrote: > > On Mon, May 29, 2023 at 07:49:52AM +0530, vignesh C wrote: > > Thanks for the comment, the attached v3 version patch has the changes > > for the same. > > -if (find_in_log( > - $node, $log_offset, > - qr/peer aut

Add support for AT LOCAL

The Standard defines time zone conversion as follows: ::= [ ] ::= AT ::= LOCAL | TIME ZONE While looking at something else, I noticed we do not support AT LOCAL. The local time zone is defined as that of *the session*, not the server, which can make this quite interesting i

Re: postgres_fdw: wrong results with self join + enable_nestloop off

On Mon, Jun 5, 2023 at 9:19 PM Etsuro Fujita wrote: > If the patch is intended for HEAD only, I also think it goes in the > right direction. But if it is intended for back branches as well, I > do not think so, because it would cause ABI breakage due to changes > made to the ForeignPath struct a

Re: Implement generalized sub routine find_in_log for tap test

On Tue, Jun 06, 2023 at 08:05:49AM +0530, Amit Kapila wrote: > Personally, I don't see any problem to do this refactoring for v16. > However, sometimes, we do decide to backpatch refactoring in tests to > avoid backpatch effort. I am not completely sure if that is the case > here. 033_replay_tsp_d

Re: Partial aggregates pushdown

fujii.y...@df.mitsubishielectric.co.jp писал 2023-06-06 06:08: Hi Mr.Pyhalov. Thank you for your always thoughtful review. From: Alexander Pyhalov Sent: Monday, June 5, 2023 6:00 PM Have found one issue - src/backend/catalog/pg_aggregate.c 585 if(strcmp(strVal(linitial(aggpa

Re: Implement generalized sub routine find_in_log for tap test

On Mon, Jun 5, 2023 at 9:39 PM vignesh C wrote: > > On Sun, 4 Jun 2023 at 03:51, Michael Paquier wrote: > > > > This looks like a typo to me, the log offset is eaten. > > > > Except of that, I am on board with log_contains(). > > Thanks for fixing this. +1 for deduplicating find_in_log. How abou

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Mon, Jun 5, 2023 at 5:32 PM Masahiko Sawada wrote: > > > Sometime in the not-too-distant future, I will start a new thread focusing on bitmap heap scan, but for now, I just want to share some progress on making the radix tree usable not only for that, but hopefully a wider range of applications

RE: Support logical replication of DDLs

On Thur, June 1, 2023 at 23:42 vignesh C wrote: > On Wed, 31 May 2023 at 14:32, Wei Wang (Fujitsu) > wrote: > > ~~~ > > > > 2. Deparsed results of the partition table. > > When I run the following SQLs: > > ``` > > create table parent (a int primary key) partition by range (a); > > create table c

Re: 回复：Fix missing initialization of delayChkptEnd

Good catch! At Tue, 06 Jun 2023 00:39:47 +0800, "蔡梦娟(玊于)" wrote in > Hi, all. I updated the patch for this bugfix, the previous one > missed the modification of function InitAuxiliaryProcess, please > check the new patch. After a quick check through the 14 tree, then compaing with the correspo