Re: Yet another fast GiST build

On 21/09/2020 02:06, Tom Lane wrote: Justin Pryzby writes: This also appears to break checksums. Thanks, I'll go fix it. I was wondering about that, because the typical pattern for use of smgrextend for indexes seems to be RelationOpenSmgr(rel);

Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)

On 17/09/2020 13:31, Thomas Munro wrote: On Thu, Sep 17, 2020 at 10:19 PM Heikki Linnakangas wrote: If you put the counter in HandleStartupProcInterrupts(), it could be a long wait if the startup process is e.g. waiting for WAL to arrive in the loop in WaitForWALToBecomeAvailable

Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)

On 17/09/2020 12:48, Thomas Munro wrote: Hello, In commits 9f095299 and f98b8476 we improved recovery performance on Linux and FreeBSD but we didn't help other operating systems. David just confirmed for me that commenting out the PostmasterIsAlive() call in the main recovery loop speeds up

Re: Yet another fast GiST build

On 15/09/2020 14:36, Heikki Linnakangas wrote: Another patch version, fixed a few small bugs pointed out by assertion failures in the regression tests. Pushed. Thanks everyone! - Heikki

Re: Yet another fast GiST build

On 16/09/2020 10:27, Andrey M. Borodin wrote: Actually, I just want to understand what changes between v18 and v19 changed on-page order of items. I look into patch diff and cannot figure it out. There are only logging changes. How this affects scan? The test was failing with v18 too. -

Re: Yet another fast GiST build

On 15/09/2020 19:46, Andrey M. Borodin wrote: 15 сент. 2020 г., в 16:36, Heikki Linnakangas написал(а): Another patch version, fixed a few small bugs pointed out by assertion failures in the regression tests. - Heikki These changes in create_index.out do not seem correct to me

Re: Yet another fast GiST build

On 11/09/2020 09:02, Andrey M. Borodin wrote: 10 сент. 2020 г., в 17:43, Heikki Linnakangas написал(а): One more patch version attached. I fixed some memory leaks, and fixed the abbreviation on 32-bit systems, and a bunch of small comment changes and such. The patch looks fine to me. On my

Re: Yet another fast GiST build

On 09/09/2020 19:50, Andrey M. Borodin wrote: 9 сент. 2020 г., в 20:39, Heikki Linnakangas написал(а): On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote: On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote: Come to think of it, the point z-order comparator could ben

Re: Yet another fast GiST build

On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote: On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote: Come to think of it, the point z-order comparator could benefit a lot from key abbreviation, too. You could do the point -> zorder conversion in the abbrevi

Re: Yet another fast GiST build

On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote: On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote: Come to think of it, the point z-order comparator could benefit a lot from key abbreviation, too. You could do the point -> zorder conversion in the abbrevi

Re: Yet another fast GiST build

On 09/09/2020 13:28, Andrey M. Borodin wrote: Thanks Darafei! 9 сент. 2020 г., в 12:05, Darafei Komяpa Praliaskouski написал(а): How does the 'sortsupport' routine interact with 'compress'/'decompress'? Which representation is passed to the comparator routine: the original value from the

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On 08/09/2020 22:25, James Coleman wrote: On Wed, Aug 19, 2020 at 3:16 AM Heikki Linnakangas wrote: You could also apply the optimization for non-Const expressions, as long as they're stable (i.e. !contain_volatile_functions(expr)). Is that true? Don't we also have to worry about whether

Re: Yet another fast GiST build

presentation, or the decompressed representation? Do the comparetup_index_btree() and readtup_index() routines agree with that? - Heikki >From 7a9331bbd43799150d6a0b9dad2e98604c6b7dfc Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Tue, 8 Sep 2020 21:56:41 +0300 Subject: [PATCH v16 1/1] A

Re: Yet another fast GiST build

rom c7cadbb017aa3ec446136c36bb58b10d35ed095a Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Mon, 7 Sep 2020 12:23:20 +0300 Subject: [PATCH v15 3/4] Expose point_zorder() to SQL. --- src/backend/access/gist/gistproc.c | 19 +++ src/include/catalog/pg_proc.dat| 4 2 fi

Re: Dubious code in pg_rewind's process_target_file()

