Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Hi, On 2019-04-30 00:50:20 -0400, Tom Lane wrote: > Andres Freund writes: > > On April 29, 2019 9:37:33 PM PDT, Tom Lane wrote: > >> Seems like putting reindexes of pg_class into a test script that runs > >> in parallel with other DDL wasn't a hot idea. > > > Saw that. Will try to reproduce (an

Re: performance regression when filling in a table

Hi, On 2019-04-30 07:12:03 +0200, Fabien COELHO wrote: > On my SSD Ubuntu laptop, with postgres-distributed binaries and unmodified > default settings using local connections: > ## pg 11.2 > > time pgbench -i -s 100 > ... > done in 31.51 s > # (drop tables 0.00 s, create tables 0.01 s,

ERROR: failed to add item to the index page

With master (3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6) I'm getting this: visena=# CREATE INDEX origo_email_part_hdrvl_value_idx ON public.origo_email_part_headervalue USING btree (lower(substr((header_value)::text, 0, 1000)) varchar_pattern_ops); psql: ERROR: failed to add item to the index pag

ERROR: tuple concurrently updated when modifying privileges

Hello, hackers we witnessed this slightly misleading error in production and it took us a while to figure out what was taking place. Below are reproduction steps: -- setup create table trun(cate int4); -- session 1 begin; truncate table trun; -- session 2 grant insert on table trun to postgre

Re: CHAR vs NVARCHAR vs TEXT performance

I agree in principle, however in this particular scenario it's not our schema so we're a little reluctant to migrate the types etc. We're in a bit of a bad place because the combination of NHibernate + npgsql3/4 + this table = seqScans everywhere. Basically when npgsql changed their default type

Re: performance regression when filling in a table

Hello Andres, ## pg 11.2 done in 31.51 s ## pg 12devel (cd3e2746) real0m38.695s What change could explain such a significant performance regression? I think the pre-release packages have had assertions enabled at some point. I suggest checking that. If it's not that, profiles would

Re: [Patch] Base backups and random or zero pageheaders

Hi, Am Mittwoch, den 27.03.2019, 11:37 +0100 schrieb Michael Banck: > Am Dienstag, den 26.03.2019, 19:23 +0100 schrieb Michael Banck: > > Am Dienstag, den 26.03.2019, 10:30 -0700 schrieb Andres Freund: > > > On 2019-03-26 18:22:55 +0100, Michael Banck wrote: > > > >

Re: ERROR: failed to add item to the index page

Andreas Joseph Krogh writes: > With master (3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6) I'm getting this: > visena=# CREATE INDEX origo_email_part_hdrvl_value_idx ON > public.origo_email_part_headervalue USING btree > (lower(substr((header_value)::text, 0, 1000)) varchar_pattern_ops); > psql: ER

Re: [PATCH v4] Add \warn to psql

About v5: applies, compiles, global & local make check ok, doc gen ok. Very minor comment: \qecho is just before \o in the embedded help, where it should be just after. Sorry I did not see it on the preceding submission. Unfortunately new TAP test doesn't pass on my machine. I'm not good a

Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 15:43:16, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > With master (3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6) I'm getting this: > visena=# CREATE INDEX origo_email_part_hdrvl_value_idx ON > public.origo_email_part_headervalue USING btr

Re: Sv: Re: ERROR: failed to add item to the index page

Andreas Joseph Krogh writes: > I built with this: make distclean && ./configure > --prefix=$HOME/programs/postgresql-master --with-openssl --with-llvm && make > -j > 8 install-world-contrib-recurse install-world-doc-recurse --with-llvm, eh? Does it reproduce without that? What platform is th

Sv: Re: Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 15:53:50, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > I built with this: make distclean && ./configure > --prefix=$HOME/programs/postgresql-master --with-openssl --with-llvm && make -j > 8 install-world-contrib-recurse install-world-

Re: Unhappy about API changes in the no-fsm-for-small-rels patch

On 2019-Apr-30, John Naylor wrote: > On Fri, Apr 26, 2019 at 11:52 AM Amit Kapila wrote: > > As discussed above, we need to issue an > > invalidation for following points: (a) when vacuum finds there is no > > FSM and page has more space now, I think you can detect this in > > RecordPageWithFree

