Re: Is it OK to ignore directory open failure in ResetUnloggedRelations?

On Mon, Dec 04, 2017 at 03:15:08PM -0500, Tom Lane wrote: > While working through Michael Paquier's patch to clean up inconsistent > usage of AllocateDir(), I noticed that ResetUnloggedRelations and its > subroutines are not consistent about whether a directory open failure > results in erroring

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

On Thu, Dec 14, 2017 at 08:51:06AM +0700, Ali Akbar wrote: > 2017-12-13 15:37 GMT+07:00 Amit Langote : > > > On 2017/12/13 15:59, Ali Akbar wrote: > > > > > > Thanks for the link to those thread. > > > > > > Judging from the discussion there, it will be a long way

Re: Bitmap table scan cost per page formula

On Tue, Dec 19, 2017 at 07:55:32PM +, Haisheng Yuan wrote: > Hi hackers, > > This is Haisheng Yuan from Greenplum Database. > > We had some query in production showing that planner favors seqscan over > bitmapscan, and the execution of seqscan is 5x slower than using > bitmapscan, but the

PG10.1 autovac killed building extended stats

After adding extended/MV stats to a few of our tables a few days ago, it looks like I wasn't been paying attention and this first crashed 2 nights ago. Why at 1am? not sure. I have an "reindex" job which runs at 1am, and an vacuum/analyze job which runs at 2am, but I don't use cron to change

Re: PG10.1 autovac crashed building extended stats

On Fri, Nov 17, 2017 at 01:27:49PM -0300, Alvaro Herrera wrote: > Justin Pryzby wrote: > > After adding extended/MV stats to a few of our tables a few days ago, it > > looks > > like I wasn't been paying attention and this first crashed 2 nights ago. > > Why >

Re: PG10.1 autovac killed building extended stats