On 06/09/2020 18:06, Tom Lane wrote: Heikki Linnakangas writes: On 05/09/2020 21:18, Tom Lane wrote: Or actually, maybe we should just drop the lstat call altogether? Agreed, the lstat() doesn't do anything interesting. This is refactored away by the patches discussed at https

Re: Dubious code in pg_rewind's process_target_file()

On 05/09/2020 21:18, Tom Lane wrote: I wrote: It looks to me like we could replace "exists = false" with "return", rather than uselessly constructing a FILE_ACTION_REMOVE entry for a file we've already proven is not there. Or actually, maybe we should just drop the lstat call altogether?

Re: Yet another fast GiST build (typo)

On 05/09/2020 14:53, Andrey M. Borodin wrote: Thanks for ideas, Heikki. Please see v13 with proposed changes. Thanks, that was quick! But I've found out that logging page-by-page slows down GiST build by approximately 15% (when CPU constrained). Though In think that this is IO-wise. Hmm, any

Re: POC: rational number type (fractions)

The discussion diverged somewhat to PGXN and extensions in general, but the consensus seems to be that this should (continue to) be an extension rather than a core feature. I agree that as an extension this is pretty cool. I'll mark this as rejected in the commitfest app. Looking at the

Re: Yet another fast GiST build (typo)

On 30/08/2020 15:04, Andrey M. Borodin wrote: 23 авг. 2020 г., в 14:39, Andrey M. Borodin написал(а): Thanks for reviewing and benchmarking, Pavel! Pavel sent me few typos offlist. PFA v12 fixing these typos. In gist_indexsortbuild(), you first build all the leaf pages. Then, you read

Re: Refactor pg_rewind code and make it work against a standby

meaningful change is in the 2nd patch, which I modified per your suggestion. Also, I moved the logic to decide each file's fate into a new subroutine called decide_file_action(). - Heikki >From 1effdaeabb843b40575ae898ec9de57ffc37f301 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Da

Refactor pg_rewind code and make it work against a standby

%40sss.pgh.pa.us - Heikki >From f2057f662e9c52c7392491831338a720a21a8ca3 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Wed, 19 Aug 2020 15:34:35 +0300 Subject: [PATCH 1/5] pg_rewind: Move syncTargetDirectory() to file_ops.c For consistency. All the other low-level functions that oper

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On 01/05/2020 05:20, James Coleman wrote: On Tue, Apr 28, 2020 at 8:25 AM Tomas Vondra wrote: ... Any particular reasons to pick dynahash over simplehash? ISTM we're using simplehash elsewhere in the executor (grouping, tidbitmap, ...), while there are not many places using dynahash for simple

Re: Newline after --progress report

On 17/08/2020 16:59, Tom Lane wrote: Heikki Linnakangas writes: Good point. Pushed a patch along those lines. Uh ... you patched v12 but not v13? Darn, I forgot it exists. Also, I'd recommend that you NOT do this: + fprintf(stderr, (!finished && isatty(fileno(stderr))) ? &q

Re: Corruption during WAL replay

On 14/04/2020 22:04, Teja Mupparti wrote: Thanks Kyotaro and Masahiko for the feedback. I think there is a consensus on the critical-section around truncate, +1 but I just want to emphasize the need for reversing the order of the dropping the buffers and the truncation.  Repro details

Re: Commit/abort WAL records with dropped rels missing XLR_SPECIAL_REL_UPDATE

On 17/08/2020 10:00, Michael Paquier wrote: On Sat, Aug 15, 2020 at 11:05:43AM +0530, Amit Kapila wrote: On Fri, Aug 14, 2020 at 2:17 PM Heikki Linnakangas wrote: It's always been like that, but I am not going backport, for fear of breaking existing applications. If a program reads the WAL

Re: Newline after --progress report

On 14/08/2020 16:51, Tom Lane wrote: Heikki Linnakangas writes: Attached is a patch to fix this, as well as a similar issue in pg_checksums. pg_basebackup and pgbench also print progres reports like this, but they seem correct to me. I wonder whether it'd be better to push the responsibility

Commit/abort WAL records with dropped rels missing XLR_SPECIAL_REL_UPDATE

ikki >From cafc42a1dfe6afc9d36c0440dd45a5b12d9a6063 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Wed, 12 Aug 2020 23:07:50 +0300 Subject: [PATCH 1/2] Make xact.h usable in frontend. xact.h included utils/datetime.h, which cannot be used in the frontend (it includes fmgr.h, which needs Datum). But xact.h only needs t