Sv: Sv: Re: Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 16:03:04, skrev Andreas Joseph Krogh < andr...@visena.com >: På tirsdag 30. april 2019 kl. 15:53:50, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > I built with this: make distclean && ./configure > --prefix=$

Re: "long" type is not appropriate for counting tuples

On 2019-Apr-30, David Rowley wrote: > On Tue, 30 Apr 2019 at 06:28, Peter Geoghegan wrote: > > > > On Mon, Apr 29, 2019 at 11:20 AM Alvaro Herrera > > wrote: > > > Agreed. Here's a patch. I see downthread that you also discovered the > > > same mistake in _h_indexbuild by grepping for "long";

Re: "long" type is not appropriate for counting tuples

Alvaro Herrera writes: > I don't know if anybody plans to do progress report for COPY, but I hope > we don't find ourselves in a problem when some user claims that they are > inserting more than 2^63 but less than 2^64 tuples. At one tuple per nanosecond, it'd take a shade under 300 years to reac

message style

I have this two message patches that I've been debating with myself about: --- a/src/backend/access/heap/heapam.c +++ b/src/backend/access/heap/heapam.c @@ -1282,7 +1282,7 @@ heap_getnext(TableScanDesc sscan, ScanDirection direction) if (unlikely(sscan->rs_rd->rd_tableam != GetHeapamTableA

Re: message style

Hi, On 2019-04-30 10:58:13 -0400, Alvaro Herrera wrote: > I have this two message patches that I've been debating with myself > about: > > --- a/src/backend/access/heap/heapam.c > +++ b/src/backend/access/heap/heapam.c > @@ -1282,7 +1282,7 @@ heap_getnext(TableScanDesc sscan, ScanDirection > dir

Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?

Hi, While looking at https://www.postgresql.org/message-id/20190430070552.jzqgcy4ihalx7nur%40alap3.anarazel.de I noticed that /* * ReindexIndex * Recreate a specific index. */ void ReindexIndex(RangeVar *indexRelation, int options, bool concurrent) { Oid

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Andres Freund writes: > On 2019-04-30 00:50:20 -0400, Tom Lane wrote: >> Hm? REINDEX INDEX is deadlock-prone by definition, because it starts >> by opening/locking the index and then it has to open/lock the index's >> table. Every other operation locks tables before their indexes. > We claim to

Re: Failure in contrib test _int on loach