On Fri, Nov 17, 2017 at 01:36:00PM -0300, Alvaro Herrera wrote: > Justin Pryzby wrote: > > > Core was generated by `postgres: autovacuum worker process gtt > > '. > > Program terminated with signal 11, Segmentation fault. > > #0 statext_ndistinct_bui

Re: Speeding up pg_upgrade

On Tue, Dec 05, 2017 at 09:01:35AM -0500, Bruce Momjian wrote: > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about > zero-downtime upgrades. ... we discussed speeding up pg_upgrade. > > There are clusters that take a long time to dump the schema from the old > cluster

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, Apr 26, 2018 at 07:29:37PM +1200, David Rowley wrote: > On 25 April 2018 at 09:59, Alvaro Herrera wrote: > > Amit Langote wrote: > >> Although the config.sgml coverage of the new capabilities seems pretty > >> good, some may find their being mentioned in 5.10

Re: [GENERAL] huge RAM use in multi-command ALTER of table heirarchy

B kernel: Killed process 47490, UID 26, (postmaster) total-vm:6813528kB, anon-rss:5212288kB, file-rss:2296kB On Wed, Oct 18, 2017 at 02:54:54PM -0500, Justin Pryzby wrote: > Hi, > > I just ran into this again in another context (see original dicussion, quoted > below). > >

allow psql to watch \dt

I thought that would be desirable, although I don't see any better way of getting there than this. I don't see other commands for which which watch is wanted...but who am I to say that watching creation extention isn't useful? So I imagine this should be generalized to save query buffer for all

Re: Postgres 11 release notes

On Fri, May 11, 2018 at 12:22:08PM -0700, Andres Freund wrote: > Btw, is it just me, or do the commit and docs confuse say stalled when > stale is intended? Should be fixed since yesterday's 8e12f4a250d250a89153da2eb9b91c31bb80c483 ? Justin

Re: doc fixes: vacuum_cleanup_index_scale_factor

3rd iteration ; thanks for bearing with me. On Tue, May 08, 2018 at 12:35:00PM +0300, Alexander Korotkov wrote: > Hi, Justin! > > Thank you for revising documentation patch. > > On Mon, May 7, 2018 at 7:55 PM, Justin Pryzby <pry...@telsasoft.com> wrote: +In order

Re: Should we add GUCs to allow partition pruning to be disabled?

On Mon, May 07, 2018 at 06:00:59PM +1200, David Rowley wrote: > Many thanks for reviewing this. 2nd round - from the minimalist department: +partitions which cannot possibly contain any matching records. maybe: partitions which cannot match any records. + +Partition pruning done

Re: doc fixes: vacuum_cleanup_index_scale_factor

On Mon, May 07, 2018 at 07:26:25PM +0300, Alexander Korotkov wrote: > Hi! > > I've revised docs and comments, and also made some fixes in the code. > See the attached patchset. > > * 0004-btree-cleanup-docs-comments-fixes.patch > Documentation and comment improvemen

documentation fixes for partition pruning, round two

On Fri, May 18, 2018 at 08:56:53PM -0500, Justin Pryzby wrote: > I reread this and have some more comments. > https://www.postgresql.org/docs/devel/static/ddl-partitioning.html > Let me know if it's useful to provide a patch. I propose this. There's two other, wider changes to

Re: documentation fixes for partition pruning, round two

On Thu, May 24, 2018 at 11:30:40AM +0900, Amit Langote wrote: > Hi Justin. > > Thanks for writing the patch. I have a couple of comments. Thanks for your review, find attached updated patch. > +possible to show the difference between a plan whose partitions have been > +pruned and one

Re: documentation fixes for partition pruning, round two

On Thu, May 24, 2018 at 10:46:38AM +1200, David Rowley wrote: > On 24 May 2018 at 09:35, Justin Pryzby <pry...@telsasoft.com> wrote: > > On Fri, May 18, 2018 at 08:56:53PM -0500, Justin Pryzby wrote: > >> I reread this and have some more comments. > >> https://www

Re: Performance regression with PostgreSQL 11 and partitioning

On Fri, May 25, 2018 at 05:17:12PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Fri, May 25, 2018 at 1:53 PM, Amit Langote > > wrote: > >> Seems here that we call find_appinfos_by_relids here for *all* > >> partitions, even if all but one

add default parallel query to v10 release notes? (Re: [PERFORM] performance drop after upgrade (9.6 > 10))

Moving to -hackers; On Sun, Jan 28, 2018 at 06:53:10PM -0500, Bruce Momjian wrote: > On Thu, Oct 26, 2017 at 02:45:15PM -0500, Justin Pryzby wrote: > > Is it because max_parallel_workers_per_gather now defaults to 2 ? > > > > BTW, I would tentatively expect a change in def

Re: Should we add GUCs to allow partition pruning to be disabled?

I reread this and have some more comments. https://www.postgresql.org/docs/devel/static/ddl-partitioning.html "however, it is not possible to use some of the inheritance features discussed in the previous section with partitioned tables and partitions" => The referenced section now follows

Re: adding tab completions

Thanks for review and comment. On Tue, Jun 05, 2018 at 05:29:42PM +0300, Arthur Zakirov wrote: > On Sun, Jun 03, 2018 at 10:39:22PM -0500, Justin Pryzby wrote: > > > Also I think it could be good to list column names after parentheses, > > > but I'm not sure if it easy to i

Re: Postgres 11 release notes

On Sat, Jun 09, 2018 at 01:35:19PM -0700, David G. Johnston wrote: > On Fri, May 11, 2018 at 8:08 AM, Bruce Momjian wrote: > > > I have committed the first draft of the Postgres 11 release notes. I > > will add more markup soon. You can view the most current version here: > > > >

Re: BUG #15237: I got "ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression"

On Wed, Jun 13, 2018 at 05:48:50AM +0100, Andrew Gierth wrote: > It then apparently went unnoticed until after the release of pg 10, at > which point it got retroactively documented (in the release notes and > nowhere else), in response to a brief discussion of a user complaint > that happened on

adding tab completions

Find attached tab completion for the following: "... Also, recursively perform VACUUM and ANALYZE on partitions when the command is applied to a partitioned table." 3c3bb99330aa9b4c2f6258bfa0265d806bf365c3 Add parenthesized options syntax for ANALYZE. 854dd8cff523bc17972d34772b0e39ad3d6d46a4

Re: "column i.indnkeyatts does not exist" in pg_upgrade from 11dev to 11b1

On Tue, May 29, 2018 at 02:00:20PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > I've used pg_upgrade like this before, but maybe from a different (recent) > > 11dev HEAD; I found: "pg_upgrade supports upgrades from 8.4.X and later to > > the > > cur

Re: adding tab completions

I finally got back to this; thanks everyone for reviews; I also added completion for parenthesized explain (...) d4382c4ae7ea1e272f4fee388aac8ff99421471a and for ALTER TABLE SET (toast_tuple_target). c2513365a0a85e77d3c21adb92fe12cfbe0d1897 BTW..should that be toast.tuple_target ?? Note that

Re: adding tab completions

Find attached an update which also supports column completion using the legacy non-parenthesized syntax. diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index 7bb47ea..699a102 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql/tab-complete.c @@ -705,6 +705,7 @@

Re: documentation fixes for partition pruning, round three

On Fri, Jun 01, 2018 at 03:00:10PM -0400, Alvaro Herrera wrote: > On 2018-May-23, Justin Pryzby wrote: > > > There's two other, wider changes to consider: ... > > > - should we find a unified term for "inheritence-based partitioning" and > > avoi

"column i.indnkeyatts does not exist" in pg_upgrade from 11dev to 11b1

I've used pg_upgrade like this before, but maybe from a different (recent) 11dev HEAD; I found: "pg_upgrade supports upgrades from 8.4.X and later to the current major release of PostgreSQL, including snapshot and beta releases." (But maybe upgrades FROM beta releases aren't supported in the

Re: \d t: ERROR: XX000: cache lookup failed for relation

On Mon, Jun 04, 2018 at 07:12:53PM +0300, Teodor Sigaev wrote: > > >Is that considered an actionable problem? > > > I think so. but I'm not able to reproduce that, I wrote a script to simplify The failure is triggered by running "\d t" in (yet) another session - sorry if that was unclear. It

\d t: ERROR: XX000: cache lookup failed for relation

Resending to -hackers https://www.postgresql.org/message-id/20180527022401.GA20949%40telsasoft.com Is that considered an actionable problem? Encountered consistently while trying to reproduce the vacuum full pg_statistic/toast_2619 bug; while running a loop around VAC FULL and more in another

Re: \d t: ERROR: XX000: cache lookup failed for relation

On Mon, Jun 04, 2018 at 08:01:41PM +0300, Teodor Sigaev wrote: > >Also note that my "INSERT" was run in a separate loop, concurrent with the > >VACUUM and ALTER, but yours is running consecutively. > > both loops run in backgound. I tried to run two scripts - and got a lot of > deadlocks but not

Re: adding tab completions

> > else if (HeadMatches1("VACUUM") && TailMatches1("(")) > COMPLETE_WITH_ATTR(prev2_wd, ""); Thanks - I've done this in the attached. It works well for having minimal logic. On Tue, Jun 05, 2018 at 05:29:42PM +0300, Arthur Zakirov wrote: > On Sun, Jun

ENOSPC FailedAssertion("!(RefCountErrors == 0)"

While grepping logs, I came across this crash, which I caused while adding many indices in a test environment. I don't know that there's any reason to believe one way or the other if this is specific to running on pg11b1. < 2018-06-17 11:38:45.465 CDT pryzbyj >FATAL: the database system is in

Re: automatic restore point

On Tue, Jun 26, 2018 at 12:04:59AM -0400, Rui DeSousa wrote: > Why not use auto commit off in the session or .psqlrc file or begin and then > use rollback? \set AUTOCOMMIT off > > What would be nice is if a syntax error didn’t abort the transaction when > auto commit is off — being a bad

pg11b1 from outside a txn: "VACUUM cannot run inside a transaction block": should be: ...or multi-command string

in pg10: ts=# begin;VACUUM FULL pg_toast.pg_toast_2619; BEGIN ERROR: 25001: VACUUM cannot run inside a transaction block LOCATION: PreventTransactionChain, xact.c:3167 => sounds fine $ psql postgres -c 'SELECT 1; VACUUM pg_statistic' ERROR:

Re: Name of main process differs between servers (postmaster vs postgres)

On Tue, Jun 26, 2018 at 04:51:32PM -0500, Jonathan Lemig wrote: > Hi, > > I noticed on two of my postgres servers, one has "postmaster" for the main > process, and the other has "postgres". My question is - why is this? For > example: On my centos6 servers: 1518140 lrwxrwxrwx 1 root

doc fixes: vacuum_cleanup_index_scale_factor

Introduced 857f9c36cda520030381bd8c2af20adf0ce0e1d4 The "minimal version" should probably be "minimum version", but I didn't include it here. Also, the documentation doesn't indicate the default value of -1 (or its special meaning). Also, my understanding of this feature changed when I read

Re: Doc tweak for huge_pages?

On Mon, Jan 22, 2018 at 07:10:33PM +1300, Thomas Munro wrote: > On Mon, Jan 22, 2018 at 6:30 PM, Justin Pryzby <pry...@telsasoft.com> wrote: > > On Mon, Jan 22, 2018 at 03:54:26PM +1300, Thomas Munro wrote: > >> On Fri, Jan 12, 2018 at 1:12 PM, Thomas Munro > >&g

Re: Doc tweak for huge_pages?

On Mon, Jan 22, 2018 at 03:54:26PM +1300, Thomas Munro wrote: > On Fri, Jan 12, 2018 at 1:12 PM, Thomas Munro > wrote: > > On Tue, Jan 9, 2018 at 6:24 AM, Catalin Iacob > > wrote: > > I don't know enough about this to make such a strong

Re: [doc fix] Correct calculation of vm.nr_hugepages

On Mon, Feb 19, 2018 at 07:05:47AM +, Tsunakawa, Takayuki wrote: > The current PostgreSQL documentation overestimates the number of huge pages > (vm.nr_hugepages) because the calculation uses the maximum virtual address > space. In practice, huge pages are only used for the anonymous shared

Re: [doc fix] Correct calculation of vm.nr_hugepages

On Wed, Feb 21, 2018 at 03:14:57PM -0500, Robert Haas wrote: > On Mon, Feb 19, 2018 at 9:43 PM, Tsunakawa, Takayuki > wrote: > > Thanks, I'd like to take this. > > Why are these values so large? The example in the documentation shows > 6490428 kB, and in my test

Re: adding tab completions

Sorry for the delay..this got lost while catching up after being out of town.. On Thu, Jun 28, 2018 at 02:20:39PM +0300, Arthur Zakirov wrote: > Thank you for the new version. > > On Wed, Jun 27, 2018 at 03:10:51PM -0500, Justin Pryzby wrote: > > Thanks - I've done this

Re: Fwd: Would like to help with documentation for Postgres 11

On Sun, Jul 29, 2018 at 11:50:40AM -0500, Michael Goldshteyn wrote: > I would like to offer some help writing and improving the English > documentation for some of the new features and changes in Postgres 11. If I > can get an email of where such help would be appreciated, so I can choose a >

10.5 but not 10.4: backend startup during reindex system: could not read block 0 in file "base/16400/..": read only 0 of 8192 bytes

I've seen this message now a handful of times recently. It seems to happen overnight, during a maintenance job which reindex things, including system catalog indices. It's easy to reproduce error under 10.5, but not under 10.3 nor 10.4. while :; do for a in pg_class_oid_index

Re: 10.5 but not 10.4: backend startup during reindex system: could not read block 0 in file "base/16400/..": read only 0 of 8192 bytes

On Thu, Aug 30, 2018 at 05:30:30PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > On Wed, Aug 29, 2018 at 11:35:51AM -0400, Tom Lane wrote: > >> As far as we can tell, that bug is a dozen years old, so it's not clear > >> why you find that you can reproduce it onl

Re: 10.5 but not 10.4: backend startup during reindex system: could not read block 0 in file "base/16400/..": read only 0 of 8192 bytes

On Wed, Aug 29, 2018 at 11:35:51AM -0400, Tom Lane wrote: > Justin Pryzby writes: > > I've seen this message now a handful of times recently. It seems to happen > > overnight, during a maintenance job which reindex things, including system > > catalog indices. > > I

Re: cache lookup failed for constraint when alter table referred by partition table

Adding Alvaro On Fri, Sep 07, 2018 at 04:02:13PM +0530, Rajkumar Raghuwanshi wrote: > postgres=# CREATE TABLE non_part (a INT,PRIMARY KEY(a)); > postgres=# CREATE TABLE part (a INT REFERENCES non_part(a)) PARTITION BY > RANGE(a); > postgres=# CREATE TABLE part_p1 PARTITION OF part FOR VALUES

Re: 10.5 but not 10.4: backend startup during reindex system: could not read block 0 in file "base/16400/..": read only 0 of 8192 bytes

On Thu, Aug 30, 2018 at 01:25:00PM -0700, Andres Freund wrote: > On August 30, 2018 1:24:12 PM PDT, Justin Pryzby wrote: > >On Thu, Aug 30, 2018 at 01:18:59PM -0700, Andres Freund wrote: > >> Could you check if both of the proposed attempts at fixing the issue > >&g

remove duplicated words in comments .. across lines

Resending to -hackers as I realized this isn't a documentation issue so not appropriate or apparently interesting to readers of -doc. Inspired by David's patch [0], find attached fixing words duplicated, across line boundaries. I should probably just call the algorithm proprietary, but if you

Re: Make deparsing of column defaults faster

On Mon, Jun 04, 2018 at 10:00:53PM -0400, Peter Eisentraut wrote: > On 6/4/18 20:55, Jeff Janes wrote: > > Since defaults can't contain Vars, this patch converts the second > > parameter to zero in places where pg_get_expr is invoked on column > > defaults. > > My in-progress generated columns

Re: How to make partitioning scale better for larger numbers of partitions

On Fri, Jul 13, 2018 at 05:49:20AM +, Tsunakawa, Takayuki wrote: > David has submitted multiple patches for PG 12, one of which speeds up > pruning of UPDATE/DELETE (I couldn't find it in the current CF, though.) > What challenges are there for future versions, and which of them are being

Re: Doc tweak for huge_pages?

On Wed, Jan 24, 2018 at 07:46:41AM +0100, Catalin Iacob wrote: > I see Peter assigned himself as committer, some more information below > for him to decide on the strength of the anti THP message. Thanks for digging this up! > And it would be good if somebody could run benchmarks on pre 4.6 and >

Re: Bug report: Dramatic increase in conflict with recovery after upgrading 10.2->10.5

On Mon, Sep 10, 2018 at 11:43:47AM +0200, Chris Travers wrote: > At present I believe this to likely be a regression. But if nobody else > knows otherwise, I should know more in a couple days. Do you have query logs or can you send details of the query ? We're not using replication, but I can't

Re: [bug fix] pg_rewind creates corrupt WAL files, and the standby cannot catch up the primary

On Sun, Mar 11, 2018 at 11:04:01PM +0900, Michael Paquier wrote: > On Fri, Mar 09, 2018 at 08:22:49AM +, Tsunakawa, Takayuki wrote: > > Thanks for reviewing. All done. > > Thanks. Please be careful with the indentation of the patch. Attached > is a slightly-updated version with a small

Re: RFC: Add 'taint' field to pg_control.

On Wed, Feb 28, 2018 at 02:18:12PM -0800, Andres Freund wrote: > On 2018-02-28 17:14:18 -0500, Peter Eisentraut wrote: > > I can see why you'd want that, but as a DBA, I don't necessarily want > > all of that recorded, especially in a quasi-permanent way. > > Huh? You're arguing that we should

Re: RFC: Add 'taint' field to pg_control.

On Wed, Feb 28, 2018 at 01:43:11PM -0800, Andres Freund wrote: > a significant number of times during investigations of bugs I wondered > whether running the cluster with various settings, or various tools > could've caused the issue at hand. Therefore I'd like to propose adding > a 'tainted'

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On Mon, Apr 09, 2018 at 09:31:56AM +0800, Craig Ringer wrote: > You could make the argument that it's OK to forget if the entire file > system goes away. But actually, why is that ok? I was going to say that it'd be okay to clear error flag on umount, since any opened files would prevent

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

Just want to add for the archive that I happened to run across what appears to be a 7-year old report of (I think) both of these vacuum/analyze bugs: Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

Re: Should we add GUCs to allow partition pruning to be disabled?

On Wed, Apr 18, 2018 at 12:07:18PM +1200, David Rowley wrote: > In PG10 the planner's partition pruning could be disabled by changing > the constraint_exclusion GUC to off. This is still the case for PG11, > but only for UPDATE and DELETE queries. There is currently no way to > disable partition

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On Thu, Mar 29, 2018 at 11:30:59AM +0900, Michael Paquier wrote: > On Tue, Mar 27, 2018 at 11:53:08PM -0400, Tom Lane wrote: > > Craig Ringer writes: > >> TL;DR: Pg should PANIC on fsync() EIO return. > > > > Surely you jest. > > Any callers of pg_fsync in the backend

Re: Index scan prefetch?

On Mon, Mar 26, 2018 at 12:43:02PM +0300, Konstantin Knizhnik wrote: > Hi, hackers. > > I was faced with the following bad performance use case with Postgres: there > is a huge append-only table with serial key (ID) > which is permanently appended using multithreaded pgloader. I think this could

open/lseek overhead with many partitions (including with "faster partitioning pruning")

TLDR: even with "faster pruning" patch, pg11dev open()+lseek() every file backing every table being queried, even for those partitions eventually "excluded". One of our customers (with the largest number of child tables, currently of relkind='r') takes a long time to plan query, and I wondered

bulk typos

I needed another distraction so bulk-checked for typos, limited to comments in *.[ch]. I'm not passionate about this, but it serves the purpose of reducing the overhead of fixing them individually. Also I heard something here recently about ugly languages.. time find . -name '*.c' -print0 |xargs

Re: [HACKERS] per-sesson errors after interrupting CLUSTER pg_attribute (not attrdef)

On Tue, Mar 20, 2018 at 01:03:57PM -0500, Justin Pryzby wrote: > On Tue, Oct 24, 2017 at 04:56:27PM -0700, Michael Paquier wrote: > > On Fri, Oct 20, 2017 at 9:01 AM, Justin Pryzby <pry...@telsasoft.com> wrote: > > > This was briefly scary but seems to have been li

Re: [HACKERS] per-sesson errors after interrupting CLUSTER pg_attribute (not attrdef)

On Tue, Oct 24, 2017 at 04:56:27PM -0700, Michael Paquier wrote: > On Fri, Oct 20, 2017 at 9:01 AM, Justin Pryzby <pry...@telsasoft.com> wrote: > > This was briefly scary but seems to have been limited to my psql session (no > > other errors logged). Issue with catcache (

Re: Function to track shmem reinit time

On Sat, Mar 03, 2018 at 01:00:52PM -0500, Peter Eisentraut wrote: > On 2/28/18 07:11, Anastasia Lubennikova wrote: > > Currently, if the 'restart_after_crash' option is on, postgres will just > > restart. > > And the only way to know that it happened is to regularly parse logfile > > or monitor

Re: Typo in src/backend/access/hash/README

On Mon, Mar 05, 2018 at 04:30:28PM +1300, Thomas Munro wrote: > Hi, > > Not sure what word was missed here, but I guess "count": > > our the number of buckets stored in our cached copy of the metapage. If > -so, the bucket has certainly been split, because the must originally > +so, the bucket

Re: RFC: Add 'taint' field to pg_control.

On Thu, Mar 01, 2018 at 09:12:18AM +0800, Craig Ringer wrote: > On 1 March 2018 at 06:28, Justin Pryzby <pry...@telsasoft.com> wrote: > > The more fine grained these are the more useful they can be: > > > > Running with fsync=off is common advice while loading, so re

\d+ fails on index on partition

For indices inherited from relkind=p: pryzbyj=# CREATE TABLE tt(i int)PARTITION BY RANGE(i); pryzbyj=# CREATE TABLE tt1 PARTITION OF tt DEFAULT; pryzbyj=# CREATE INDEX ON tt((0+i)); pryzbyj=# ALTER INDEX tt1_expr_idx ALTER COLUMN 1 SET STATISTICS 123; pryzbyj=# \d+ tt1_expr_idx ERROR: 42809:

rowcount estimate varies WRT partitionwise_join

I was crosseyed yesterday due to merge conflicts, but this still seems odd. I thought that final row counts would not vary with the details of the chosen plan. Which seems to hold true when I disable parallel join or hash join, but not for PWJ. I noticed this behavior while joining our own

pg11rc1 DROP INDEX: NOTICE: drop_trigger

ts=# CREATE INDEX ON t(i) ; CREATE INDEX ts=# DROP INDEX t_i_idx ; NOTICE: 0: drop_trigger LOCATION: exec_stmt_raise, pl_exec.c:3748 DROP INDEX ts=# ts=# \d t Table "public.t" Column | Type | Collation | Nullable | Default

Re: pg11rc1 DROP INDEX: NOTICE: drop_trigger

On Mon, Oct 15, 2018 at 03:44:52PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > ts=# CREATE INDEX ON t(i) ; > > CREATE INDEX > > ts=# DROP INDEX t_i_idx ; > > NOTICE: 0: drop_trigger > > LOCATION: exec_stmt_raise, pl_exec.c:3748 > > DROP INDEX

Re: fine tune v11 release notes

On Sat, Oct 13, 2018 at 04:34:07PM -0400, Tom Lane wrote: > "Jonathan S. Katz" writes: > > On 10/6/18 9:42 AM, Justin Pryzby wrote: > >> Find below various fixes to release notes for v11, for discussion purposes. > > > Thanks for putting this toget

Re: fine tune v11 release notes

On Sat, Oct 13, 2018 at 03:38:39PM -0500, Justin Pryzby wrote: > On Sat, Oct 13, 2018 at 04:34:07PM -0400, Tom Lane wrote: > > "Jonathan S. Katz" writes: > > > On 10/6/18 9:42 AM, Justin Pryzby wrote: > > >> Find below various fixes to release notes

backpatch to v11? Add "B" suffix for bytes to docs

I suggest this should be backpatched ? commit 36e9d413a1d6928cd809d302d495fd6880a44b1e Author: Greg Stark Date: Sat Oct 6 13:03:43 2018 -0400 Add "B" suffix for bytes to docs 6e7baa3227 and b06d8e58b5 added "B" as a valid suffix for GUC_UNIT_BYTES but neglected to add it to

Re: fine tune v11 release notes

On Sat, Oct 13, 2018 at 05:31:46PM -0400, Tom Lane wrote: > Justin Pryzby writes: > >> On Sat, Oct 13, 2018 at 04:34:07PM -0400, Tom Lane wrote: > >>> Hmm, I just saw this after spending an afternoon editing the release > >>> notes. I'll try to merge it with

Re: pg11.1 jit segv

On Thu, Nov 15, 2018 at 06:03:34PM -0600, Justin Pryzby wrote: > Verbose plan, munged for brevity/sanity due to joining wide tables, and > redacted since the view probably has to be considered proprietary. Hopefully > the remaining bits are still useful. I replaced column names with x.

pg11.1 jit segv

Crash is reproducible but only when JIT=on. postgresql11-llvmjit-11.1-1PGDG.rhel7.x86_64 [2769871.453033] postmaster[8582]: segfault at 7f083bddb780 ip 7f08127e814e sp 7ffe463506e0 error 4 [2770774.470600] postmaster[29410]: segfault at 7f0812eeb6c8 ip 7f08127eb4f0 sp

Re: pg11.1 jit segv

On Thu, Nov 15, 2018 at 02:47:55PM -0800, Andres Freund wrote: > > (gdb) bt > > #0 0x7f08127e814e in ?? () > > #1 0x in ?? () > > Could you enable jit_debugging_support and reproduce? That should give > a more useful backtrace. Core was generated by `postgres: pryzbyj ts