Newline after --progress report

similar issue in pg_checksums. pg_basebackup and pgbench also print progres reports like this, but they seem correct to me. - Heikki >From b4a64c3aca7257336c3ca1bf4bee8675e148de10 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Wed, 12 Aug 2020 23:27:01 +0300 Subject: [PATCH 1/1]

Re: pendingOps table is not cleared with fsync=off

On 06/08/2020 18:42, Tom Lane wrote: Heikki Linnakangas writes: On 09/05/2020 02:53, Thomas Munro wrote: On Sat, May 9, 2020 at 9:21 AM Heikki Linnakangas wrote: I noticed that commit 3eb77eba5a changed the logic in ProcessSyncRequests() (formerly mdsync()) so that if you have fsync=off

pg_rewind is not crash safe

A colleague of mine brought to my attention that pg_rewind is not crash safe. If it is interrupted for any reason, it leaves behind a data directory with a mix of data from the source and target images. If you're "lucky", the server will start up, but it can be in an inconsistent state. That's

Re: Incorrect OpenSSL type reference in code comment

On 14/05/2020 11:07, Daniel Gustafsson wrote: The comment which refers to the OpenSSL PEM password callback type has a small typo, the type is called pem_password_cb and not pem_passwd_cb (which is an easy typo to make to make since confusingly enough the functions in OpenSSL are called

Re: pendingOps table is not cleared with fsync=off

On 09/05/2020 02:53, Thomas Munro wrote: On Sat, May 9, 2020 at 9:21 AM Heikki Linnakangas wrote: I noticed that commit 3eb77eba5a changed the logic in ProcessSyncRequests() (formerly mdsync()) so that if you have fsync=off, the entries are not removed from the pendingOps hash table. I don't

pendingOps table is not cleared with fsync=off

Hi! I noticed that commit 3eb77eba5a changed the logic in ProcessSyncRequests() (formerly mdsync()) so that if you have fsync=off, the entries are not removed from the pendingOps hash table. I don't think that was intended. I propose the attached patch to move the test for enableFsync so

Re: Memory-Bounded Hash Aggregation

On 05/02/2020 21:56, Jeff Davis wrote: On Tue, 2020-02-04 at 18:10 +0200, Heikki Linnakangas wrote: I'd love to change the LogicalTape API so that you could allocate and free tapes more freely. I wrote a patch to do that, as part of replacing tuplesort.c's polyphase algorithm with a simpler one

Re: Memory-Bounded Hash Aggregation

On 03/02/2020 20:29, Jeff Davis wrote: 1. Use a minheap for the freelist. The original design used an array that had to be sorted between a read (which frees a block) and a write (which needs to sort the array to consume the lowest block number). The comments said: * sorted. This is an

Re: ReadRecord wrongly assumes randAccess after 38a957316d.

On 28/01/2020 12:44, Kyotaro Horiguchi wrote: While rebasing a patch, I found that after the commit 38a957316d (Sorry for overlooking that.), ReadRecord sets randAccess reverse way. That is, it sets randAccess to false just after a XLogBeginRead() call. The attached fixes that. Thanks,

Re: Remove page-read callback from XLogReaderState.

On 21/01/2020 13:33, Craig Ringer wrote: On Tue, 21 Jan 2020 at 18:46, Kyotaro Horiguchi wrote: It seems to me that it works perfectly, and everything looks good I seem to remember some considerable pain in this area when it came to timeline switches. Especially with logical decoding and

Re: Remove page-read callback from XLogReaderState.

On 21/01/2020 12:45, Kyotaro Horiguchi wrote: At Mon, 20 Jan 2020 17:24:07 +0900 (JST), Kyotaro Horiguchi wrote in Separating XLogBeginRead seems reasonable. The annoying recptr trick is no longer needed. In particular some logical-decoding stuff become far cleaner by the patch.

Re: [PoC] Non-volatile WAL buffer

On 24/01/2020 10:06, Takashi Menjo wrote: I propose "non-volatile WAL buffer," a proof-of-concept new feature. It enables WAL records to be durable without output to WAL segment files by residing on persistent memory (PMEM) instead of DRAM. It improves database performance by reducing copies

Re: Crash in BRIN summarization

On 17/01/2020 23:35, Alvaro Herrera wrote: On 2019-Aug-28, Heikki Linnakangas wrote: I bumped into a little bug in BRIN, while hacking on something unrelated. This causes a segfault, or an assertion failure if assertions are enabled: Heikki, I just noticed that you haven't pushed this bugfix

Re: remove separate postgres.(sh)description files

On 16/01/2020 23:39, Tomas Vondra wrote: On Wed, Jan 08, 2020 at 02:33:23PM +0200, Heikki Linnakangas wrote: On 31/12/2019 02:08, John Naylor wrote: I'm guessing the initial data for pg_(sh)description is output into separate files because it was too difficult for the traditional shell script

Re: Remove page-read callback from XLogReaderState.

On 29/11/2019 10:14, Kyotaro Horiguchi wrote: At Thu, 28 Nov 2019 21:37:03 +0900 (JST), Kyotaro Horiguchi wrote in 0dc8ead463 hit this. Rebased. Please review the pg_waldump.c hunks in 0001; they revert recent changes. Ughhh! I'l check it. Thank you for noticing!! Fixed that, re-rebased

Re: Modernizing SQL functions' result type coercions

On 28/11/2019 00:57, Tom Lane wrote: Hence, the attached patch rearranges things so that we'll allow any case where the parser's standard coercion logic can find an assignment-level coercion, including typmod coercion if needed. In a green field I might've argued for restricting this to implicit

Re: remove separate postgres.(sh)description files

On 31/12/2019 02:08, John Naylor wrote: I'm guessing the initial data for pg_(sh)description is output into separate files because it was too difficult for the traditional shell script to maintain enough state to do otherwise. Yeah, I guess so. The roots of postgres.description goes all the

Re: Fastpath while arranging the changes in LSN order in logical decoding

On 25/11/2019 05:52, Dilip Kumar wrote: In logical decoding, while sending the changes to the output plugin we need to arrange them in the LSN order. But, if there is only one transaction which is a very common case then we can avoid building the binary heap. A small patch is attached for the

Re: Memory-Bounded Hash Aggregation

On 28/12/2019 01:35, Jeff Davis wrote: I've attached a new patch that adds some basic costing for disk during hashagg. This patch (hashagg-20191227.patch) doesn't compile: nodeAgg.c:3379:7: error: ‘hashagg_mem_overflow’ undeclared (first use in this function) if (hashagg_mem_overflow)

Re: Improve checking for pg_index.xmin

On 01/11/2019 01:50, Alexander Korotkov wrote: Hi! Our customer faced with issue, when index is invisible after creation. The reproducible case is following. $ psql db2 # begin; # select txid_current(); $ psql db1 # select i as id, 0 as v into t from generate_series(1, 10)

Re: reduce size of fmgr_builtins array

On 02/01/2020 01:15, John Naylor wrote: I wrote: Currently, we include the function name string in each FmgrBuiltin struct, whose size is 24 bytes on 64 bit platforms. As far as I can tell, the name is usually unused, so the attached (WIP, untested) patch stores it separately, reducing this

Re: Read Uncommitted

On 18/12/2019 20:46, Mark Dilger wrote: On 12/18/19 10:06 AM, Simon Riggs wrote: Just consider this part of the recovery toolkit. In that case, don't call it "read uncommitted". Call it some other thing entirely. Users coming from other databases may request "read uncommitted" isolation

Re: Restore backup file "with oids"

On 18 December 2019 19:28:07 EET, "gmail Vladimir Koković" wrote: >Is there somewhere a script that can do a restore backup file "with >oids" in some newer DB where there is no term "with oids"? There is nothing automatic, some manual work is needed. A couple of ideas: 1. Install an older

Re: automating pg_config.h.win32 maintenance

On 13/12/2019 14:51, Peter Eisentraut wrote: Keeping pg_config.h.win32 up to date with pg_config.h.in is a gratuitous annoyance. Hear hear! My proposal is that we essentially emulate what config.status does in Perl code. config.status gets a list of defines discovered by configure and

Re: Questions about PostgreSQL implementation details

Hi Julien! On 09/12/2019 17:35, Julien Delplanque wrote: Q1. Are PostgreSQL's meta-description tables (such as pg_class) the "reality" concerning the state of the DB or are they just a virtual representation ? Yes, the catalog tables are the authoritative source. The system uses those

Re: Application name for pg_basebackup and friends

On 31/10/2019 14:52, Jesper Pedersen wrote: Hi, The attached patch adds an -a / --appname command line switch to pg_basebackup, pg_receivewal and pg_recvlogical. This is useful when f.ex. pg_receivewal needs to connect as a synchronous client (synchronous_standby_names), pg_receivewal -h

Re: strpos behavior change around empty substring in PG12

). It looks to me like this got broken here: commit 9556aa01c69a26ca726d8dda8e395acc7c1e30fc Author: Heikki Linnakangas Date: Fri Jan 25 16:25:05 2019 +0200 Use single-byte Boyer-Moore-Horspool search even with multibyte encodings. Not sure what happened exactly. I think the problem

