Re: New vacuum option to do only freezing

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested I have read this patch. I like the concept and would like it to get committed

Re: Progress reporting for pg_verify_checksums

On Tue, Apr 02, 2019 at 08:11:45AM +0200, Fabien COELHO wrote: > Nope, this was way before I intervened. ISTM that a patch was submitted to > get per second or slower progress reporting on the initalization, and it was > rejected. Now that there are many SSD, maybe I could bring it back. An issue >

Re: Checksum errors in pg_stat_database

On Tue, Apr 02, 2019 at 07:43:12AM +0200, Julien Rouhaud wrote: > On Tue, Apr 2, 2019 at 6:56 AM Michael Paquier wrote: >> One thing which is not >> proposed on this patch, and I am fine with it as a first draft, is >> that we don't have any information about the broken block number and >> the fi

Re: Compressed TOAST Slicing

Hi! > I'll plan to push this tomorrow with the above change (and a few > additional comments to explain what all is going on..). Is everything ok? Can it be pushed? I'm looking here, haven't found it pushed and worry about this. https://github.com/postgres/postgres/commits/master

Re: Progress reporting for pg_verify_checksums

Bonjour Michaël, Maybe it should be -P X where X is the expected delay in seconds. Pgbench progress reporting on initialization basically outputs 10 rows per second, probably it is too much. I cannot say for pgbench. I personally think that's a lot but you are the one who wrote it as such I

Re: Pluggable Storage - Andres's take

On Tue, Apr 2, 2019 at 11:53 AM Andres Freund wrote: > Hi, > > On 2019-04-02 11:39:57 +1100, Haribabu Kommi wrote: > > > What made you rename indexam.sgml to am.sgml, instead of creating a > > > separate tableam.sgml? Seems easier to just have a separate file? > > > > > > > No specific reason, I

Re: Reduce amount of WAL generated by CREATE INDEX for gist, gin and sp-gist

On 25/03/2019 15:21, Heikki Linnakangas wrote: I had another quick look. I still think using the "generic xlog AM" for this is a wrong level of abstraction, and we should use the XLOG_FPI records for this directly. We can extend XLOG_FPI so that it can store multiple pages in a single recor

Re: speeding up planning with partitions

Thanks for taking a look. On 2019/04/02 2:34, Tom Lane wrote: > Amit Langote writes: >> On 2019/03/30 0:29, Tom Lane wrote: >>> That seems like probably an independent patch --- do you want to write it? > >> Here is that patch. >> It revises get_relation_constraints() such that the partition con

Re: Column lookup in a row performance

Tom, Thank you. > (1) Backwards compatibility, and (2) it's not clear that a different > layout would be a win for all cases. I am curious regarding (2), for my understanding it is good to find out at least one case when layout with lengths/offsets in a header will be crucially worse. I will be h

Re: Checksum errors in pg_stat_database

On Tue, Apr 2, 2019 at 6:56 AM Michael Paquier wrote: > > On Sat, Mar 30, 2019 at 06:15:11PM +0100, Julien Rouhaud wrote: > > I'd also have to get more feedback on this. For now, I'll add this > > thread to the pg12 open items, as a follow up of the initial code > > drop. > > Catching up here...

Re: proposal: type info support functions for functions that use "any" type

Hi so 9. 3. 2019 v 7:22 odesílatel Pavel Stehule napsal: > Hi, > > Tom introduced supported functions for calculation function's selectivity. > Still I have similar idea to use supported function for calculation > function's parameter's types and function return type. > > Motivation: > > Reduce

Re: Re: A separate table level option to control compression

