Re: Optimize WindowAgg's use of tuplestores

On Wed, Sep 4, 2024 at 8:20 PM David Rowley wrote: > > On Mon, 19 Aug 2024 at 22:01, David Rowley wrote: > > To try and move this forward again, I adjusted the patch to use a > > static function with pg_noinline rather than unlikely. I don't think > > this will make much difference code generati

Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN

> Thanks for making the adjustments to this. > > I don't think there is any need to call tuplestore_updatemax() from > within writetup_heap(). That means having to update the maximum space > used every time a tuple is written to disk. That's a fairly massive > overhead. > > Instead, it should be

Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN

On Fri, 6 Sept 2024 at 16:21, Tatsuo Ishii wrote: > However, for 10, 2, 1 partitions. I see large performance > degradation with the patched version: patched is slower than stock > master in 1.5% (10 partitions), 41% (2 partitions) and 55.7% (1 > partition). See the attached graph. Thanks for mak

Re: Trying out read streams in pgvector (an extension)

On Fri, Sep 6, 2024 at 4:28 PM Thomas Munro wrote: > Without this > patch for PostgreSQL, it reads 1, 2, 4, 7 blocks (= 16 in total) > before it has to take a break to hop to a new page, and then it start > again at 1. Oops. Erm, correction: 1, 2, 4, 8, 1 (because it runs out due to m == 16 and

Re: pgsql: Add more SQL/JSON constructor functions

On Fri, Sep 6, 2024 at 12:07 PM Amit Langote wrote: > On Thu, Sep 5, 2024 at 9:58 PM Amit Langote wrote: > > On Tue, Sep 3, 2024 at 6:05 PM jian he wrote: > > > On Mon, Sep 2, 2024 at 4:18 PM Amit Langote > > > wrote: > > > v2-0001 looks good to me. > > > +-- Test JSON_TABLE() column deparsing

Re: Trying out read streams in pgvector (an extension)

On Wed, Jun 12, 2024 at 3:37 AM Jonathan S. Katz wrote: > If you're curious, I can fire up some of my more serious benchmarks on > this to do a before/after to see if there's anything interesting. I have > a few large datasets (10s of millions) of larger vectors (1536dim => 6KB > payloads) that co

Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN

Hi David, >> I pushed the changes to WindowAgg so as not to call tuplestore_end() >> on every partition. Can you rebase this patch over that change? >> >> It would be good to do this in a way that does not add any new state >> to WindowAggState, you can see that I had to shuffle fields around in

Re: pgsql: Add more SQL/JSON constructor functions

On Thu, Sep 5, 2024 at 9:58 PM Amit Langote wrote: > On Tue, Sep 3, 2024 at 6:05 PM jian he wrote: > > On Mon, Sep 2, 2024 at 4:18 PM Amit Langote wrote: > > v2-0001 looks good to me. > > +-- Test JSON_TABLE() column deparsing -- don't emit default ON ERROR / > > EMPTY > > +-- behavior > > +EXP

Re: First draft of PG 17 release notes

On Tue, Sep 3, 2024 at 10:44:01AM -0500, Nathan Bossart wrote: > While freely acknowledging that I am biased because I wrote it, I am a bit > surprised to see the DSM registry left out of the release notes (commit > 8b2bcf3, docs are here [0]). This feature is intended to allow modules to > alloc

Re: First draft of PG 17 release notes

On Wed, Sep 4, 2024 at 07:18:52PM +0800, jian he wrote: > hi. > > Allow partitions to be merged using ALTER TABLE ... MERGE PARTITIONS > (Dmitry Koval) > Allow partitions to be split using ALTER TABLE ... SPLIT PARTITION > (Dmitry Koval) > > also these two items got reverted? see > https://git.p

Re: AIO v2.0

On Sun, 1 Sept 2024 at 18:28, Andres Freund wrote: > 0 workers 1 worker2 workers > 4 workers > master: 65.753 33.246 21.095 > 12.918 > aio v2.0, worker: 21.519 12.636

Re: Support run-time partition pruning for hash join

On Tue, 22 Aug 2023 at 21:51, Richard Guo wrote: > Sometimes we may just not generate parameterized nestloop as final plan, > such as when there are no indexes and no lateral references in the > Append/MergeAppend node. In this case I think it would be great if we > can still do some partition ru

Re: Create syscaches for pg_extension

On Thu, Sep 05, 2024 at 10:56:34PM +0200, Jelte Fennema-Nio wrote: > LGTM now. Added it to the commitfest here: > https://commitfest.postgresql.org/50/5241/ Looks OK at quick glance. I'll take care of that as I've done the other one. -- Michael signature.asc Description: PGP signature

Re: Avoid overflowed array index (src/backend/utils/activity/pgstat.c)

On Thu, Sep 05, 2024 at 09:25:11AM -0300, Ranier Vilela wrote: > Please, disregard the first patch, it contains a bug. > New version attached, v1. These are wrong, because they are changing code paths where we know that stats kinds should be set. For custom stats, particularly, this would silentl

Re: race condition in pg_class

On Thu, Sep 05, 2024 at 07:10:04PM +0530, Nitin Motiani wrote: > On Thu, Sep 5, 2024 at 1:27 AM Noah Misch wrote: > > On Wed, Sep 04, 2024 at 09:00:32PM +0530, Nitin Motiani wrote: > > > Assert(rel->ri_needsLockTagTuple == > > > IsInplaceUpdateRelation(rel->relationDesc) > > > > > > This can sa

Re: Add trim_trailing_whitespace to editorconfig file

On Fri, 9 Aug 2024 at 16:09, Jelte Fennema-Nio wrote: > That's there so that the generated .editorconfig file the correct > indent_size. I guess another approach would be to change the > generate_editorconfig.py script to include hardcoded values for these > 4 filetypes. Okay, I've done this now.

Re: SPI_connect, SPI_connect_ext return type

Peter Eisentraut writes: > On 10.08.24 16:12, Tom Lane wrote: >> We go to a lot of effort to keep the SPI API as stable as we can >> across major versions, so I don't see why we'd just randomly make >> an API-breaking change like this. > Here is a previous discussion: > https://www.postgresql.or

Re: Adding NOTICE for differences between estimated and actual rows

On 05.09.2024 23:32, Euler Taveira wrote: On Thu, Sep 5, 2024, at 1:05 PM, Ilia Evdokimov wrote: It's quite common that poor query performance can be attributed to inaccurate row estimations by the planner. To make it easier to detect these discrepancies, rather than scrutinizing the estimat

Re: Adding NOTICE for differences between estimated and actual rows

On Thu, Sep 5, 2024, at 5:32 PM, Euler Taveira wrote: > $ cat /tmp/pcc.pl > #!/usr/bin/perl -n > print "\033[1m\033[35m$1\033[36m$2\033[32m$3\033[33m$4\033[m" while > /([|+-]+)|([0-9]+)|([a-zA-Z_]+)|([^\w])/g; > > and then you can start psql as: > > $ PAGER="/c/mypager.pl" psql I meant: $ PAGE

Re: Create syscaches for pg_extension

On Thu, 5 Sept 2024 at 22:03, Andrei Lepikhov wrote: > Thanks, see new patch in attachment. LGTM now. Added it to the commitfest here: https://commitfest.postgresql.org/50/5241/

Re: CREATE OR REPLACE MATERIALIZED VIEW

On 2024-07-27 02:45 +0200, Erik Wienhold wrote: > On 2024-07-12 16:49 +0200, Said Assemlal wrote: > > > My initial idea, while writing the patch, was that one could replace the > > > matview without populating it and then run the concurrent refresh, like > > > this: > > > > > > CREATE OR REPL

Re: Adding NOTICE for differences between estimated and actual rows

On Thu, Sep 5, 2024, at 1:05 PM, Ilia Evdokimov wrote: > It's quite common that poor query performance can be attributed to inaccurate > row estimations by the planner. To make it easier to detect these > discrepancies, rather than scrutinizing the estimates manually, it would be > helpful to ou

Re: Create syscaches for pg_extension

On 5/9/2024 18:50, Jelte Fennema-Nio wrote: On Thu, 5 Sept 2024 at 15:41, Andrei Lepikhov wrote: It seems that the get_extension_oid routine was not modified when the sys cache was introduced. What is the reason? It may be that this routine is redundant now, but if not, and we want to hold the

Re: Add GiST support for mixed-width integer operators

Paul Jungwirth writes: > On 7/6/24 05:04, Andrey M. Borodin wrote:>> On 5 Jul 2024, at 23:46, Paul > Jungwirth > wrote: >>> this commit adds support for all combinations of int2/int4/int8 for all >>> five btree operators (=/>). Perhaps I'm missing something, but how can this possibly work wit

Re: Invalid "trailing junk" error message when non-English letters are used

On Thu, 5 Sept 2024 at 20:49, Tom Lane wrote: > Karina Litskevich writes: > > On Thu, Sep 5, 2024 at 6:07 PM Karina Litskevich > > wrote: > >> In v3 of the patch I grouped all the *_junk rules together and included > >> the suggested comment with a little added something. > > > Oops, I forgot t

Re: change regexp_substr first argument make tests more easier to understand.

Ilia Evdokimov writes: > Current tests with regexp_instr() and regexp_substr()  with string > 'abcabcabc' are really unreadable and you would spend time to understand > that happens in these tests and if they are really correct. I'd better > change them into "abcdefghi" just like in query >  

Re: Statistics Import and Export

> > > git am shows some whitespace error. > Jeff indicated that this was more of a stylistic/clarity reworking. I'll be handling it again for now. > > > +extern Datum pg_set_relation_stats(PG_FUNCTION_ARGS); > +extern Datum pg_set_attribute_stats(PG_FUNCTION_ARGS); > is unnecessary? > They're

Re: scalability bottlenecks with (many) partitions (and more)

On 9/4/24 13:15, Tomas Vondra wrote: > On 9/4/24 11:29, Jakub Wartak wrote: >> Hi Tomas! >> >> ... >> >> My $0.02 cents: the originating case that triggered those patches, >> actually started with LWLock/lock_manager waits being the top#1. The >> operator can cross check (join) that with a group by

Re: Statistics Import and Export

> > I have attached version 28j as one giant patch covering what was > previously 0001-0003. It's a bit rough (tests in particular need some > work), but it implelements the logic to replace only those values > specified rather than the whole tuple. > I like what you did restoring the parameter en

Re: scalability bottlenecks with (many) partitions (and more)

Hi, Here's a bit more polished version of this patch series. I only propose 0001 and 0002 for eventual commit, the two other bits are just stuff to help with benchmarking etc. 0001 increases the size of the arrays, but uses hard-coded number of groups (64, so 1024 locks) and leaves everythin

Re: Make query cancellation keys longer

On Thu, Sep 5, 2024 at 9:36 AM Jelte Fennema-Nio wrote: > Totally agreed that it would be good to update psql to use the new > much more secure libpq function introduced in PG17[1]. This is not a > trivial change though because it requires refactoring the way we > handle signals (which is why I di

Re: Create syscaches for pg_extension

On Thu, 5 Sept 2024 at 15:41, Andrei Lepikhov wrote: > It seems that the get_extension_oid routine was not modified when the > sys cache was introduced. What is the reason? It may be that this > routine is redundant now, but if not, and we want to hold the API that > extensions use, maybe we shoul

Re: Invalid "trailing junk" error message when non-English letters are used

Karina Litskevich writes: > On Thu, Sep 5, 2024 at 6:07 PM Karina Litskevich > wrote: >> In v3 of the patch I grouped all the *_junk rules together and included >> the suggested comment with a little added something. > Oops, I forgot to attach the patch, here it is. Pushed with a bit of further

Re: json_query conditional wrapper bug

> On Sep 5, 2024, at 11:51 AM, Peter Eisentraut wrote: > > On 05.09.24 17:01, Andrew Dunstan wrote: >>> On 2024-09-04 We 4:10 PM, Andrew Dunstan wrote: >>> >>> On 2024-09-04 We 6:16 AM, Peter Eisentraut wrote: On 28.08.24 11:21, Peter Eisentraut wrote: > These are ok: > >

Re: Make query cancellation keys longer

On Thu, 5 Sept 2024 at 17:43, Jacob Champion wrote: > Has there been any work/discussion around not sending the cancel key > in plaintext from psql? It's not a prerequisite or anything (the > longer length is a clear improvement either way), but it seems odd > that this longer "secret" is still ju

Re: Make query cancellation keys longer

On Thu, Sep 5, 2024 at 9:21 AM Tom Lane wrote: > Wasn't this already addressed in v17, by > > Author: Alvaro Herrera > 2024-03-12 [61461a300] libpq: Add encrypted and non-blocking query > cancellation > > ? Perhaps we need to run around and make sure none of our standard > clients use the old A

Re: scalability bottlenecks with (many) partitions (and more)

On Tue, Sep 3, 2024 at 12:19 PM Tomas Vondra wrote: > > Doing some worst case math, suppose somebody has max_connections=1000 > > (which is near the upper limit of what I'd consider a sane setting) > > and max_locks_per_transaction=1 (ditto). The product is 10 > > million, so every 10 bytes of

Re: Make query cancellation keys longer

Jacob Champion writes: > Has there been any work/discussion around not sending the cancel key > in plaintext from psql? It's not a prerequisite or anything (the > longer length is a clear improvement either way), but it seems odd > that this longer "secret" is still just going to be exposed on the

Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points

On Thu, 5 Sept 2024 at 04:59, Michael Paquier wrote: > Even if the code is compiled with injection points enabled, it's still > going to be necessary to check if the module exists in the > installation or not. And it may or may not be around. > OK, thanks for an explanation, I get it. -- Best

Adding NOTICE for differences between estimated and actual rows

Hi hackers, It's quite common that poor query performance can be attributed to inaccurate row estimations by the planner. To make it easier to detect these discrepancies, rather than scrutinizing the estimates manually, it would be helpful to output a dedicated |NOTICE| message. In the curre

Re: Use read streams in pg_visibility

On Thu, Sep 05, 2024 at 03:59:53PM +0300, Nazir Bilal Yavuz wrote: > On Wed, 4 Sept 2024 at 21:43, Noah Misch wrote: > > https://postgr.es/m/caeudqaozv3wty5tv2t29jcwpydbmkbiwqkzd42s2ogzdixp...@mail.gmail.com > > then observed that collect_corrupt_items() was now guaranteed to never > > detect > >

Re: json_query conditional wrapper bug

On 05.09.24 17:01, Andrew Dunstan wrote: On 2024-09-04 We 4:10 PM, Andrew Dunstan wrote: On 2024-09-04 We 6:16 AM, Peter Eisentraut wrote: On 28.08.24 11:21, Peter Eisentraut wrote: These are ok: select json_query('{"a": 1, "b": 42}'::jsonb, 'lax $.b' without wrapper);   json_query --

Re: Make query cancellation keys longer

On Thu, Aug 15, 2024 at 10:14 AM Heikki Linnakangas wrote: > I'm back to working on the main patch here, to make cancellation keys > longer. New rebased version attached, with all the FIXMEs and TODOs from > the earlier version fixed. There was a lot of bitrot, too. I have a couple of questions/c

Re: Don't overwrite scan key in systable_beginscan()

On 12.08.24 09:44, Peter Eisentraut wrote: On 09.08.24 06:55, Tom Lane wrote: Noah Misch writes: On Thu, Aug 08, 2024 at 08:46:35AM +0200, Peter Eisentraut wrote: I propose to fix that by making a copy of the scan keys passed by the caller and make the modifications there. No objection, bu

Re: proposal: plpgsql, new check for extra_errors - strict_expr_check

ne 16. 6. 2024 v 16:11 odesílatel Pavel Stehule napsal: > Hi, > > assigned patch try to solve issue reported by Mor Lehr (Missing semicolon > in anonymous plpgsql block does not raise syntax error). > > > https://www.postgresql.org/message-id/CALyvM2bp_CXMH_Gyq87pmHJRuZDEhV40u9VP8rX=canet2w...@ma

Re: Invalid "trailing junk" error message when non-English letters are used

On Thu, Sep 5, 2024 at 6:07 PM Karina Litskevich wrote: > In v3 of the patch I grouped all the *_junk rules together and included > the suggested comment with a little added something. Oops, I forgot to attach the patch, here it is. Best regards, Karina Litskevich Postgres Professional: http://

Re: Invalid "trailing junk" error message when non-English letters are used

On Thu, Sep 5, 2024 at 1:52 AM Tom Lane wrote: > Karina Litskevich writes: > > I see the two solutions here: either move the rule for decinteger_junk > > below the rules for hexinteger_junk, octinteger_junk and bininteger_junk, > > or just use a single rule decinteger_junk for all these cases, si

Re: json_query conditional wrapper bug

On 2024-09-04 We 4:10 PM, Andrew Dunstan wrote: On 2024-09-04 We 6:16 AM, Peter Eisentraut wrote: On 28.08.24 11:21, Peter Eisentraut wrote: These are ok: select json_query('{"a": 1, "b": 42}'::jsonb, 'lax $.b' without wrapper);   json_query   42 select json_query('{"a": 1, "

Re: per backend I/O statistics

Hi, On Thu, Sep 05, 2024 at 03:03:32PM +0200, Alvaro Herrera wrote: > 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,

Re: updatable view set default interact with base rel generated stored columns

jian he writes: > --- > drop table if exists base_tbl cascade; > CREATE TABLE base_tbl (a int, b int GENERATED ALWAYS AS (22) stored, d > int default 22); > create view rw_view1 as select * from base_tbl; > insert into rw_view1(a) values (12) returning *; > alter view rw_view1

ATExecColumnDefault comments

hi. one minor issue for ATExecColumnDefault comments. /* * ALTER TABLE ALTER COLUMN SET/DROP DEFAULT * * Return the address of the affected column. */ static ObjectAddress ATExecColumnDefault(Relation rel, const char *colName, Node *newDefault, LOCKMODE lockmode) the comm

Re: SQL:2011 application time

On Thu, Sep 5, 2024 at 5:09 AM Peter Eisentraut wrote: > > On 07.08.24 22:54, Paul Jungwirth wrote: > > Here are some fixes based on outstanding feedback (some old some new). > > I have studied your patches v39-0001 through v39-0004, which correspond > to what had been reverted plus the new empty

Re: Create syscaches for pg_extension

čt 5. 9. 2024 v 15:41 odesílatel Andrei Lepikhov napsal: > On 22/8/2024 03:49, Michael Paquier wrote: > > On Mon, Aug 19, 2024 at 03:21:30PM +0900, Michael Paquier wrote: > >> I won't hide that I've wanted that in the past.. > > > > And I have bumped into a case where this has been helpful today,

Re: Avoid possible dereference null pointer (src/bin/pg_dump/pg_dump.c)

Em qui., 5 de set. de 2024 às 10:39, Daniel Gustafsson escreveu: > > On 4 Sep 2024, at 20:35, Daniel Gustafsson wrote: > >> On 4 Sep 2024, at 19:30, Nathan Bossart > wrote: > >> On Wed, Sep 04, 2024 at 02:10:28PM -0300, Ranier Vilela wrote: > > >>> patch attached. > >> > >> Yeah, that looks lik

Re: Create syscaches for pg_extension

On 22/8/2024 03:49, Michael Paquier wrote: On Mon, Aug 19, 2024 at 03:21:30PM +0900, Michael Paquier wrote: I won't hide that I've wanted that in the past.. And I have bumped into a case where this has been helpful today, so applied. Thanks! It had been my dream, too, for years. But the reaso

Re: race condition in pg_class

On Thu, Sep 5, 2024 at 1:27 AM Noah Misch wrote: > > On Wed, Sep 04, 2024 at 09:00:32PM +0530, Nitin Motiani wrote: > > How about this alternative then? The tuple length check > > and the elog(ERROR) gets its own function. Something like > > heap_inplace_update_validate or > > heap_inplace_update_

Re: Avoid possible dereference null pointer (src/bin/pg_dump/pg_dump.c)

> On 4 Sep 2024, at 20:35, Daniel Gustafsson wrote: >> On 4 Sep 2024, at 19:30, Nathan Bossart wrote: >> On Wed, Sep 04, 2024 at 02:10:28PM -0300, Ranier Vilela wrote: >>> patch attached. >> >> Yeah, that looks like a problem to me. I've cc'd Daniel here. > > Thanks for the report, it does se

Re: strange context message in spi.c?

On 03.08.24 07:43, Umar Hayat wrote: The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed As tree is branched ou

Re: [PATCH] Add roman support for to_number function

On Thu, Sep 5, 2024 at 2:41 PM Aleksander Alekseev wrote: > > While playing with the patch I noticed that to_char(..., 'RN') doesn't > seem to be test-covered. I suggest adding the following test: > > ``` > WITH rows AS ( > SELECT i, to_char(i, 'FMRN') AS roman > FROM generate_series(1, 3

Re: per backend I/O statistics

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

Re: Use read streams in pg_visibility

Hi, On Wed, 4 Sept 2024 at 21:43, Noah Misch wrote: > > https://postgr.es/m/caeudqaozv3wty5tv2t29jcwpydbmkbiwqkzd42s2ogzdixp...@mail.gmail.com > then observed that collect_corrupt_items() was now guaranteed to never detect > corruption. I have pushed revert ddfc556 of the pg_visibility.c changes

Re: pgsql: Add more SQL/JSON constructor functions

Hi, On Tue, Sep 3, 2024 at 6:05 PM jian he wrote: > On Mon, Sep 2, 2024 at 4:18 PM Amit Langote wrote: > v2-0001 looks good to me. > +-- Test JSON_TABLE() column deparsing -- don't emit default ON ERROR / EMPTY > +-- behavior > +EXPLAIN VERBOSE SELECT * from JSON_TABLE('"a"', '$' COLUMNS (a text

Re: Thread-safe nl_langinfo() and localeconv()

On 19.08.24 08:29, Thomas Munro wrote: Here is a slightly better version of patch 0003. I removed some unnecessary refactoring, making the patch smaller. FTR I wrote a small program[1] for CI to test the assumptions about Windows in 0001. I printed out the addresses of the objects, to confirm

Re: Vacuum statistics

On Thu, Sep 5, 2024 at 1:23 AM Alena Rybakina wrote: > > Hi, all! > > I have attached the new version of the code and the diff files > (minor-vacuum.no-cbot). > hi. still have white space issue when using "git apply", you may need to use "git diff --check" to find out where. /* -- dif

Re: Avoid overflowed array index (src/backend/utils/activity/pgstat.c)

Em qui., 5 de set. de 2024 às 09:18, Ranier Vilela escreveu: > m qua., 4 de set. de 2024 às 20:58, Michael Paquier > escreveu: > >> On Wed, Sep 04, 2024 at 03:14:34PM -0300, Ranier Vilela wrote: >> > The commit 7949d95 , >> left >> > out an oversi

Re: Avoid overflowed array index (src/backend/utils/activity/pgstat.c)

m qua., 4 de set. de 2024 às 20:58, Michael Paquier escreveu: > On Wed, Sep 04, 2024 at 03:14:34PM -0300, Ranier Vilela wrote: > > The commit 7949d95 , > left > > out an oversight. > > > > The report is: > > CID 1559468: (#1 of 1): Overflowed array

Re: Jargon and acronyms on this mailing list

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

Re: SQL:2011 application time

On 07.08.24 22:54, Paul Jungwirth wrote: Here are some fixes based on outstanding feedback (some old some new). I have studied your patches v39-0001 through v39-0004, which correspond to what had been reverted plus the new empty range check plus various minor fixes. This looks good to me now

Re: optimizing pg_upgrade's once-in-each-database steps

I've read and tested through the latest version of this patchset and I think it's ready to go in. The one concern I have is that tasks can exit(1) on libpq errors tearing down perfectly functional connections without graceful shutdown. Longer term I think it would make sense to add similar exit ha

Re: long-standing data loss bug in initial sync of logical replication

On Mon, Sep 2, 2024 at 9:19 PM Nitin Motiani wrote: > > I think that the partial data replication for one table is a bigger > issue than the case of data being sent for a subset of the tables in > the transaction. This can lead to inconsistent data if the same row is > updated multiple times or de

Re: [PATCH] Add roman support for to_number function

Hi, > I have attached a new patch v2 with following changes: > > - Handled invalid cases like 'viv', 'lxl', and 'dcd'. > - Changed errcode to 22P07 because 22P06 was already taken. > - Removed TODO. > - Added a few positive & negative tests. > - Updated documentation. > > Looking forward to your f

Re: meson vs. llvm bitcode files

Hi, On Thu, 5 Sept 2024 at 11:56, Peter Eisentraut wrote: > > The meson build currently does not produce llvm bitcode (.bc) files. > AFAIK, this is the last major regression for using meson for production > builds. > > Is anyone working on that? I vaguely recall that some in-progress code > was

Re: Use streaming read API in ANALYZE

On Thu, Sep 5, 2024 at 6:45 PM Mats Kindahl wrote: > Forgive me for asking, but I am not entirely sure why the ReadStream struct > is opaque. The usual reasons are: > > You want to provide an ABI to allow extensions to work with new major > versions without re-compiling. Right now it is necessar

meson vs. llvm bitcode files

The meson build currently does not produce llvm bitcode (.bc) files. AFAIK, this is the last major regression for using meson for production builds. Is anyone working on that? I vaguely recall that some in-progress code was shared a couple of years ago, but I haven't seen anything since. It

Re: Virtual generated columns

On Wed, Sep 4, 2024 at 4:40 PM Peter Eisentraut wrote: > > > Here is an implementation of this. It's much nicer! It also appears to > fix all the additional test cases that have been presented. (I haven't > integrated them into the patch set yet.) > > I left the 0001 patch alone for now and put

updatable view set default interact with base rel generated stored columns

hi. While reviewing virtual generated columns, I find some issues with the updatable view interacting with stored generated columns. --- drop table if exists base_tbl cascade; CREATE TABLE base_tbl (a int, b int GENERATED ALWAYS AS (22) stored, d int default 22); create view rw

Re: [PATCH] Add roman support for to_number function

Hi, I have attached a new patch v2 with following changes: - Handled invalid cases like 'viv', 'lxl', and 'dcd'. - Changed errcode to 22P07 because 22P06 was already taken. - Removed TODO. - Added a few positive & negative tests. - Updated documentation. Looking forward to your feedback. Regard

Re: Support run-time partition pruning for hash join

On 19/3/2024 07:12, Richard Guo wrote: On Tue, Jan 30, 2024 at 10:33 AM Richard Guo > wrote: Attached is an updated patch.  Nothing else has changed. Here is another rebase over master so it applies again.  Nothing else has changed. The patch doesn't apply

Re: Add callback in pgstats for backend initialization

On Thu, Sep 05, 2024 at 12:41:09PM +0900, Michael Paquier wrote: > Not sure which one is better than the other, TBH. Either way, we > still have a full release cycle to finalize that, and I am OK to > switch the name to something else if there are more folks in favor of > one, the other or even so