Re: Fix of fake unlogged LSN initialization

On 24/10/2019 15:08, Michael Paquier wrote: On Thu, Oct 24, 2019 at 11:57:33AM +0100, Simon Riggs wrote: I wonder why is that value 1000, rather than an aligned value or a whole WAL page? Good question. Heikki, why this choice? No particular reason, it's just a nice round value in decimal.

Re: Zedstore - compressed in-core columnar storage

On 15/10/2019 13:49, Ashutosh Sharma wrote: Hi, I got chance to spend some time looking into the recent changes done in the zedstore code, basically the functions for packing datums into the attribute streams and handling attribute leaf pages. I didn't find any issues but there are some minor

Re: Questions/Observations related to Gist vacuum

On 17/10/2019 05:31, Amit Kapila wrote: On Wed, Oct 16, 2019 at 11:20 AM Dilip Kumar wrote: On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas wrote: On 15/10/2019 09:37, Amit Kapila wrote: While reviewing a parallel vacuum patch [1], we noticed a few things about $SUBJECT implemented

Re: Questions/Observations related to Gist vacuum

On 16 October 2019 12:57:03 CEST, Amit Kapila wrote: >On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas >wrote: >> All things >> considered, I'm not sure which is better. > >Yeah, this is a tough call to make, but if we can allow it to delete >the pages in bulkdelete