On Tue, Apr 02, 2019 at 11:37:56AM +0900, Masahiko Sawada wrote: > Marked. + compress_tuple_threshold = RelationGetCompressTupleTarget(relation, + toast_tuple_threshold); + compress_tuple_threshold = Min(compress_tuple_threshold, +

Re: Planning counters in pg_stat_statements (using pgss_store)

On Mon, Apr 1, 2019 at 10:35 PM legrand legrand wrote: > > I have played with this patch, it works fine. Thanks for testing! > rem the last position of the "new" total_time column is confusing > +CREATE VIEW pg_stat_statements AS > + SELECT *, total_plan_time + total_exec_time AS total_time > +

RE: Problem with default partition pruning

Hi, > Maybe we should have two patches as we seem to be improving two things: > > 1. Patch to fix problems with default partition pruning originally reported > by Hosoya-san > > 2. Patch to determine if a given clause contradicts a sub-partitioned table's > partition constraint, > fixing probl

Re: Checksum errors in pg_stat_database

On Sat, Mar 30, 2019 at 06:15:11PM +0100, Julien Rouhaud wrote: > I'd also have to get more feedback on this. For now, I'll add this > thread to the pg12 open items, as a follow up of the initial code > drop. Catching up here... I think that having a completely separate view with one row for eac

Re: Unified logging system for command-line programs

On Mon, Apr 01, 2019 at 11:55:09AM -0700, Andres Freund wrote: > A written upthread, I think this should have had a uniform interface > with elog.h, and probably even share some code between the two. This is > going in the wrong direction, making it harder, not easier, to share > code between front

Re: Re: A separate table level option to control compression

On Wed, Mar 27, 2019 at 3:38 PM Masahiko Sawada wrote: > > On Thu, Mar 21, 2019 at 10:40 PM Pavan Deolasee > wrote: > > > > Hi, > > > > On Thu, Mar 21, 2019 at 3:10 AM Shaun Thomas > > wrote: > >> > >> > >> I can't really speak for the discussion related to `storage.sgml`, but > >> I based my i

Re: [HACKERS] generated columns

On Mon, Apr 01, 2019 at 10:44:05PM +0900, Michael Paquier wrote: > Really? I thought on the contrary that it should work. This reminds > me of commit 59a884e9, which has been discussed here: > https://www.postgresql.org/message-id/20160212001846.gb29...@momjian.us And this remark makes little se

Re: Progress reporting for pg_verify_checksums

On Mon, Apr 01, 2019 at 07:26:00PM +0200, Fabien COELHO wrote: > Hmmm. Progress is more an interactive feature where the previous result is > overriden thanks to the \r. Well, many people also redirect the output for such things. > Maybe it should be -P X where X is the expected > delay in second

Re: Progress reporting for pg_verify_checksums

On Mon, Apr 01, 2019 at 08:51:03PM +0200, Michael Banck wrote: > I had another look and I don't see any slowdown with your patch. I noticed one slowdown when using --disable --progress as this was scanning the data directory for the total size but we don't need it in this case. Fixed that and com

Re: patch to allow disable of WAL recycling

On Sat, Mar 30, 2019 at 11:18 AM Jerry Jelinek wrote: > I went through your new version of the patch and it all looks great to me. I moved the error handling logic around a bit so we'd capture errno immediately after the syscalls. I also made a couple of further tweaks to comments and removed so

Re: Ordered Partitioned Table Scans

Hi, On 2019/03/29 7:59, David Rowley wrote: > On Fri, 29 Mar 2019 at 00:00, Amit Langote > wrote: >> >> On 2019/03/28 8:04, David Rowley wrote: >>> If it's *always* scanned last then it's fine for ORDER BY partkey >>> NULLS LAST. If they have ORDER BY partkey NULLS FIRST then we won't >>> match

Re: pgsql: Compute XID horizon for page level index vacuum on primary.

Hi, On 2019-03-30 11:44:36 -0400, Robert Haas wrote: > On Sat, Mar 30, 2019 at 6:33 AM Thomas Munro wrote: > > I didn't understand that last sentence. > > > > Here's an attempt to write a suitable comment for the quick fix. And > > I suppose effective_io_concurrency is a reasonable default. > >

Re: COPY FROM WHEN condition

Hi, On 2019-04-02 14:06:52 +1300, David Rowley wrote: > On Tue, 2 Apr 2019 at 13:59, Andres Freund wrote: > > > > On 2019-04-02 13:41:57 +1300, David Rowley wrote: > > > On Tue, 2 Apr 2019 at 05:19, Andres Freund wrote: > > > > Thanks! I'm not quite clear whether you planning to continue working

Re: COPY FROM WHEN condition

On Tue, 2 Apr 2019 at 13:59, Andres Freund wrote: > > On 2019-04-02 13:41:57 +1300, David Rowley wrote: > > On Tue, 2 Apr 2019 at 05:19, Andres Freund wrote: > > > Thanks! I'm not quite clear whether you planning to continue working on > > > this, or whether this is a handoff? Either is fine with

Re: COPY FROM WHEN condition

Hi, On 2019-04-02 13:41:57 +1300, David Rowley wrote: > On Tue, 2 Apr 2019 at 05:19, Andres Freund wrote: > > > > On 2019-04-02 04:23:20 +1300, David Rowley wrote: > > > On Mon, 1 Apr 2019 at 08:05, Andres Freund wrote: > > > > I'll work on pushing all the other pending tableam patches today - >

Re: Pluggable Storage - Andres's take

Hi, On 2019-04-02 11:39:57 +1100, Haribabu Kommi wrote: > > What made you rename indexam.sgml to am.sgml, instead of creating a > > separate tableam.sgml? Seems easier to just have a separate file? > > > > No specific reason, I just thought of adding all the access methods under > one file. > I

Re: COPY FROM WHEN condition

On Tue, 2 Apr 2019 at 05:19, Andres Freund wrote: > > On 2019-04-02 04:23:20 +1300, David Rowley wrote: > > On Mon, 1 Apr 2019 at 08:05, Andres Freund wrote: > > > I'll work on pushing all the other pending tableam patches today - > > > leaving COPY the last non pluggable part. You'd written in a

Re: Pluggable Storage - Andres's take

On Tue, Apr 2, 2019 at 10:18 AM Andres Freund wrote: > Hi, > > On 2019-03-16 23:21:31 +1100, Haribabu Kommi wrote: > > updated patches are attached. > > Now that nearly all of the tableam patches are committed (with the > exception of the copy.c changes which are for bad reasons discussed at > [1

Re: Pluggable Storage - Andres's take

Hi, On 2019-03-16 23:21:31 +1100, Haribabu Kommi wrote: > updated patches are attached. Now that nearly all of the tableam patches are committed (with the exception of the copy.c changes which are for bad reasons discussed at [1]) I'm looking at the docs changes. What made you rename indexam.sgm

Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

On Fri, Mar 22, 2019 at 2:15 PM Peter Geoghegan wrote: > On Thu, Mar 21, 2019 at 10:28 AM Peter Geoghegan wrote: > > I'll likely push the remaining two patches on Sunday or Monday. > > I noticed that if I initidb and run "make installcheck" with and > without the "split after new tuple" optimizat

Re: monitoring CREATE INDEX [CONCURRENTLY]

I did this (I should stop c&p'ing this silly little setup code sometime): create table t (a int) partition by hash (a); create table t1 partition of t for values with (modulus 10, remainder 0); create table t2 partition of t for values with (modulus 10, remainder 1); create table t3 partition of t

Re: Fix XML handling with DOCTYPE

On 04/01/19 17:34, Alvaro Herrera wrote: > I think there were some outright bugs in the docs, at least for > XMLTABLE, that maybe we should backpatch. If you have the energy to > cherry-pick a minimal doc update to 10/11, I offer to back-patch it. I'll see what I can do. There's breathing room fo

Re: CPU costs of random_zipfian in pgbench

Alvaro Herrera writes: > On 2019-Apr-01, Tom Lane wrote: >> Seems reasonable. Pushed with minor documentation editing. > Ah, so we now we can get rid of the TState * being passed around > separately for expression execution, too? I didn't really look for follow-on simplifications, but if there

Re: CPU costs of random_zipfian in pgbench

On 2019-Apr-01, Tom Lane wrote: > Fabien COELHO writes: > >> I was wondering about that too. It seems like it'd be a wise idea to > >> further constrain s and/or n to ensure that the s > 1 code path doesn't do > >> anything too awful ... > > > Yep. The attached version enforces s >= 1.001, whic

Re: CPU costs of random_zipfian in pgbench

Fabien COELHO writes: >> I was wondering about that too. It seems like it'd be a wise idea to >> further constrain s and/or n to ensure that the s > 1 code path doesn't do >> anything too awful ... > Yep. The attached version enforces s >= 1.001, which avoids the worse cost > of iterating, accor

Re: Fix XML handling with DOCTYPE

On 2019-Apr-01, Chapman Flack wrote: > When I get a moment, I'll update the PostgreSQL vs. SQL/XML wiki page > to reflect the things that were fixed. I think there were some outright bugs in the docs, at least for XMLTABLE, that maybe we should backpatch. If you have the energy to cherry-pick a

Re: monitoring CREATE INDEX [CONCURRENTLY]

On 2019-Apr-02, Rahila Syed wrote: > 1. FWIW, below results for CIC show that blocks_done does not become equal > to blocks_total at the end of the phase or it processes last 800 blocks so > fast that > the update is not visible in less than 1 secs interval. Yeah, I noticed this too and decided

Re: Fix XML handling with DOCTYPE

On 4/1/19 4:22 PM, Tom Lane wrote: > Chapman Flack writes: >> So, xml-functions-type-docfix-6.patch. > > Pushed with some light(?) copy-editing. > > I believe this closes out everything discussed in > > https://commitfest.postgresql.org/22/1872/ > > but I haven't gone through all three threads

Re: DWIM mode for psql

Andreas Karlsson wrote > On 3/31/19 10:52 PM, Thomas Munro wrote:> Building on the excellent work > begun by commit e529cd4ffa60, I would >> like to propose a do-what-I-mean mode for psql. Please find a POC >> patch attached. It works like this: >> >> postgres=# select datnaam from pg_database

Re: monitoring CREATE INDEX [CONCURRENTLY]

Hi, On Mon, 1 Apr 2019 at 21:40, Alvaro Herrera wrote: > Hi Rahila, thanks for reviewing. > > On 2019-Mar-25, Rahila Syed wrote: > > > Please see few comments below: > > > > 1. Makecheck fails currently as view definition of expected rules.out > does > > not reflect latest changes in progress me

Re: C_C_A animal on HEAD gets stuck in initdb

On Tue, Apr 2, 2019 at 12:52 AM Christian Ullrich wrote: > I think the patch in the linked message works; it doesn't get stuck > anymore. It's still slow as molasses with C_C_A; this animal can take > 12+ hours to complete. Thanks. I pushed the fix. -- Thomas Munro https://enterprisedb.com

Re: Planning counters in pg_stat_statements (using pgss_store)

Hi, I have played with this patch, it works fine. rem the last position of the "new" total_time column is confusing +CREATE VIEW pg_stat_statements AS + SELECT *, total_plan_time + total_exec_time AS total_time +FROM pg_stat_statements(true); I wanted to perform some benchmark between those

Re: Fix XML handling with DOCTYPE

Chapman Flack writes: > So, xml-functions-type-docfix-6.patch. Pushed with some light(?) copy-editing. I believe this closes out everything discussed in https://commitfest.postgresql.org/22/1872/ but I haven't gone through all three threads in detail. Please confirm whether that CF entry can b

RE: minimizing pg_stat_statements performance overhead

Hi, it seems that your patch is not readable. If you want it to be included in a commitfest, you should add it by yourself in https://commitfest.postgresql.org/ Not sure that there is any room left in pg12 commitfest. Regard PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-ha

Re: partitioned tables referenced by FKs

On 2019-Mar-29, Jesper Pedersen wrote: > I ran my test cases for this feature, and havn't seen any issues. > > Therefore I'm marking 1877 as Ready for Committer. If others have additional > feedback feel free to switch it back. Thanks! I found two issues today. One, server side, is that during

Re: C_C_A animal on HEAD gets stuck in initdb

On Mon, Apr 1, 2019 at 4:31 AM Christian Ullrich wrote: > It does look very similar. I don't have a working gdb on the box, hence > this is from lldb. > > (lldb) bt I am almost certain that it's the same issue, based on this stack trace. -- Peter Geoghegan

Re: Unified logging system for command-line programs

On 2019-04-01 20:48:41 +0200, Peter Eisentraut wrote: > On 2019-04-01 20:31, Andres Freund wrote: > > I'm unhappy about this being committed. I don't think there was > > terribly much buyin for this amount of duplicated infrastructure. > > What duplicated infrastructure? A written upthread, I th

Re: Progress reporting for pg_verify_checksums

Hi, Am Montag, den 01.04.2019, 15:10 +0900 schrieb Michael Paquier: > On Sat, Mar 30, 2019 at 09:07:41PM +0100, Michael Banck wrote: > > The way you've now changed this is that there's a function call into > > progress_report() for every block that's being read, even if there is no > > progress re

Re: Unified logging system for command-line programs

On 2019-04-01 20:31, Andres Freund wrote: > I'm unhappy about this being committed. I don't think there was > terribly much buyin for this amount of duplicated infrastructure. What duplicated infrastructure? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24

Re: Unified logging system for command-line programs

Hi, On 2019-02-22 09:39:59 +0100, Peter Eisentraut wrote: > Here is an updated patch. I've finished the functionality to the point > where I'm content with it. I fixed up some of the remaining special > cases in pg_dump that I hadn't sorted out last time. I also moved the > scattered setvbuf(st

RE: minimizing pg_stat_statements performance overhead

Hi Fabien, > Sure, it definitely makes sense to reduce the overhead when the extension is > disabled. I wanted to understand the source of performance issue, and your > explanations where not enough for reproducing it. Thanks again Fabien. I am attaching the patch to this email in the hope of

Re: Extending USE_MODULE_DB to more test suite types

Andres Freund writes: > On 2019-04-01 06:52:13 -0700, Noah Misch wrote: >> I plan to back-patch the PostgreSQL patch, to combat buildfarm noise. >> Perhaps >> someone has test automation that sets USE_MODULE_DB and nonetheless probes >> the >> exact database name "pl_regression", but I'm not to

Re: speeding up planning with partitions

Amit Langote writes: > On 2019/03/30 0:29, Tom Lane wrote: >> That seems like probably an independent patch --- do you want to write it? > Here is that patch. > It revises get_relation_constraints() such that the partition constraint > is loaded in only the intended cases. So I see the problem y

Re: Progress reporting for pg_verify_checksums

Bonjour Michaël, I do not think that it matters. I like to see things moving, and the performance impact is null. Another point is that this bloats the logs redirected to a file by 4 compared to the initial proposal. I am not sure that this helps much for anybody. Hmmm. Progress is more an

Re: Extending USE_MODULE_DB to more test suite types

On 2019-04-01 06:52:13 -0700, Noah Misch wrote: > I plan to back-patch the PostgreSQL patch, to combat buildfarm noise. Perhaps > someone has test automation that sets USE_MODULE_DB and nonetheless probes the > exact database name "pl_regression", but I'm not too worried. The original > rationale

Re: Extending USE_MODULE_DB to more test suite types

On Mon, Apr 1, 2019 at 9:52 AM Noah Misch wrote: > > Some buildfarm runs have failed like this: > > == dropping database "pl_regression" == > ERROR: database "pl_regression" is being accessed by other users > DETAIL: There is 1 other session using the database. > > A

Re: COPY FROM WHEN condition

Hi, On 2019-04-02 04:23:20 +1300, David Rowley wrote: > On Mon, 1 Apr 2019 at 08:05, Andres Freund wrote: > > I'll work on pushing all the other pending tableam patches today - > > leaving COPY the last non pluggable part. You'd written in a private > > email that you might try to work on this on

Re: monitoring CREATE INDEX [CONCURRENTLY]

Hi Rahila, thanks for reviewing. On 2019-Mar-25, Rahila Syed wrote: > Please see few comments below: > > 1. Makecheck fails currently as view definition of expected rules.out does > not reflect latest changes in progress metrics numbering. Ouch ... fixed. > 2. + > I think there is a typo

Re: COPY FROM WHEN condition

On Mon, 1 Apr 2019 at 08:05, Andres Freund wrote: > I'll work on pushing all the other pending tableam patches today - > leaving COPY the last non pluggable part. You'd written in a private > email that you might try to work on this on Monday, so I think I'll give > this a shot on Tuesday if you'v

Re: [PATCH v22] GSSAPI encryption support

Stephen Frost writes: > * Robbie Harwood (rharw...@redhat.com) wrote: >> Stephen Frost writes: >> >> I wanted to note a couple things about this approach. It now uses >> one more buffer than before (in contrast to the previous approach, >> which reused a buffer for received data that was encry

Re: speeding up planning with partitions

Amit Langote writes: > On 2019/04/01 3:46, Tom Lane wrote: >> One thing that I intentionally left out of the committed patch was changes >> to stop short of scanning the whole simple_rel_array when looking only for >> baserels. I thought that had been done in a rather piecemeal fashion >> and it'

Extending USE_MODULE_DB to more test suite types

Some buildfarm runs have failed like this: == dropping database "pl_regression" == ERROR: database "pl_regression" is being accessed by other users DETAIL: There is 1 other session using the database. Affected runs: axolotl │ PLCheck-C │ REL9_5_

Re: [HACKERS] generated columns

On Mon, Apr 01, 2019 at 10:53:27AM +0200, Peter Eisentraut wrote: > On 2019-03-31 15:22, Jeff Janes wrote: >> I can't do a same-major-version pg_upgrade across this commit, as the >> new pg_dump is trying to dump a nonexistent attgenerated column from the >> old database.  Is that acceptable collat

Re: Question on alignment

Antonin Houska writes: > Antonin Houska wrote: >> Since palloc() only ensures MAXIMUM_ALIGNOF, that wouldn't help here anyway. > After some more search I'm not sure about that. The following comment > indicates that MAXALIGN helps too: Well, there is more than one thing going on here, and more

Re: Question on alignment

On Mon, Apr 01, 2019 at 02:38:30PM +0200, Antonin Houska wrote: > After some more search I'm not sure about that. The following comment > indicates that MAXALIGN helps too: The performance argument is true, now the reason why PGAlignedBlock has been introduced is here: https://www.postgresql.org/m

Re: Question on alignment

Antonin Houska wrote: > Since palloc() only ensures MAXIMUM_ALIGNOF, that wouldn't help here anyway. After some more search I'm not sure about that. The following comment indicates that MAXALIGN helps too: /* * Use this, not "char buf[BLCKSZ]", to declare a field or local variable * holding a

Re: SQL statement PREPARE does not work in ECPG

Hi Matsumura-san, > If we also allow the statement name including white space in PREPRARE > AS, > we have to make backend parser to scan it as IDENT. Correct, without quoting would only work when using PQprepare() et al. > I cannot think of anything. > I may notice if I try to merge. Thanks. M

Re: C_C_A animal on HEAD gets stuck in initdb

* Christian Ullrich wrote: > * Thomas Munro wrote: > >> On Mon, Apr 1, 2019 at 9:39 PM Christian Ullrich >> wrote: >>> my CLOBBER_CACHE_ALWAYS animal, jaguarundi, has gotten stuck in "make >>> check"'s initdb three times in a row now. >> >> Could it be the same as this? >> >> https://www.postg

Re: C_C_A animal on HEAD gets stuck in initdb

* Thomas Munro wrote: > On Mon, Apr 1, 2019 at 9:39 PM Christian Ullrich wrote: >> my CLOBBER_CACHE_ALWAYS animal, jaguarundi, has gotten stuck in "make >> check"'s initdb three times in a row now. > > Could it be the same as this? > > https://www.postgresql.org/message-id/CA%2BhUKGLCwPF0S4Mk7S

Re: dropdb --force

On 31.03.2019, 04:35 Andres Freund wrote: > > > bool > > -CountOtherDBBackends(Oid databaseId, int *nbackends, int *nprepared) > > +CountOtherDBBackends(Oid databaseId, int *nbackends, int *nprepared, bool > > force_terminate) > > { > > That doesn't seem like a decent API to me. Only excuse i

Re: Reduce amount of WAL generated by CREATE INDEX for gist, gin and sp-gist

On 26/03/2019 15:59, Heikki Linnakangas wrote: On 26/03/2019 11:29, Andrey Lepikhov wrote: On 25/03/2019 15:21, Heikki Linnakangas wrote: Hmm. When do we create all-zero pages during index build? That seems pretty surprising. GIST uses buffered pages. During GIST build it is possible (very

Re: speeding up planning with partitions

On 2019/03/30 0:29, Tom Lane wrote: > Amit Langote writes: >> Finally, it's not in the patch, but how about visiting >> get_relation_constraints() for revising this block of code: > > That seems like probably an independent patch --- do you want to write it? Here is that patch. It revises get_r

Re: explain plans with information about (modified) gucs

On Fri, 29 Mar 2019 at 22:07, Tomas Vondra wrote: > On Wed, Mar 27, 2019 at 09:06:04AM +0100, Rafia Sabih wrote: > >On Tue, 26 Mar 2019 at 21:04, Tomas Vondra > >wrote: > > > >> On Mon, Mar 18, 2019 at 11:31:48AM +0100, Rafia Sabih wrote: > >> >On Sun, 24 Feb 2019 at 00:06, Tomas Vondra < > toma

Re: [HACKERS][Proposal] LZ4 Compressed Storage Manager

On 31.03.2019 17:25, Николай Петров wrote: Hello everyone! Thank you for your interest to this topic. I would like to propose Compressed Storage Manager for PostgreSQL. The problem: In cases when you store some log-like data in your tables, or when you store time-series data you may face with h

RE: SQL statement PREPARE does not work in ECPG

Meskes-san I'm sorry for my slow reply. > I agree that we have to accept a quoted statement name and your > observations are correct of course, I am merely wondering if we need > the escaped quotes in the call to the ecpg functions or the libpq > functions. The following allows to use statement

Re: C_C_A animal on HEAD gets stuck in initdb

On Mon, Apr 1, 2019 at 9:39 PM Christian Ullrich wrote: > my CLOBBER_CACHE_ALWAYS animal, jaguarundi, has gotten stuck in "make > check"'s initdb three times in a row now. Could it be the same as this? https://www.postgresql.org/message-id/CA%2BhUKGLCwPF0S4Mk7S8qw%2BDK0Bq65LueN9rofAA3HHSYikW-Zw%

Re: Why does ExecComputeStoredGenerated() form a heap tuple

On 2019-03-31 05:00, Andres Freund wrote: > Also, have you actually benchmarked this code? ISTM that adding a > stored generated column would cause quite noticable slowdowns in the > COPY path based on this code. Yes, it'll be slower than not having it, but it's much faster than the equivalent tri

Re: Why does ExecComputeStoredGenerated() form a heap tuple

On 2019-03-31 04:57, Andres Freund wrote: > while rebasing the remaining tableam patches (luckily a pretty small set > now!), I had a few conflicts with ExecComputeStoredGenerated(). While > resolving I noticed: The core of that code was written a long time ago and perhaps hasn't caught up with al

Re: Question on alignment

Heikki Linnakangas wrote: > On 01/04/2019 11:01, Antonin Houska wrote: > > In copydir.c:copy_file() I read > > > > /* Use palloc to ensure we get a maxaligned buffer */ > > buffer = palloc(COPY_BUF_SIZE); > > > > No data type wider than a single byte is used to access the data in the > >

Re: Question on alignment

On 01/04/2019 11:01, Antonin Houska wrote: In copydir.c:copy_file() I read /* Use palloc to ensure we get a maxaligned buffer */ buffer = palloc(COPY_BUF_SIZE); No data type wider than a single byte is used to access the data in the buffer, and neither read() nor write() should

Re: GSoC proposal for pgAdmin 4 bytea support

Hi On Mon, Apr 1, 2019 at 3:12 AM Haoran Yu wrote: > Dear PostgreSQL community, > > I have submitted a proposal for the project pgAdmin 4 bytea support. The > project discusses storing media content (images, audio, video) as bytea. > However, I have a quick question. What does bytea data look li

Re: [HACKERS] generated columns

On 2019-03-31 15:22, Jeff Janes wrote: > I can't do a same-major-version pg_upgrade across this commit, as the > new pg_dump is trying to dump a nonexistent attgenerated column from the > old database.  Is that acceptable collateral damage?  I thought we > usually avoided that breakage within the d

Re: [HACKERS] generated columns

On 2019-03-31 05:49, Erik Rijkers wrote: > STORED in a > file_fdw foreign table still silently creates the column which then > turns out to be useless on SELECT, with an error like: > > "ERROR: column some_column_name is a generated column > DETAIL: Generated columns cannot be used in COPY." >

Re: [HACKERS] generated columns

On 2019-03-30 10:24, Justin Pryzby wrote: > create_table.sgml now has this: > > https://www.postgresql.org/docs/devel/sql-createtable.html#id-1.9.3.85.6.2.18.1.2 > + > + The keyword STORED is required to signify that the > + column will be computed on write and will be stored on dis

Re: [PROPOSAL] Shared Ispell dictionaries

On 25.02.2019 14:33, Arthur Zakirov wrote: It seems to me Tom and Andres also vote for the mmap() approach. I think I need to look closely at the mmap(). I've labeled the patch as 'v13'. Unfortunately I didn't come up with a new patch yet. So I marked the entry as "Returned with feedback" for

C_C_A animal on HEAD gets stuck in initdb

Hello, my CLOBBER_CACHE_ALWAYS animal, jaguarundi, has gotten stuck in "make check"'s initdb three times in a row now. I have trace output covering about the final minute of initdb. It mainly consists of ~9 iterations of - Open base/1/1259 [pg_class] - Seek to end [twice] - Open global/pg_

Re: speeding up planning with partitions

On 2019/04/01 3:46, Tom Lane wrote: > One thing that I intentionally left out of the committed patch was changes > to stop short of scanning the whole simple_rel_array when looking only for > baserels. I thought that had been done in a rather piecemeal fashion > and it'd be better to address it ho

Re: Enable data checksums by default

On Mon, Apr 1, 2019 at 10:17 AM Christoph Berg wrote: > Re: Tomas Vondra 2019-03-30 <20190330192543.GH4719@development> > > I have not investigated the exact reasons, but my hypothesis it's about > > the amount of WAL generated during the initial CREATE INDEX (because it > > probably ends up sett

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

On Monday, April 1, 2019 12:42 AM, Noah Misch wrote: > On Fri, Mar 29, 2019 at 09:53:51AM +, Daniel Gustafsson wrote: > > This seems like a case where it would be useful to log a shmdt() error or do > > an Assert() around the success of the operation perhaps? > > I'll add the same elog(LOG) w

Re: Enable data checksums by default

Re: Tomas Vondra 2019-03-30 <20190330192543.GH4719@development> > I have not investigated the exact reasons, but my hypothesis it's about > the amount of WAL generated during the initial CREATE INDEX (because it > probably ends up setting the hint bits), which puts additional pressure > on the stor

Question on alignment

In copydir.c:copy_file() I read /* Use palloc to ensure we get a maxaligned buffer */ buffer = palloc(COPY_BUF_SIZE); No data type wider than a single byte is used to access the data in the buffer, and neither read() nor write() should require any specific alignment. Can someone p

RE: Timeout parameters

Hi again, Since Nagaura-san seems to have addressed the additional comments on tcp user timeout patches, I still retain the status for the patch set as ready for committer. As for socket_timeout, I agree that this can be discussed further. >Fabien Coelho wrote: >> I still think that this paramete

Re: Feature: triggers on materialized views

On Thu, Mar 21, 2019 at 03:41:08PM -0400, Robert Haas wrote: > Yeah. The fact that a concurrent refresh currently does DELETE+INSERT > rather than UPDATE is currently an implementation detail. If you > allow users to hook up triggers to the inserts, then suddenly it's no > longer an implementatio