Re: pg11.1 jit segv

On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote: > I'm about to commit some changes to 12/master that'd possibly make it > easier to find issues like this. Is there any chance that it's easier to > repro this on master than making a reproducible test case? Yes, very possibly - this

Re: pg11.1 jit segv

On Thu, Nov 15, 2018 at 03:14:01PM -0800, Andres Freund wrote: > Huh, that's the same crash? Because I don't see any evalexpr functions > in the stack, and without those the above bt should have worked... TTBOMK it's the same .. Is it odd if i'm seeing this: (odd because of "ANOTHER") ? I guess

Re: pg11.1 jit segv

On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote: > I'm about to commit some changes to 12/master that'd possibly make it > easier to find issues like this. Are you referring to this a future commit ? commit 763f2edd92095b1ca2f4476da073a28505c13820 Rejigger materializing and

Re: pg_ls_tmpdir(); AND, Function for listing archive_status directory

On Wed, Sep 26, 2018 at 10:36:03PM +0200, Laurenz Albe wrote: > Bossart, Nathan wrote: > > Attached is a patch to add a pg_ls_tmpdir() function that lists the > > contents of a specified tablespace's pgsql_tmp directory. This is > > very similar to the existing pg_ls_logdir() and pg_ls_waldir() >

Re: buildfarm and git pull