Re: Questions/Observations related to Gist vacuum

On 15/10/2019 09:37, Amit Kapila wrote: While reviewing a parallel vacuum patch [1], we noticed a few things about $SUBJECT implemented in commit - 7df159a620b760e289f1795b13542ed1b3e13b87. 1. A new memory context GistBulkDeleteResult->page_set_context has been introduced, but it doesn't seem

Re: Locking a row with KEY SHARE NOWAIT blocks

On 03/09/2019 16:31, Tom Lane wrote: Heikki Linnakangas writes: When you lock a row with FOR KEY SHARE, and the row's non-key columns have been updated, heap_lock_tuple() walks the update chain to mark all the in-progress tuple versions also as locked. But it doesn't pay attention

Locking a row with KEY SHARE NOWAIT blocks

When you lock a row with FOR KEY SHARE, and the row's non-key columns have been updated, heap_lock_tuple() walks the update chain to mark all the in-progress tuple versions also as locked. But it doesn't pay attention to the NOWAIT or SKIP LOCKED flags when doing so. The

Re: Bug in GiST paring heap comparator

On 02/09/2019 07:54, Alexander Korotkov wrote: Andrey Borodin noticed me that results of some KNN-GIST tests are obviously wrong and don't match results of sort node. SELECT * FROM point_tbl ORDER BY f1 <-> '0,1'; f1 --- (10,10) (NaN,NaN) (0,0) (1e-300,-1e-300)

Re: Zedstore - compressed in-core columnar storage

On 29/08/2019 14:30, Ashutosh Sharma wrote: On Wed, Aug 28, 2019 at 5:30 AM Alexandra Wang > wrote: You are correct that we currently go through each item in the leaf page that contains the given tid, specifically, the logic to retrieve all the

Re: Comment in ginpostinglist.c doesn't match code

On 23/08/2019 11:44, Masahiko Sawada wrote: On Fri, Aug 23, 2019 at 7:05 AM Ashwin Agrawal wrote: On Thu, Aug 22, 2019 at 1:14 AM Heikki Linnakangas wrote: The patch also includes a little unit test module to test this without creating a 16 TB table. A whole new test module seems a bit like