Hi! So, if other hackers are agreed with my reasoning, the suggested fix is sufficient and can be committed. Patch looks right, but I think that comment should be improved in follow piece: if (stack->blkno != GIST_ROOT_BLKNO && - stack->parent->lsn < GistPageGetNSN(stack->

Re: Sv: Sv: Re: Sv: Re: ERROR: failed to add item to the index page

Please fix or abstain from using the MUA that produces this monstrosity of a Subject: "Sv: Sv: Re: Sv: Re: ERROR: failed to add item to the index page" cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Se

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

I wrote: > I haven't been able to reproduce this locally yet, but my guess is that > the REINDEX wants to update some row that was already updated by the > concurrent transaction, so it has to wait to see if the latter commits > or not. And, of course, waiting while holding AccessExclusiveLock on

Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 16:27:05, skrev Andreas Joseph Krogh < andr...@visena.com >: [snip] Yep, happens without --with-llvm also. I'll try to load only the necessary table(s) to reproduce. I have a 1.4GB dump (only one table) which reliably reproduces this error.

Re: ERROR: failed to add item to the index page

On Tue, Apr 30, 2019 at 9:44 AM Andreas Joseph Krogh wrote: > I have a 1.4GB dump (only one table) which reliably reproduces this error. > Shall I share it off-list? I would be quite interested in this, too, since there is a chance that it's my bug. -- Peter Geoghegan

Re: ERROR: failed to add item to the index page

Andreas Joseph Krogh writes: > I have a 1.4GB dump (only one table) which reliably reproduces this error. > Shall I share it off-list? -- That's awfully large :-(. How do you have in mind to transmit it? Maybe you could write a short script that generates dummy data to reproduce the problem?

Re: ERROR: failed to add item to the index page

On Tue, Apr 30, 2019 at 9:47 AM Tom Lane wrote: > Andreas Joseph Krogh writes: > > I have a 1.4GB dump (only one table) which reliably reproduces this error. > > Shall I share it off-list? -- > > That's awfully large :-(. How do you have in mind to transmit it? I've send dumps that were larger

Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 18:48:45, skrev Peter Geoghegan mailto:p...@bowt.ie>>: On Tue, Apr 30, 2019 at 9:47 AM Tom Lane wrote: > Andreas Joseph Krogh writes: > > I have a 1.4GB dump (only one table) which reliably reproduces this error. > > Shall I share it off-list? -- > > That's awf

Re: ERROR: failed to add item to the index page

On Tue, Apr 30, 2019 at 9:56 AM Andreas Joseph Krogh wrote: > I've sent you guys a link (Google Drive) off-list. I'll start investigating the problem right away. Thanks -- Peter Geoghegan

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

On 2019-04-30 11:51:10 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2019-04-30 00:50:20 -0400, Tom Lane wrote: > > I suspect the problem isn't REINDEX INDEX in general, it's REINDEX INDEX > > over catalog tables modified during reindex. > > So far, every one of the failures in the buildfa

Re: performance regression when filling in a table

Hi, On 2019-04-30 12:32:13 +0200, Fabien COELHO wrote: > The effect is that the first generation seems to take more time, but > dropping the table and regenerating again much less, with a typical 40% > performance improvement between first and second run, independently of the > version. The report

Re: ERROR: failed to add item to the index page

On Tue, Apr 30, 2019 at 9:59 AM Peter Geoghegan wrote: > I'll start investigating the problem right away. I have found what the problem is. I simply neglected to make a conservative assumption about suffix truncation needing to add a heap TID to a leaf page's new high key in nbtsort.c (following

Re: CHAR vs NVARCHAR vs TEXT performance

> > > > On Tue, Apr 30, 2019 at 5:44 AM Tom Lane wrote: > >> FWIW, my recommendation for this sort of thing is almost always > >> to not use CHAR(n). The use-case for that datatype pretty much > >> disappeared with the last IBM Model 029 card punch. > ... > > > Perhaps the "tip" on the character

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Andres Freund writes: > It's the lock-upgrade problem I theorized about > upthread. ReindexIndex(), via RangeVarCallbackForReindexIndex(), takes a > ShareLock on pg_class, and then goes on to upgrade to RowExclusiveLock > in RelationSetNewRelfilenode(). But at that time another session > obviously

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Hi, On 2019-04-30 14:05:50 -0400, Tom Lane wrote: > Andres Freund writes: > > It's the lock-upgrade problem I theorized about > > upthread. ReindexIndex(), via RangeVarCallbackForReindexIndex(), takes a > > ShareLock on pg_class, and then goes on to upgrade to RowExclusiveLock > > in RelationSetN

Turning off enable_partition_pruning doesn't

I'd have thought that disabling enable_partition_pruning would, um, disable partition pruning. It does not: regression=# create table p (a int) partition by list (a); CREATE TABLE regression=# create table p1 partition of p for values in (1); CREATE TABLE regression=# create table p2 partition of

Re: doc: improve PG 12 to_timestamp()/to_date() wording

Hi Bruce I saw this commit; commit ad23adc5a169b114f9ff325932cbf2ce1c5e69c1 |Author: Bruce Momjian |Date: Tue Apr 30 14:06:57 2019 -0400 | |doc: improve PG 12 to_timestamp()/to_date() wording which cleans up language added at cf984672. Can I suggest this additional change, which is updat

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Andres Freund writes: > On 2019-04-30 14:05:50 -0400, Tom Lane wrote: >> Possibly we could run them in a TAP test that configures a cluster >> with autovac disabled? > Hm. Would it be sufficient to instead move them to a non-concurrent > test group, and stick a BEGIN; LOCK pg_class, ; COMMIT;

Re: Turning off enable_partition_pruning doesn't

On 2019-Apr-30, Tom Lane wrote: > regression=# explain select * from p1 where a = 3; But you're reading from the partition, not from the partitioned table ... -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: doc: improve PG 12 to_timestamp()/to_date() wording

Hi! I'd like to add couple of comments from my side. On Tue, Apr 30, 2019 at 9:36 PM Justin Pryzby wrote: > I saw this commit; > commit ad23adc5a169b114f9ff325932cbf2ce1c5e69c1 > |Author: Bruce Momjian > |Date: Tue Apr 30 14:06:57 2019 -0400 > | > |doc: improve PG 12 to_timestamp()/to_da

Match table_complete_speculative() code to comment

Comment for table_complete_speculative() says /* * Complete "speculative insertion" started in the same transaction. If * succeeded is true, the tuple is fully inserted, if false, it's removed. */ static inline void table_complete_speculative(Relation rel, TupleTableSlot *slot,

Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 19:58:31, skrev Peter Geoghegan mailto:p...@bowt.ie>>: On Tue, Apr 30, 2019 at 9:59 AM Peter Geoghegan wrote: > I'll start investigating the problem right away. I have found what the problem is. I simply neglected to make a conservative assumption about suffix tr

Re: Re: ERROR: failed to add item to the index page

On Tue, Apr 30, 2019 at 11:54 AM Andreas Joseph Krogh wrote: > Nice, thanks! Thanks for the report! -- Peter Geoghegan

Re: ERROR: failed to add item to the index page

Hi, On 2019-04-30 20:54:45 +0200, Andreas Joseph Krogh wrote: > På tirsdag 30. april 2019 kl. 19:58:31, skrev Peter Geoghegan >: On Tue, Apr 30, 2019 at 9:59 AM Peter Geoghegan > wrote: > > I'll start investigating the problem right away. > > I have found what the proble

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Hi, On 2019-04-30 14:41:00 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2019-04-30 14:05:50 -0400, Tom Lane wrote: > >> Possibly we could run them in a TAP test that configures a cluster > >> with autovac disabled? > > > Hm. Would it be sufficient to instead move them to a non-concurren

Re: speeding up planning with partitions

Amit Langote writes: > On Tue, Apr 30, 2019 at 1:26 PM Amit Langote wrote: >> It would be nice if at least we fix the bug that directly accessed >> partitions are not excluded with constraint_exclusion = on, without >> removing PG 11's contortions in relation_excluded_by_constraints to >> work ar

Re: Turning off enable_partition_pruning doesn't

Alvaro Herrera writes: > On 2019-Apr-30, Tom Lane wrote: >> regression=# explain select * from p1 where a = 3; > But you're reading from the partition, not from the partitioned table ... Argh! Where's my brown paper bag? regards, tom lane

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Andres Freund writes: > On 2019-04-30 14:41:00 -0400, Tom Lane wrote: >> I think trying to get this "working" is a v13 task now. We've obviously >> never tried to stress the case before, so you're neither fixing a >> regression nor fixing a new-in-v12 issue. > Well, the test *do* test that a pre

Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 20:59:43, skrev Andres Freund mailto:and...@anarazel.de>>: [...] Andreas, unfortunately your emails are pretty unreadable. Check the quoted email, and the web archive: https://www.postgresql.org/message-id/VisenaEmail.41.51d7719d814a1f54.16a6f98a5e9%40tc7-visena

Re: ERROR: failed to add item to the index page

Hi, On 2019-04-30 21:23:21 +0200, Andreas Joseph Krogh wrote: > På tirsdag 30. april 2019 kl. 20:59:43, skrev Andres Freund > >: [...] > Andreas, unfortunately your emails are pretty unreadable. Check the > quoted email, and the web archive: > > > https://www.post

Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 21:26:52, skrev Andres Freund mailto:and...@anarazel.de>>: > [...] > The standard on pg lists is to write in a manner that's usable for both > text mail readers and the archive. Doesn't terribly matter to the > occasional one-off poster on -general, but you're not th

Re: Calling PrepareTempTablespaces in BufFileCreateTemp

On Fri, Apr 26, 2019 at 8:05 AM Tom Lane wrote: > The version that I posted left it to GetNextTempTableSpace to assert > that. That seemed cleaner to me than an Assert that has to depend > on interXact. > > Running `make check` with [1] applied and one of the calls to PrepareTempTablespaces comm

Re: Calling PrepareTempTablespaces in BufFileCreateTemp

Melanie Plageman writes: > I also think that if there is a step that a caller should always take before > calling a function, then there needs to be a very compelling reason not to > move that step into the function itself. Fair complaint. > PrepareTempTablespaces should not be called in BufFile

Re: Initializing LWLock Array from Server Code

Hi Robert, Thank you for your reply and sorry that I couldn't reply earlier. Since I didn't get any response within a couple of days, I took the longer route -- changed the lwlock.h and lwlock.c for accommodating the lw locks for the shared hash table. I'll describe what I modified in the lwlock.

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Hi, On 2019-04-30 15:11:43 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2019-04-30 14:41:00 -0400, Tom Lane wrote: > > > On 2019-04-30 12:03:08 -0700, Andres Freund wrote: > > > > This is a pretty finnicky area of the code, with obviously not enough > > > > test coverage. I'm inclined t

Re: Calling PrepareTempTablespaces in BufFileCreateTemp

I wrote: > So maybe a reasonable compromise is to add the Assert(s) in fd.c as > per previous patch, but *also* add PrepareTempTablespaces in > BufFileCreateTemp, so that at least users of buffile.c are insulated > from the issue. buffile.c is still kind of low-level, but it's not > part of core i

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Andres Freund writes: > I'm not wild to go for a separate TAP test. A separate initdb cycle for > a a tests that takes about 30ms seems a bit over the top. Fair enough. > So I'm > inclined to either try running it in a serial step on the buildfarm > (survived a few dozen cycles with -DRELCACHE_F

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Just when you thought it was safe to go back in the water ... markhor just reported in with results showing that we have worse problems than deadlock-prone tests in the back branches: 9.4 for example looks like -- -- whole tables REINDEX TABLE pg_class; -- mapped, non-shared, critical + ERR

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Hi, On 2019-04-30 18:42:36 -0400, Tom Lane wrote: > markhor just reported in with results showing that we have worse > problems than deadlock-prone tests in the back branches: 9.4 > for example looks like > -- whole tables > REINDEX TABLE pg_class; -- mapped, non-shared, critical > + ERROR:

Re: clean up docs for v12

Hi, On 2019-04-22 14:17:48 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2019-04-22 13:27:17 -0400, Tom Lane wrote: > >> I wonder > >> also if it wouldn't be smart to explicitly check that the "guaranteeing" > >> column is not attisdropped. > > > Yea, that probably would be smart. I don

Re: clean up docs for v12

Hi, On 2019-04-08 09:18:28 -0500, Justin Pryzby wrote: > From aae1a84b74436951222dba42b21de284ed8b1ac9 Mon Sep 17 00:00:00 2001 > From: Justin Pryzby > Date: Sat, 30 Mar 2019 17:24:35 -0500 > Subject: [PATCH v2 03/12] JIT typos.. > > ..which I sent to Andres some time ago and which I noticed wer

Re: doc: improve PG 12 to_timestamp()/to_date() wording

On Tue, Apr 30, 2019 at 09:48:14PM +0300, Alexander Korotkov wrote: > I'd like to add couple of comments from my side. > > - returns an error because the second template string space is > > consumed > > - by the letter J in the input string. > > + returns an error because the se

Adding a test for speculative insert abort case

Today, while poking around the table_complete_speculative code which Ashwin mentioned in [1], we were trying to understand when exactly we would complete a speculative insert by aborting. We added a logging message to heapam_tuple_complete_speculative before it calls heap_abort_speculative and ran

Re: Adding a test for speculative insert abort case

Hi, On 2019-04-30 17:15:55 -0700, Melanie Plageman wrote: > Today, while poking around the table_complete_speculative code which Ashwin > mentioned in [1], we were trying to understand when exactly we would > complete a > speculative insert by aborting. (FWIW, it's on my todo queue to look at thi

Re: Initializing LWLock Array from Server Code

On Tue, Apr 30, 2019 at 5:52 PM Souvik Bhattacherjee wrote: > Thank you for your reply and sorry that I couldn't reply earlier. > Since I didn't get any response within a couple of days, I took the longer > route -- changed the lwlock.h and lwlock.c > for accommodating the lw locks for the shared

walsender vs. XLogBackgroundFlush during shutdown

Hi, I see there's an ongoing discussion about race conditions in walreceiver blocking shutdown, so let me start a new thread about a race condition in walsender during shutdown. The symptoms are rather simple - 'pg_ctl -m fast shutdown' gets stuck, waiting for walsender processes to catch-up and

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Replying to myself to resend to the list, since my previous attempt seems to have been eaten by a grue. On Tue, Apr 30, 2019 at 1:01 PM Robert Haas wrote: > > On Tue, Apr 30, 2019 at 1:38 AM Masahiko Sawada wrote: > > It seems to me that encrypting table data in WAL with multiple keys > > reduce

Re: message style

Replying to myself to resend to the list, since my previous attempt seems to have been eaten by a grue. On Tue, Apr 30, 2019 at 12:05 PM Robert Haas wrote: > > On Tue, Apr 30, 2019 at 10:58 AM Alvaro Herrera > wrote: > > My problem here is not really the replacement of the name to %s, but the >

Re: POC: Cleaning up orphaned files using undo logs

Replying to myself to resend to the list, since my previous attempt seems to have been eaten by a grue. On Tue, Apr 30, 2019 at 11:14 AM Robert Haas wrote: > > On Tue, Apr 30, 2019 at 2:16 AM Dilip Kumar wrote: > > Like previous version these patch set also applies on: > > https://github.com/Ent

Re: Initializing LWLock Array from Server Code

Replying to myself to resend to the list, since my previous attempt seems to have been eaten by a grue. On Mon, Apr 29, 2019 at 1:59 PM Robert Haas wrote: > > On Fri, Apr 26, 2019 at 2:58 PM Souvik Bhattacherjee > wrote: > > I have created a shared hash table in partitioned mode inside the post

Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid

On Tue, Apr 30, 2019 at 10:47:37PM +1200, Thomas Munro wrote: > On Mon, Apr 22, 2019 at 4:59 AM Noah Misch wrote: > > On Thu, Apr 18, 2019 at 04:30:46PM +1200, Thomas Munro wrote: > > > This causes make check-world to deliver a flurry of pop-ups from > > > macOS's built-in Firewall asking if perl

Re: Improve search for missing parent downlinks in amcheck

On Sun, Apr 28, 2019 at 10:15 AM Alexander Korotkov wrote: > I think this definitely not bug fix. Bloom filter was designed to be > lossy, no way blaming it for that :) I will think about a simple fix, but after the upcoming point release. There is no hurry. -- Peter Geoghegan

Re: ERROR: failed to add item to the index page

On Tue, Apr 30, 2019 at 10:58 AM Peter Geoghegan wrote:j > I have found what the problem is. I simply neglected to make a > conservative assumption about suffix truncation needing to add a heap > TID to a leaf page's new high key in nbtsort.c (following commit > dd299df8189), even though I didn't

Re: Adding a test for speculative insert abort case

On Tue, Apr 30, 2019 at 5:22 PM Andres Freund wrote: > > Not easily so - that's why the ON CONFLICT patch didn't add code > coverage for it :(. I wonder if you could whip something up by having > another non-unique expression index, where the expression acquires a > advisory lock? If that advisor

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

On 2019-04-30 15:53:07 -0700, Andres Freund wrote: > Hi, > > On 2019-04-30 18:42:36 -0400, Tom Lane wrote: > > markhor just reported in with results showing that we have worse > > problems than deadlock-prone tests in the back branches: 9.4 > > for example looks like > > > -- whole tables > >

Re: Adding a test for speculative insert abort case

On Tue, Apr 30, 2019 at 5:16 PM Melanie Plageman wrote: > Can anyone think of a good way to put this codepath under test? During the initial development of ON CONFLICT, speculative insertion itself was tested using custom stress testing that you can still get here: https://github.com/petergeoghe

Re: performance regression when filling in a table

Hello Andres, The effect is that the first generation seems to take more time, but dropping the table and regenerating again much less, with a typical 40% performance improvement between first and second run, independently of the version. The reported figures above where comparisons between fi

Re: Adding a test for speculative insert abort case

Hi, On April 30, 2019 6:43:08 PM PDT, Peter Geoghegan wrote: >On Tue, Apr 30, 2019 at 5:16 PM Melanie Plageman > wrote: >> Can anyone think of a good way to put this codepath under test? > >During the initial development of ON CONFLICT, speculative insertion >itself was tested using custom stress

Re: Adding a test for speculative insert abort case

On Wed, May 1, 2019 at 12:16 PM Melanie Plageman wrote: > s1: insert into t1 values(1, 'someval') on conflict(id) do update set val = > 'someotherval'; > s1: pause in ExecInsert before calling ExecInsertIndexTuples > s2: insert into t1 values(1, 'someval'); > s2: continue > > We don't know of a w

Re: Unhappy about API changes in the no-fsm-for-small-rels patch

On Tue, Apr 30, 2019 at 7:52 PM Alvaro Herrera wrote: > > On 2019-Apr-30, John Naylor wrote: > > > On Fri, Apr 26, 2019 at 11:52 AM Amit Kapila > > wrote: > > > As discussed above, we need to issue an > > > invalidation for following points: (a) when vacuum finds there is no > > > FSM and page

Re: POC: Cleaning up orphaned files using undo logs

On Wed, May 1, 2019 at 6:02 AM Robert Haas wrote: > > Replying to myself to resend to the list, since my previous attempt > seems to have been eaten by a grue. > > On Tue, Apr 30, 2019 at 11:14 AM Robert Haas wrote: > > > > On Tue, Apr 30, 2019 at 2:16 AM Dilip Kumar wrote: > > > Like previous v

Re: Unhappy about API changes in the no-fsm-for-small-rels patch

On Tue, Apr 30, 2019 at 6:06 PM Amit Kapila wrote: > > On Tue, Apr 30, 2019 at 2:24 PM Dilip Kumar wrote: > > > > insert into atacc1 values (21, 22, 23); > > +ERROR: could not read block 0 in file "base/16384/31379": read only > > 0 of 8192 bytes > > > > I have analysed this failure. Seems tha

Re: Unhappy about API changes in the no-fsm-for-small-rels patch

On Tue, Apr 30, 2019 at 12:48 PM Amit Kapila wrote: > > On Fri, Apr 26, 2019 at 10:46 AM John Naylor > wrote: > > > > On Wed, Apr 17, 2019 at 2:04 AM Andres Freund wrote: > > > > > > Hi, > > > > > > I'm somewhat unhappy in how much the no-fsm-for-small-rels exposed > > > complexity that looks li

Re: Unhappy about API changes in the no-fsm-for-small-rels patch

On Wed, May 1, 2019 at 9:57 AM John Naylor wrote: > > On Tue, Apr 30, 2019 at 12:48 PM Amit Kapila wrote: > > > > On Fri, Apr 26, 2019 at 10:46 AM John Naylor > > wrote: > > I don't much like the new function name GetAlternatePage, may be > > GetPageFromLocalFSM or something like that. OTOH, I

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Andres Freund writes: > On 2019-04-30 15:53:07 -0700, Andres Freund wrote: >> I'll move the test into a new "reindex_catalog" test, with a comment >> explaining that the failure cases necessitating that are somewhere >> between bugs, ugly warts, an hard to fix edge cases. > Just pushed that. loc

Re: Unhappy about API changes in the no-fsm-for-small-rels patch

On Wed, May 1, 2019 at 11:43 AM Amit Kapila wrote: > > On Tue, Apr 30, 2019 at 7:52 PM Alvaro Herrera > wrote: > > but that seems correct. > > Sounds better than keeping outdated entries indicating no-space-available. > > Agreed, but as mentioned in one of the above emails, I am also bit > scare

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Hi, On 2019-04-30 00:50:20 -0400, Tom Lane wrote: > Andres Freund writes: > > On April 29, 2019 9:37:33 PM PDT, Tom Lane wrote: > >> Seems like putting reindexes of pg_class into a test script that runs > >> in parallel with other DDL wasn't a hot idea. > > > Saw that. Will try to reproduce (an

Re: performance regression when filling in a table

Hi, On 2019-04-30 07:12:03 +0200, Fabien COELHO wrote: > On my SSD Ubuntu laptop, with postgres-distributed binaries and unmodified > default settings using local connections: > ## pg 11.2 > > time pgbench -i -s 100 > ... > done in 31.51 s > # (drop tables 0.00 s, create tables 0.01 s,

ERROR: failed to add item to the index page

With master (3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6) I'm getting this: visena=# CREATE INDEX origo_email_part_hdrvl_value_idx ON public.origo_email_part_headervalue USING btree (lower(substr((header_value)::text, 0, 1000)) varchar_pattern_ops); psql: ERROR: failed to add item to the index pag

ERROR: tuple concurrently updated when modifying privileges

Hello, hackers we witnessed this slightly misleading error in production and it took us a while to figure out what was taking place. Below are reproduction steps: -- setup create table trun(cate int4); -- session 1 begin; truncate table trun; -- session 2 grant insert on table trun to postgre

Re: CHAR vs NVARCHAR vs TEXT performance

I agree in principle, however in this particular scenario it's not our schema so we're a little reluctant to migrate the types etc. We're in a bit of a bad place because the combination of NHibernate + npgsql3/4 + this table = seqScans everywhere. Basically when npgsql changed their default type

Re: performance regression when filling in a table

Hello Andres, ## pg 11.2 done in 31.51 s ## pg 12devel (cd3e2746) real0m38.695s What change could explain such a significant performance regression? I think the pre-release packages have had assertions enabled at some point. I suggest checking that. If it's not that, profiles would

Re: [Patch] Base backups and random or zero pageheaders

Hi, Am Mittwoch, den 27.03.2019, 11:37 +0100 schrieb Michael Banck: > Am Dienstag, den 26.03.2019, 19:23 +0100 schrieb Michael Banck: > > Am Dienstag, den 26.03.2019, 10:30 -0700 schrieb Andres Freund: > > > On 2019-03-26 18:22:55 +0100, Michael Banck wrote: > > > >

Re: ERROR: failed to add item to the index page

Andreas Joseph Krogh writes: > With master (3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6) I'm getting this: > visena=# CREATE INDEX origo_email_part_hdrvl_value_idx ON > public.origo_email_part_headervalue USING btree > (lower(substr((header_value)::text, 0, 1000)) varchar_pattern_ops); > psql: ER

Re: [PATCH v4] Add \warn to psql

About v5: applies, compiles, global & local make check ok, doc gen ok. Very minor comment: \qecho is just before \o in the embedded help, where it should be just after. Sorry I did not see it on the preceding submission. Unfortunately new TAP test doesn't pass on my machine. I'm not good a

Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 15:43:16, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > With master (3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6) I'm getting this: > visena=# CREATE INDEX origo_email_part_hdrvl_value_idx ON > public.origo_email_part_headervalue USING btr

Re: Sv: Re: ERROR: failed to add item to the index page

Andreas Joseph Krogh writes: > I built with this: make distclean && ./configure > --prefix=$HOME/programs/postgresql-master --with-openssl --with-llvm && make > -j > 8 install-world-contrib-recurse install-world-doc-recurse --with-llvm, eh? Does it reproduce without that? What platform is th

Sv: Re: Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 15:53:50, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > I built with this: make distclean && ./configure > --prefix=$HOME/programs/postgresql-master --with-openssl --with-llvm && make -j > 8 install-world-contrib-recurse install-world-

Re: Unhappy about API changes in the no-fsm-for-small-rels patch

On 2019-Apr-30, John Naylor wrote: > On Fri, Apr 26, 2019 at 11:52 AM Amit Kapila wrote: > > As discussed above, we need to issue an > > invalidation for following points: (a) when vacuum finds there is no > > FSM and page has more space now, I think you can detect this in > > RecordPageWithFree

Sv: Sv: Re: Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 16:03:04, skrev Andreas Joseph Krogh < andr...@visena.com >: På tirsdag 30. april 2019 kl. 15:53:50, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > I built with this: make distclean && ./configure > --prefix=$

  1   2   >