On Thu, Sep 27, 2018 at 06:32:59PM +0300, Alexander Kuzmenkov wrote: > It just has to checkout the remote branch as-is. It doesn't clean files, but I would suggest: git checkout -B branch remote/branch Justin

fine tune v11 release notes

Find below various fixes to release notes for v11, for discussion purposes. Note: I changed these: "B-tree indexes can now be built in parallel with" "Allow btree indexes to be built in parallel" ..since they could be construed to mean building multiple indexes simultaneously (perhaps like

Re: Segfault when creating partition with a primary key and sql_drop trigger exists

On Thu, Sep 20, 2018 at 12:00:18PM +0200, Marco Slot wrote: > We're seeing a segmentation fault when creating a partition of a > partitioned table with a primary key when there is a sql_drop trigger on > Postgres 11beta4. Thanks for reporting ; I reproduced easily so added to open items list,

Re: pg11.1 jit segv

On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote: > Are you referring to this a future commit ? this OR a future commit > The table is not too special, but was probably ALTERed to add columns a good > number of times by one of our processes. It has ~1100 columns, including

Re: pg11.1 jit segv

On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote: > BTW find attached patch which I believe corrects some comments. Updated. Some of the changes may be gratuitous, but changed while I was already looking. Also note that I had to remove -flto=thin to compile under RH7. Justin d

pg11.1: dsa_area could not attach to segment

In our query logs I saw: postgres=# SELECT log_time, session_id, session_line, left(message,99), left(query,99) FROM postgres_log WHERE error_severity='ERROR' AND message NOT LIKE 'cancel%'; -[ RECORD 1

Re: bitmaps and correlation

Attached for real. diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c index 88780c0..1c25f36 100644 --- a/src/backend/optimizer/path/costsize.c +++ b/src/backend/optimizer/path/costsize.c @@ -548,11 +548,12 @@ cost_index(IndexPath *path, PlannerInfo *root,

bitmaps and correlation

PM, Justin Pryzby wrote: > > > I started playing with this weeks ago (probably during Vitaliy's problem > > report). Is there any reason cost_bitmap_heap_scan shouldn't interpolate > > based on correlation from seq_page_cost to rand_page_cost, same as > > cost_index ? >

ALTER INDEX fails on partitioned index

12dev and 11.1: postgres=# CREATE TABLE t(i int)PARTITION BY RANGE(i); postgres=# CREATE INDEX ON t(i) WITH(fillfactor=11); postgres=# ALTER INDEX t_i_idx SET (fillfactor=12); ERROR: 42809: "t_i_idx" is not a table, view, materialized view, or index LOCATION: ATWrongRelkindError,

Re: unique, partitioned index fails to distinguish index key from INCLUDEd columns

On Mon, Jan 14, 2019 at 07:31:07PM -0300, Alvaro Herrera wrote: > On 2019-Jan-09, Justin Pryzby wrote: > > > -- Fails to error > > postgres=# CREATE UNIQUE INDEX ON t(j) INCLUDE(i); > > > > -- Fail to enforce uniqueness across partitions due to failure to enforce

psql exit status with multiple -c or -f

Our deployment script failed to notice dozens of commands failed in a transaction block and I only noticed due to keeping full logs and monitoring for error_severity>'LOG'. I would have thought that exit status would be nonzero had an error occured in an earlier script. The docs since PG9.6 say:

Re: psql exit status with multiple -c or -f

On Tue, Dec 18, 2018 at 05:13:40PM +0900, Kyotaro HORIGUCHI wrote: > $ psql postgres -v ON_ERROR_STOP=0 -f ~/work/y.txt ; echo $? > $ psql postgres -v ON_ERROR_STOP=0 < ~/work/y.txt ; echo $? > c) psql postgres -v ON_ERROR_STOP=0 -c foo -c 'select 1'; echo $? > d) psql postgres -v

jit comments typos (Re: pg11.1 jit segv)

On Tue, Nov 27, 2018 at 10:24:52AM -0800, Andres Freund wrote: > And pushed. Justin, thanks again for reporting the bug and then > narrowing it down to a reproducible test case! Would've been much harder > to diagnose without that. > > I'll look into your comments patch in a bit. Thanks for

Re: pg11b1 from outside a txn: "VACUUM cannot run inside a transaction block": should be: ...or multi-command string

to do things like: psql -c 'begin;commit;create;drop' ..before figuring it out due to misleading error message, despite having written this earlier message. On Sat, Jun 23, 2018 at 04:06:37PM -0500, Justin Pryzby wrote: > in pg10: > > ts=# begin;VACUUM FULL pg_toast.pg_t

Re: performance statistics monitoring without spamming logs

Hi, I'm replying to an old thread from -performance: https://www.postgresql.org/message-id/flat/7ffb9dbe-c76f-8ca3-12ee-7914ede872e6%40stormcloud9.net I was looking at: https://commitfest.postgresql.org/20/1691/ "New GUC to sample log queries" On Tue, Jul 10, 2018 at 01:54:12PM -0400, Patrick

Re: pg11.1 jit segv

On Fri, Nov 16, 2018 at 08:29:27AM -0800, Andres Freund wrote: > > On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote: > > > I'm about to commit some changes to 12/master that'd possibly make it > commit 15d8f83128e15de97de61430d0b9569f5ebecc26 I don't think it had to do with your

  1   2   3   4   5   6   7   8   9   10   >