Crash in BRIN summarization

I bumped into a little bug in BRIN, while hacking on something unrelated. This causes a segfault, or an assertion failure if assertions are enabled: CREATE TABLE brintest (n numrange); CREATE INDEX brinidx ON brintest USING brin (n); INSERT INTO brintest VALUES ('empty'); INSERT INTO brintest

Re: Yet another fast GiST build

On 26/08/2019 10:59, Andrey Borodin wrote: Hi! In many cases GiST index can be build fast using z-order sorting. I've looked into proof of concept by Nikita Glukhov [0] and it looks very interesting. So, I've implemented yet another version of B-tree-like GiST build. Cool! My biggest

Re: Remove page-read callback from XLogReaderState.

On 22/08/2019 04:43, Kyotaro Horiguchi wrote: At Mon, 29 Jul 2019 22:39:57 +0300, Heikki Linnakangas wrote in On 12/07/2019 10:10, Kyotaro Horiguchi wrote: * XLogReaderState->readBuf is now allocated and controlled by the * caller, not by xlogreader.c itself. When XLogReadRecord() needs d

Re: Take skip header out of a loop in COPY FROM

On 22/08/2019 12:54, Adam Lee wrote: My next thought is to call unlikely() here, but we don't have it... https://www.postgresql.org/message-id/CABRT9RC-AUuQL6txxsoOkLxjK1iTpyexpbizRF4Zxny1GXASGg%40mail.gmail.com We do, actually, since commit aa3ca5e3dd in v10. Not sure it's worth the trouble

Re: Take skip header out of a loop in COPY FROM

On 22/08/2019 11:31, Surafel Temesgen wrote: Hello, Even if skipping header is done only once its checked and skipped in a loop. If I don’t miss something it can be done out side a loop like attached patch You may be on to something, but if we move it to CopyFrom(), as in your patch, then

Comment in ginpostinglist.c doesn't match code

or not? - Heikki >From 3178fe98ca93c52bc8678953b328f70d7ed16b5c Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Thu, 22 Aug 2019 11:06:13 +0300 Subject: [PATCH 1/1] Fix overflow check and comment in GIN posting list encoding. The comment did not match what the code actually did for integ

Re: Zedstore - compressed in-core columnar storage

On 20/08/2019 05:04, Justin Pryzby wrote: it looks like zedstore with lz4 gets ~4.6x for our largest customer's largest table. zfs using compress=gzip-1 gives 6x compression across all their partitioned tables, and I'm surprised it beats zedstore . I did a quick test, with 10

Re: understand the pg locks in in an simple case

On 20/08/2019 10:23, Alex wrote: I have troubles to understand the pg lock in the following simple situation. Session 1: begin; update tset a= 1 where a= 10; Session 2: begin; update tset a= 2 where a= 10; They update the same row and session 2 is blocked by session 1

Re: Zedstore - compressed in-core columnar storage

On 14/08/2019 20:32, Ashwin Agrawal wrote: On Wed, Aug 14, 2019 at 2:51 AM Ashutosh Sharma wrote: 2) Is there a chance that IndexOnlyScan would ever be required for zedstore tables considering the design approach taken for it? We have not given much thought to IndexOnlyScans so far. But I

Re: use of the term "verifier" with SCRAM

On 14/08/2019 08:59, Peter Eisentraut wrote: I'm confused by how the code uses the term "verifier" in relation to SCRAM. ISTM that the code uses the term as meaning whatever is or would be stored in pg_auth.rolpassword. I don't see this usage supported in the RFCs. In RFC 5802, verifier

Re: Shrinking tuplesort.c's SortTuple struct (Was: More ideas for speeding up sorting)

On 10/08/2019 02:14, Peter Geoghegan wrote: The easy part was removing SortTuple.tupindex itself -- it was fairly natural to stash that in the slab allocation for each tape. I used the aset.c trick of having a metadata "chunk" immediately prior to address that represents the allocation proper --

Re: Add "password_protocol" connection parameter to libpq

On 09/08/2019 23:27, Jonathan S. Katz wrote: On 8/9/19 11:51 AM, Jeff Davis wrote: On Fri, 2019-08-09 at 09:28 -0400, Stephen Frost wrote: Having an 'any' option, as mentioned before, could be an alternative though. ... I agree with the point that there isn't any guarantee that it'll

default_table_access_method is not in sample config file

On 11/04/2019 19:49, Andres Freund wrote: On 2019-04-11 14:52:40 +0300, Heikki Linnakangas wrote: diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c index f7f726b5aec..bbcab9ce31a 100644 --- a/src/backend/utils/misc/guc.c +++ b/src/backend/utils/misc/guc.c @@ -3638,7

Re: Grouping isolationtester tests in the schedule

On 07/08/2019 18:52, Alvaro Herrera wrote: On 2019-Aug-07, Tom Lane wrote: Something related I've been wondering about is whether we could parallelize the isolation tests. A difficulty here is that the slowest ones tend to also be timing-sensitive, such that running them in parallel would

Re: stress test for parallel workers

On 07/08/2019 17:45, Tom Lane wrote: Heikki Linnakangas writes: On 07/08/2019 16:57, Tom Lane wrote: Also, if you're using systemd or something else that thinks it ought to interfere with where cores get dropped, that could be a problem. I think they should just go to a file called "

Re: stress test for parallel workers

On 07/08/2019 16:57, Tom Lane wrote: Heikki Linnakangas writes: On 07/08/2019 02:57, Thomas Munro wrote: On Wed, Jul 24, 2019 at 5:15 PM Tom Lane wrote: So I think I've got to take back the assertion that we've got some lurking generic problem. This pattern looks way more like a platform

Re: Unix-domain socket support on Windows

On 07/08/2019 16:56, Peter Eisentraut wrote: It works! Cool! Am I reading the patches correctly, that getpeereid() still doesn't work on Windows? That means that peer authentication doesn't work, right? That's a bit sad. One of the big advantages of unix domain sockets over TCP is peer

Re: stress test for parallel workers

On 07/08/2019 02:57, Thomas Munro wrote: On Wed, Jul 24, 2019 at 5:15 PM Tom Lane wrote: So I think I've got to take back the assertion that we've got some lurking generic problem. This pattern looks way more like a platform-specific issue. Overaggressive OOM killer would fit the facts on

Re: Grouping isolationtester tests in the schedule

On 07/08/2019 14:42, Thomas Munro wrote: On Wed, Aug 7, 2019 at 11:28 PM Heikki Linnakangas wrote: The list of tests in src/test/isolation/isolation_schedule has grown over the years. Originally, they were all related to Serializable Snapshot Isolation, but there are different kinds

Re: POC: Cleaning up orphaned files using undo logs

On 07/08/2019 13:52, Dilip Kumar wrote: I have one more problem related to compression of the command id field. Basically, the problem is that we don't set the command id in the WAL and we will always store FirstCommandId in the undo[1]. So suppose there were 2 operations under a different

Grouping isolationtester tests in the schedule

The list of tests in src/test/isolation/isolation_schedule has grown over the years. Originally, they were all related to Serializable Snapshot Isolation, but there are different kinds of concurrency tests there now. More tests is good, but the schedule file has grown into a big inscrutable

Re: POC: Cleaning up orphaned files using undo logs

On 05/08/2019 16:24, Robert Haas wrote: On Sun, Aug 4, 2019 at 5:16 AM Heikki Linnakangas wrote: I feel that the level of abstraction is not quite right. There are a bunch of fields, like uur_block, uur_offset, uur_tuple, that are probably useful for some UNDO resource managers (zheap I

Re: Remove HeapTuple and Buffer dependency for predicate locking functions

On 06/08/2019 13:35, Thomas Munro wrote: On Tue, Aug 6, 2019 at 9:26 PM Heikki Linnakangas wrote: Attached is a patch that contains your fix.txt with the changes for clarity mentioned above, and an isolationtester test case. LGTM. Pushed, thanks! - Heikki

Re: Remove HeapTuple and Buffer dependency for predicate locking functions

eapam_index_fetch_tuple() wouldn't need to do "bslot->base.tupdata.t_self = *tid". - Heikki >From 23d07e6d5b259e1fd2fe7694cde51212920fbb3a Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Tue, 6 Aug 2019 12:14:14 +0300 Subject: [PATCH 1/1] Fix predicate-locking of HOT upda

Re: POC: Cleaning up orphaned files using undo logs

On 05/08/2019 07:23, Thomas Munro wrote: On Mon, Aug 5, 2019 at 3:54 PM Amit Kapila wrote: On Sun, Aug 4, 2019 at 2:46 PM Heikki Linnakangas wrote: Could we leave out the UNDO and discard worker processes for now? Execute all UNDO actions immediately at rollback, and after crash recovery

Re: POC: Cleaning up orphaned files using undo logs

I had a look at the UNDO patches at https://www.postgresql.org/message-id/CAA4eK1KKAFBCJuPnFtgdc89djv4xO%3DZkAdXvKQinqN4hWiRbvA%40mail.gmail.com, and at the patch to use the UNDO logs to clean up orphaned files, from undo-2019-05-10.tgz earlier in this thread. Are these the latest ones to

Re: Batch insert in CTAS/MatView code

On 17/06/2019 15:53, Paul Guo wrote: I noticed that to do batch insert, we might need additional memory copy sometimes comparing with "single insert" (that should be the reason that we previously saw a bit regressions) so a good solution seems to fall back to "single insert" if the tuple length

Re: Assertion for logically decoding multi inserts into the catalog

On 08/07/2019 22:42, Daniel Gustafsson wrote: My patch for using heap_multi_insert in the catalog [1] failed the logical decoding part of test/recovery [2]. The assertion it failed on seems to not take multi inserts into the catalog into consideration, while the main logic does. This assertion

Re: [HACKERS] Cached plans and statement generalization

On 09/07/2019 23:59, Konstantin Knizhnik wrote: Fixed patch version of the path is attached. Much of the patch and the discussion has been around the raw parsing, and guessing which literals are actually parameters that have been inlined into the SQL text. Do we really need to do that,

Re: Allow table AM's to cache stuff in relcache

On 12/07/2019 16:07, Julien Rouhaud wrote: On Fri, Jun 14, 2019 at 5:40 PM Tom Lane wrote: Heikki Linnakangas writes: In the patch, I documented that rd_amcache must be allocated in CacheMemoryContext, or in rd_indexcxt if it's an index. It works, but it's a bit weird. Given the way

Re: Remove page-read callback from XLogReaderState.

On 12/07/2019 10:10, Kyotaro Horiguchi wrote: At Tue, 28 May 2019 04:45:24 -0700, Andres Freund wrote in <20190528114524.dvj6ymap2virl...@alap3.anarazel.de> Hi, On 2019-04-18 21:02:57 +0900, Kyotaro HORIGUCHI wrote: Hello. As mentioned before [1], read_page callback in XLogReaderState is a

Re: Hypothetical indexes using BRIN broken since pg10

On 27/06/2019 23:09, Alvaro Herrera wrote: On 2019-Jun-27, Tom Lane wrote: Dunno, I just can't get excited about exposing REVMAP_PAGE_MAXITEMS. Especially not since we seem to agree on the long-term solution here, and what you're suggesting to Julien doesn't particularly fit into that

Re: GiST VACUUM

On 24/07/2019 21:02, Peter Geoghegan wrote: On Wed, Jul 24, 2019 at 10:30 AM Heikki Linnakangas wrote: Pushed this now, to master and REL_12_STABLE. Now, B-tree indexes still have the same problem, in all versions. Any volunteers to write a similar fix for B-trees? I was hoping that you'd

Re: GiST VACUUM

On 22/07/2019 16:09, Heikki Linnakangas wrote: Unless something comes up, I'll commit this tomorrow. Pushed this now, to master and REL_12_STABLE. Now, B-tree indexes still have the same problem, in all versions. Any volunteers to write a similar fix for B-trees? - Heikki

Re: GiST VACUUM

On 28/06/2019 01:02, Thomas Munro wrote: On Thu, Jun 27, 2019 at 11:38 PM Heikki Linnakangas wrote: * I moved the logic to extend a 32-bit XID to 64-bits to a new helper function in varsup.c. I'm a bit uneasy about making this into a generally available function for reuse. I think we should

Re: Memory Accounting

On 18/07/2019 21:24, Jeff Davis wrote: Previous discussion: https://postgr.es/m/1407012053.15301.53.camel%40jeff-desktop This patch introduces a way to ask a memory context how much memory it currently has allocated. Each time a new block (not an individual chunk, but a new malloc'd block) is

<    3   4   5   6   7   8   9   10   11   >