Re: Prepared transaction releasing locks before deregistering its GID

On Wed, Feb 20, 2019 at 03:14:07PM +0900, Masahiko Sawada wrote: > @@ -811,6 +811,9 @@ TwoPhaseGetGXact(TransactionId xid) > static TransactionId cached_xid = InvalidTransactionId; > static GlobalTransaction cached_gxact = NULL; > > + Assert(!lock_held || > +

Re: Compressed TOAST Slicing

On Tue, 19 Feb 2019 at 23:09, Paul Ramsey wrote: > On Sat, Feb 16, 2019 at 7:25 AM Simon Riggs wrote: > > > Could we get an similarly optimized implementation of -> operator for > JSONB as well? > > Are there any other potential uses? Best to fix em all up at once and > then move on to other thi

Re: pg_basebackup ignores the existing data directory permissions

On Wed, Feb 20, 2019 at 5:17 AM Haribabu Kommi wrote: > > On Fri, Feb 15, 2019 at 10:15 AM Michael Paquier > wrote: > >> On Thu, Feb 14, 2019 at 11:21:19PM +1100, Haribabu Kommi wrote: >> > On Thu, Feb 14, 2019 at 8:57 PM Magnus Hagander >> wrote: >> >> I think it could be argued that neither i

Re: Ltree syntax improvement

В письме от вторник, 29 января 2019 г. 20:43:07 MSK пользователь Dmitry Belyavsky написал: > Dear all, > > Please find attached the patch extending the sets of symbols allowed in > ltree labels. The patch introduces 2 variants of escaping symbols, via > backslashing separate symbols and via quoti

Re: [PATCH v20] GSSAPI encryption support

On 2019-02-18 16:32, Stephen Frost wrote: > Considering this is only the second encryption protocol in the project's > lifetime, I agree that using callbacks would be overkill here. What > other encryption protocols are you thinking we would be adding here? I > think most would be quite hard-pres

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

On 2019-01-03 12:16, Peter Eisentraut wrote: > On 03/01/2019 10:39, Christoph Berg wrote: >> It will especially say which _alternate.out file was used, which seems >> like a big win. So +1. > > It already shows that in the existing diff output header. > > Although if you have a really long absolu

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

On 2019-02-15 16:05, Christoph Berg wrote: > Re: Andrew Gierth 2019-02-15 <874l95m8w7@news-spur.riddles.org.uk> >> Also while we're tweaking regression test output, would it be possible >> to have some indicator of whether a test passed because a variant file >> in the resultmap was ignored in

RE: SQL statement PREPARE does not work in ECPG

Hi, Maybe, there is no work-around. For supporting it, there are two steps. step1. fix for PREPARE. step2. fix for EXECUTE. About step1, there are two way. I want to choose Idea-2. Idea-1. ecpglib prepares Oids of type listed in PREPARE statement for 5th argument of PQprepare(). But it's dif

Re: Prepared transaction releasing locks before deregistering its GID

Michael Paquier wrote: > > Attached is an updated patch. Thanks for the feedback. @@ -1755,7 +1755,7 @@ void multixact_twophase_recover(TransactionId xid, uint16 info, void *recdata, uint32 len) { - BackendId dummyBackendId = TwoPhaseGetDummyBackendId(xid); +

Re: Another way to fix inherited UPDATE/DELETE

(2019/02/20 6:48), Tom Lane wrote: In the case of a standard inheritance or partition tree, this seems to go through really easily, since all the children could share the same returned CTID column (I guess you'd also need a TABLEOID column so you could figure out which table to direct the update

Re: restrict pg_stat_ssl to superuser?

On 2019-02-19 16:57, Peter Eisentraut wrote: > On 2019-02-18 04:58, Michael Paquier wrote: >> On Fri, Feb 15, 2019 at 02:04:59PM +0100, Peter Eisentraut wrote: >>> We could remove default privileges from pg_stat_get_activity(). Would >>> that be a problem? >> >> I don't think so, still I am wonder

bgwriter_lru_maxpages limits in PG 10 sample conf

Hello We increased bgwriter_lru_maxpages limit in 10 release [1]. Docs now are changed correctly but in REL_10_STABLE postgresql.conf.sample we still have comment "0-1000 max buffers written/round". Master (and REL_11_STABLE) was updated later in 611fe7d4793ba6516e839dc50b5319b990283f4f, but n

Re: WIP: Avoid creation of the free space map for small tables

On Mon, Feb 11, 2019 at 10:48 PM John Naylor wrote: > > On 2/9/19, Amit Kapila wrote: > > > Shall we add a note to the docs of pg_freespacemap and > > pgstattuple_approx indicating that for small relations, FSM won't be > > created, so these functions won't give appropriate value? > > I've given

Re: WIP: Avoid creation of the free space map for small tables

On Wed, Feb 20, 2019 at 6:09 PM Amit Kapila wrote: > I have modified the patch for the above observations and added a > commit message as well, see if it looks okay to you. Looks good to me, thanks. -- John Naylorhttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

Re: Referential Integrity Checks with Statement-level Triggers

Corey Huinker wrote: > Attached is a patch that refactors DELETE triggers to fire at the statement > level. > > I chose delete triggers partly out of simplicity, and partly because there > some before/after row linkage in the ON UPDATE CASCADE cases where statement > level triggers might not be

Re: SQL statement PREPARE does not work in ECPG

Matsumura-san, > Maybe, there is no work-around. Did you analyze the bug? Do you know where it comes from? > For supporting it, there are two steps. Could you please start with explaining where you see the problem? I'm actually not sure what you are trying to do here. Michael -- Michael Meske

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

Re: Peter Eisentraut 2019-02-20 <40c5c12f-adad-fc86-7d43-ff7c53535...@2ndquadrant.com> > > By the same argument, it should always print which variant file was > > used so determining which _N.out files are still in use is possible. > > I would rather not overload the test output even more. A tes

Re: SQL statement PREPARE does not work in ECPG

Takahashi-san, > I tried as follows. > ... > Unfortunately, this does not work. > ECPGst_execute seems good, but prepare statement is the same as my > first post. Ah right, my bad. The workaround should have been: EXEC SQL PREPARE test_prep from "SELECT id from test_table where id = $1"; EXEC SQ

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Hi, I will work out this one with postgres -C and come back till the next commitfest. I found that something similar is already used in pg_ctl and there is a mechanism for finding valid executables in exec.c. So it does not seem to be a big deal at the first sight. I have reworked the pa

Re: SQL statement PREPARE does not work in ECPG

Takahashi-san, > EXEC SQL EXECUTE test_prep (2); Could you please also verify for me if this works correctly if you use a variable instead of the const? As in: EXEC SQL BEGIN DECLARE SECTION; int i=2; EXEC SQL END DECLARE SECTION; ... EXEC SQL EXECUTE test_prep (:i); I guess the problem is th

Re: 2019-03 CF Summary / Review - Tranche #2

(2019/02/18 12:40), Etsuro Fujita wrote: (2019/02/16 14:45), Andres Freund wrote: - postgres_fdw: Perform UPPERREL_ORDERED and UPPERREL_FINAL steps remotely WOA: This is a nontrivial change, and the design and review only started in late December. It's probably not realistic to target v12. And

Re: WIP: Avoid creation of the free space map for small tables

On Mon, Feb 11, 2019 at 10:48 PM John Naylor wrote: > > On 2/9/19, Amit Kapila wrote: > > On Tue, Feb 5, 2019 at 3:25 PM John Naylor > > wrote: > >> > >> On Tue, Feb 5, 2019 at 4:04 AM Amit Kapila > >> wrote: > > This is certainly a good test w.r.t code coverage of new code, but I > > have few

Re: Conflict handling for COPY FROM

On Tue, Feb 19, 2019 at 3:47 PM Andres Freund wrote: > > > Err, what? Again, that requires super user permissions (in contrast to > copy from/to stdin/out). Backends run as the user postgres runs under > okay i see it now and modified the patch similarly regards Surafel diff --git a/doc/src/sg

Re: 2019-03 CF Summary / Review - Tranche #2

On 16.02.2019 8:45, Andres Freund wrote: - pg_rewind: options to use restore_command from recovery.conf or command line WOA: Was previously marked as RFC, but I don't see how it is. Possibly can be finished, but does require a good bit more work. Just sent new version of the patch to

Re: Conflict handling for COPY FROM

On 2/20/19 8:01 AM, Surafel Temesgen wrote: > > > On Tue, Feb 19, 2019 at 3:47 PM Andres Freund > wrote: > > > > Err, what? Again, that requires super user permissions (in > contrast to copy from/to stdin/out). Backends run as the user > postgres runs under

Unnecessary checks for new rows by some RI trigger functions?

When reviewing a related patch [1], I spent some time thinking about the "detectNewRows" argument of ri_PerformCheck(). My understanding is that it should (via the es_crosscheck_snapshot field of EState) prevent the executor from accidentally deleting PK value that another transaction (whose data c

Re: crash in pg_identify_object_as_address

Pushed, thanks. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: WIP: Avoid creation of the free space map for small tables

Please remember to keep serial_schedule in sync. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Remove unnecessary use of PROCEDURAL

I propose the attached patch to remove some unnecessary, legacy-looking use of the PROCEDURAL keyword before LANGUAGE. We mostly don't use this anymore, so some of these look a bit old. There is still some use in pg_dump, which is harder to remove because it's baked into the archive format, so I'

Re: [PROPOSAL] Shared Ispell dictionaries

Hello, I've created the new commitfest entry since the previous entry was closed with status "Returned with feedback": https://commitfest.postgresql.org/22/2007/ I attached new version of the patch. There are changes only in 0003-Retrieve-shared-location-for-dict-v18.patch. I added a refer

Re: Row Level Security − leakproof-ness and performance implications

On 2/19/19 6:43 PM, Laurenz Albe wrote: > Pierre Ducroquet wrote: >> if we had a 'RLS-enabled' context on functions, a way to make a lot of built- >> in functions leakproof would simply be to prevent them from logging errors >> containing values. >> >> For others, like arraycontains, it's much tr

Re: Another way to fix inherited UPDATE/DELETE

Amit Langote writes: > On 2019/02/20 13:54, Tom Lane wrote: >> That's something we'd need to think about. Obviously, anything >> along this line breaks the existing FDW update APIs, but let's assume >> that's acceptable. Is it impossible, or even hard, for an FDW to >> support this definition of

Re: Another way to fix inherited UPDATE/DELETE

Etsuro Fujita writes: > (2019/02/20 6:48), Tom Lane wrote: >> In the case of a standard inheritance or partition tree, this seems to >> go through really easily, since all the children could share the same >> returned CTID column (I guess you'd also need a TABLEOID column so you >> could figure ou

list append syntax for postgresql.conf

Nowadays there are a number of methods for composing multiple postgresql.conf files for modularity. But if you have a bunch of things you want to load via shared_preload_libraries, you have to put them all in one setting. How about some kind of syntax for appending something to a list, like

Re: list append syntax for postgresql.conf

Em qua, 20 de fev de 2019 às 12:15, Peter Eisentraut escreveu: > > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them all > in one setting. H

Re: list append syntax for postgresql.conf

Re: Peter Eisentraut 2019-02-20 <74af1f60-34af-633e-ee8a-310d40c74...@2ndquadrant.com> > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them al

Re: Delay locking partitions during INSERT and UPDATE

On Tue, Feb 19, 2019 at 4:07 PM David Rowley wrote: > I'd say that here we should only discuss what this patch is doing, ... On that note, I spent some more time looking at what the patch is doing today. /* * We locked all the partitions in ExecSetupPartitionTupleRouting * inclu

Re: speeding up planning with partitions

Amit Langote writes: > On 2019/02/20 5:57, Tom Lane wrote: >> but that is not >> going to fix the fundamental problem: the cost estimate for such a >> Path should vary depending on how large we think the outer rel is, >> and we don't have a reasonable way to set that if we're trying to >> make a o

Re: list append syntax for postgresql.conf

On 2/20/19 10:15 AM, Peter Eisentraut wrote: > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them all > in one setting. How about some kind of

Re: list append syntax for postgresql.conf

On Wednesday, February 20, 2019, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put t

Re: Delay locking partitions during INSERT and UPDATE

Robert Haas writes: > On Mon, Feb 18, 2019 at 6:15 PM Tom Lane wrote: >> I'm inclined to think that if we already have lock on the parent >> partitioned table (thereby, IIUC, guaranteeing that its partitioning >> info can't change) that the order in which we acquire the same lock >> level on its

Re: Conflict handling for COPY FROM

On February 20, 2019 6:05:53 AM PST, Andrew Dunstan wrote: > >On 2/20/19 8:01 AM, Surafel Temesgen wrote: >> >> >> On Tue, Feb 19, 2019 at 3:47 PM Andres Freund > > wrote: >> >> >> >> Err, what? Again, that requires super user permissions (in >> contrast to c

Re: propagating replica identity to partitions

On Tue, Feb 19, 2019 at 5:41 PM Alvaro Herrera wrote: > OK, let me concede that point -- it's not rewriting that makes things > act differently, but rather TABLESPACE (as well as some other things) > behave that way. ALTER TABLE ... SET DATA TYPE is the obvious > counterexample. > > The Notes sec

Re: list append syntax for postgresql.conf

On 2/20/19 10:54 AM, Joe Conway wrote: >> shared_preload_libraries += 'pg_stat_statements' > > I like the idea, but presume it would apply to any GUC list, not just > shared_preload_libraries? It would be nice if there were some way for extensions to declare GUC lists (the very thing that rec

Re: Delay locking partitions during INSERT and UPDATE

On Wed, Feb 20, 2019 at 11:03 AM Tom Lane wrote: > Right, that's the same thing I was trying to say. OK, thanks. > > ... So my question is - what do > > you mean by the parenthetical note about the partitioning info not > > changing? Regardless of whether it does or does not, I think the same

Re: Row Level Security − leakproof-ness and performance implications

Pierre Ducroquet writes: > For simple functions like enum_eq/enum_ne, marking them leakproof is an > obvious fix (patch attached to this email, including also textin/textout). This is not nearly as "obvious" as you think. See prior discussions, notably https://www.postgresql.org/message-id/flat

Re: Compressed TOAST Slicing

On 2019-02-20 08:39:38 +, Simon Riggs wrote: > On Tue, 19 Feb 2019 at 23:09, Paul Ramsey wrote: > > > On Sat, Feb 16, 2019 at 7:25 AM Simon Riggs wrote: > > > > > Could we get an similarly optimized implementation of -> operator for > > JSONB as well? > > > Are there any other potential uses

Re: Index Skip Scan

> On Fri, Feb 1, 2019 at 8:24 PM Jesper Pedersen > wrote: > > Dmitry and I will look at this and take it into account for the next > version. In the meantime, just to not forget, I'm going to post another version with a fix for cursor fetch backwards, which was crashing before. And talking about

Re: list append syntax for postgresql.conf

Peter Eisentraut writes: > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them all > in one setting. How about some kind of syntax for appendi

Re: propagating replica identity to partitions

On 2019-Feb-20, Robert Haas wrote: > On Tue, Feb 19, 2019 at 5:41 PM Alvaro Herrera > wrote: > > OK, let me concede that point -- it's not rewriting that makes things > > act differently, but rather TABLESPACE (as well as some other things) > > behave that way. ALTER TABLE ... SET DATA TYPE is

Re: Protect syscache from bloating with negative cache entries

On Tue, Feb 19, 2019 at 11:15 PM Kyotaro HORIGUCHI wrote: > Difference from v15: > > Removed AllocSet accounting stuff. We use approximate memory > size for catcache. > > Removed prune-by-number(or size) stuff. > > Adressing comments from Tsunakawa-san and Ideriha-san . > > Separated cat

Re: Compressed TOAST Slicing

On Wed, Feb 20, 2019 at 11:27 AM Andres Freund wrote: > -1, I think this is blowing up the complexity of a already useful patch, > even though there's no increase in complexity due to the patch proposed > here. I totally get wanting incremental decompression for jsonb, but I > don't see why Paul

Re: propagating replica identity to partitions

On Wed, 20 Feb 2019 at 17:38, Alvaro Herrera wrote: > > Fair enough. I don't think it's entirely useful to think about this > > in terms of which operations do and don't recurse; the question in my > > mind is WHY some things recurse and other things don't, and what will > > be easiest for user

Re: Compressed TOAST Slicing

On Wed, 20 Feb 2019 at 16:27, Andres Freund wrote: > > > Sure, but we have the choice between something that benefits just a few > > cases or one that benefits more widely. > > > > If we all only work on the narrow use cases that are right in front of us > > at the present moment then we would no

Re: Compressed TOAST Slicing

> On Feb 20, 2019, at 10:37 AM, Simon Riggs wrote: > > -1, I think this is blowing up the complexity of a already useful patch, > even though there's no increase in complexity due to the patch proposed > here. I totally get wanting incremental decompression for jsonb, but I > don't see why Paul

Re: Compressed TOAST Slicing

Paul Ramsey wrote: > Oddly enough, I couldn't find many/any things that were sensitive to > left-end decompression. The only exception is "LIKE this%" which > clearly would be helped, but unfortunately wouldn't be a quick > drop-in, but a rather major reorganization of the regex handling.

Re: Compressed TOAST Slicing

On Wed, Feb 20, 2019 at 1:45 PM Paul Ramsey wrote: > What this does not support: any function that probably wants > less-than-everything, but doesn’t know how big a slice to look for. Stephen > thinks I should put an iterator on decompression, which would be an > interesting piece of work. Havi

Re: BUG #15646: Inconsistent behavior for current_setting/set_config

On 2/20/19 12:11 PM, Tom Lane wrote: > Joe Conway writes: >> On 2/20/19 11:10 AM, PG Bug reporting form wrote: >>> But current behavior returns empty string instead of NULL (the initial >>> value) after transaction is rolled back. When I restart session, NULL is >>> returned again as it is expecte

Re: propagating replica identity to partitions

On Wed, Feb 20, 2019 at 12:38 PM Alvaro Herrera wrote: > > I don't see that in the NOTES section for ALTER TABLE. Are you > > looking at some patch, or at master? > > I was looking here: > https://www.postgresql.org/docs/11/sql-altertable.html OK, I was looking at the wrong thing. Not enough ca

BRIN summarize autovac_report_workitem passes datname as relname

src/backend/postmaster/autovacuum.c declares: |static void |autovac_report_workitem(AutoVacuumWorkItem *workitem, |const char *nspname, const char *relname) But calls it like: |cur_relname = get_rel_name(workitem->avw_relation); |cur_nspname = get_namespa

Re: Compressed TOAST Slicing

On Wed, Feb 20, 2019 at 10:50 AM Daniel Verite wrote: > > Paul Ramsey wrote: > > > Oddly enough, I couldn't find many/any things that were sensitive to > > left-end decompression. The only exception is "LIKE this%" which > > clearly would be helped, but unfortunately wouldn't be a quick >

Re: Compressed TOAST Slicing

Paul Ramsey wrote: > > text_starts_with(arg1,arg2) in varlena.c does a full decompression > > of arg1 when it could limit itself to the length of the smaller arg2: > > Nice catch, I didn't find that one as it's not user visible, seems to > be only called in spgist (!!) It's also exposed

Re: bgwriter_lru_maxpages limits in PG 10 sample conf

On Wed, Feb 20, 2019 at 5:53 AM Sergei Kornilov wrote: > We increased bgwriter_lru_maxpages limit in 10 release [1]. Docs now are > changed correctly but in REL_10_STABLE postgresql.conf.sample we still have > comment "0-1000 max buffers written/round". > Master (and REL_11_STABLE) was updated l

Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's

BTW, I just pushed a fix (e04a3905e) that adds a little more code to clause_is_strict_for(). This shouldn't cause more than minor rebasing pain for you, I hope. regards, tom lane

Re: Compressed TOAST Slicing

Paul Ramsey writes: >> On Feb 20, 2019, at 10:37 AM, Simon Riggs wrote: >> If we add one set of code now and need to add another different one later, >> we will have 2 sets of code that do similar things. > Note that adding an iterator isn’t adding two ways to do the same thing, > since the ite

Re: Compressed TOAST Slicing

On 2/20/19 7:50 PM, Robert Haas wrote: > On Wed, Feb 20, 2019 at 1:45 PM Paul Ramsey wrote: >> What this does not support: any function that probably wants >> less-than-everything, but doesn’t know how big a slice to look >> for. Stephen thinks I should put an iterator on decompression, >> whic

Re: bgwriter_lru_maxpages limits in PG 10 sample conf

Hello > I'm a bit reluctant to whack postgresql.conf around in back-branches > because sometimes that makes funny things happen when somebody > upgrades, e.g. via RPM. If i remember correctly both deb and rpm packages will ask user about config difference. But good point, comment change is too s

Re: Delay locking partitions during INSERT and UPDATE

Robert Haas writes: > On Wed, Feb 20, 2019 at 11:03 AM Tom Lane wrote: >> What I was wondering about was the possibility of the set of >> tables-that-need-to-be-locked-at-all changing. Maybe that won't >> create an issue either, but I'm not quite sure. > That's pretty much what I was thinking,

Re: Compressed TOAST Slicing

Greetings, * Paul Ramsey (pram...@cleverelephant.ca) wrote: > On Wed, Feb 20, 2019 at 10:50 AM Daniel Verite > wrote: > > > > Paul Ramsey wrote: > > > > > Oddly enough, I couldn't find many/any things that were sensitive to > > > left-end decompression. The only exception is "LIKE this%"

Re: BRIN summarize autovac_report_workitem passes datname as relname

Em qua, 20 de fev de 2019 às 15:56, Justin Pryzby escreveu: > > I guess it should be database.namespace.relname ? > Yup. It is an oversight in 7526e10224f0792201e99631567bbe44492bbde4. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Cons

Re: Problems with plan estimates in postgres_fdw

On Wed, Jan 30, 2019 at 6:12 AM Etsuro Fujita wrote: > (2018/12/28 15:50), Etsuro Fujita wrote: > > Attached is a new version of the > > patch. > > Here is an updated version of the patch set. Changes are: > > * In the previous version, LIMIT without OFFSET was not performed > remotely as the co

Re: libpq host/hostaddr/conninfo inconsistencies

On Thu, Feb 14, 2019 at 1:10 PM Andres Freund wrote: > > (2) you are not against improving the documentation, although you find it > > clear enough already, but you agree that some people could get confused. > > > > The attached patch v4 only improves the documentation so that it reflects > > what

Re: Delay locking partitions during INSERT and UPDATE

On Wed, Feb 20, 2019 at 3:57 PM Tom Lane wrote: > I agree that any deadlock would have to involve somebody doing something > quite odd --- not just one partition-oriented operation, but something > taking multiple strong locks without regard to the partition structure. > So I don't see a problem w

Re: WAL insert delay settings

Greetings, * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > On 2/19/19 8:40 PM, Andres Freund wrote: > > On 2019-02-19 20:34:25 +0100, Tomas Vondra wrote: > >> On 2/19/19 8:22 PM, Andres Freund wrote: > >>> And my main point is that even if you implement a proper bytes/sec limit > >>> ONLY f

Re: Delay locking partitions during INSERT and UPDATE

On Thu, 21 Feb 2019 at 10:32, Robert Haas wrote: > I spent some time thinking about that exact issue this morning and > studying the code to try to figure that out. I wasn't able to find > any other places that seemed to need updating, but it could be that I > missed something that David also mis

[patch] Add schema total size to psql \dn+

Hi all, When we want to get total size of all relation in a schema we have to execute one of our favorite DBA query. It  is quite simple but what about displaying schema size when using \dn+ in psql ? gilles=# \dn+    List of schemas   Name  |  Owner   |  Access priv

Re: Pluggable Storage - Andres's take

On Fri, Feb 8, 2019 at 5:18 AM Amit Khandekar wrote: > In the attached v1 patch, the prefetch_distance is calculated as > effective_io_concurrency + 10. Also it has some cosmetic changes. I did a little brief review of this patch and noticed the following things. +} PrefetchState; That name see

Re: WAL insert delay settings

On 2/20/19 10:43 PM, Stephen Frost wrote: > Greetings, > ... >> >> So maybe doing it for WAL first makes sense. But I still think we need >> to have at least a rough idea how it interacts with the existing >> throttling and how it will work in the end. > > Well, it seems like Andres explained how

Re: WAL insert delay settings

Greetings, * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > On 2/20/19 10:43 PM, Stephen Frost wrote: > > Just to share a few additional thoughts after pondering this for a > > while, but the comment Andres made up-thread really struck a chord- we > > don't necessairly want to throttle anyth

Re: Refactoring the checkpointer's fsync request queue

Hi, Thanks for the update! On 2019-02-20 15:27:40 -0800, Shawn Debnath wrote: > As promised, here's a patch that addresses the points discussed by > Andres and Thomas at FOSDEM. As a result of how we want checkpointer to > track what files to fsync, the pending ops table now integrates the > f

Re: WAL insert delay settings

Hi, On 2019-02-20 18:46:09 -0500, Stephen Frost wrote: > * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > > On 2/20/19 10:43 PM, Stephen Frost wrote: > > > Just to share a few additional thoughts after pondering this for a > > > while, but the comment Andres made up-thread really struck a ch

Re: ToDo: show size of partitioned table

On Sat, Feb 16, 2019 at 10:52:35PM +0100, Pavel Stehule wrote: > I like your changes. I merged all - updated patch is attached I applied and tested your v10 patch. Find attached some light modifications. Thanks, Justin diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml

Re: Ryu floating point output patch

> "Tom" == Tom Lane writes: Tom> typedef char bool; Tom> #endif Tom> I believe that we could suppress these warnings by changing that Tom> last to be Tom> typedef unsigned char bool; After testing this locally with a hand-tweaked configure result (since I don't have hardware that trig

Re: WAL insert delay settings

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2019-02-20 18:46:09 -0500, Stephen Frost wrote: > > * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > > > On 2/20/19 10:43 PM, Stephen Frost wrote: > > > > Just to share a few additional thoughts after pondering this for a > > > > wh

Re: propagating replica identity to partitions

On Wed, 20 Feb 2019 at 18:51, Robert Haas wrote: I don't buy Simon's argument that we should treat TABLESPACE > differently because the tables might be really big and take a long > time to move. I agree that this could well be true, but nobody is > proposing to remove the ability to move tables

Re: Set fallback_application_name for a walreceiver to cluster_name

Em sex, 8 de fev de 2019 às 05:16, Peter Eisentraut escreveu: > > By default, the fallback_application_name for a physical walreceiver is > "walreceiver". This means that multiple standbys cannot be > distinguished easily on a primary, for example in pg_stat_activity or > synchronous_standby_name

Re: NOT IN subquery optimization

Jim Finnerty writes: > We have been working on improved optimization of NOT IN, and we would like > to share this optimizaton with the community. The idea that's been kicked around in the past is to detect whether the subselect's output column(s) can be proved NOT NULL, and if so, convert to an a

Re: amcheck verification for GiST

On Sun, Feb 17, 2019 at 12:55 AM Andrey Borodin wrote: > That's true, we cannot avoid locking parent and child page simultaneously to > check correctness of tuples. Right. Some further questions/comments: * I think that this should be an error: > + if (GistPageIsLeaf(page)) > + {

Re: libpq host/hostaddr/conninfo inconsistencies

Robert Haas writes: >> Robert, any chance you could opine on the doc patch, given that's your >> suggested direction? > I find it to be a more change than we really need, and I'm not sure > how much it helps to clarify the issue at hand. Here is a simpler > change which seems like it might do the

Re: Delay locking partitions during INSERT and UPDATE

Robert Haas writes: > On Wed, Feb 20, 2019 at 3:57 PM Tom Lane wrote: >> Looking at the patch itself, I agree that a bit more attention to comments >> is needed, and I wonder whether David has found all the places where >> it's now necessary to s/NoLock/RowExclusiveLock/. I don't have any >> oth

Re: Performance issue in foreign-key-aware join estimation

David Rowley writes: > Attaching the original patch again so the commitfest bot gets off my > back about the other one not applying. Pushed that one. I'm interested by the "POC" patch, but I agree that it'd take some research to show that it isn't a net negative for simple queries. It sounds li

Re: Performance issue in foreign-key-aware join estimation

On Thu, 21 Feb 2019 at 15:00, Tom Lane wrote: > Pushed that one. I'm interested by the "POC" patch, but I agree > that it'd take some research to show that it isn't a net negative > for simple queries. It sounds like you're not really interested > in pursuing that right now? Thanks for pushing

Re: NOT IN subquery optimization

Jim Finnerty writes: > re: The idea that's been kicked around in the past is to detect whether the > subselect's output column(s) can be proved NOT NULL, and if so, convert > to an antijoin just like NOT EXISTS > basically, yes. this will handle nullability of both the outer and inner > correlat

Re: insensitive collations

On Tue, Feb 19, 2019 at 6:47 AM Peter Eisentraut wrote: > Another patch to address merge conflicts. Some remarks on this: * Your draft commit message says: > This patch makes changes in three areas: > > - CREATE COLLATION DDL changes and system catalog changes to support > this new flag. > >

Re: proposal: variadic argument support for least, greatest function

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Latest patch passes installcheck-world as of d26a810 and does what it

Re: speeding up planning with partitions

On 2019/02/21 0:50, Tom Lane wrote: > However, there are other reasons why I'm not really happy with the > approach proposed in this patch. > > The main problem is that cloning the PlannerInfo while still sharing a lot > of infrastructure between the clones is a horrid hack that I think will be >

Re: Refactoring the checkpointer's fsync request queue

On Thu, Feb 21, 2019 at 12:50 PM Andres Freund wrote: > Thanks for the update! +1, thanks Shawn. It's interesting that you measure performance improvements that IIUC can come only from dropping the bitmapset stuff (or I guess bugs). I don't understand the mechanism for that improvement yet. Th

Re: Another way to fix inherited UPDATE/DELETE

(2019/02/21 0:14), Tom Lane wrote: Etsuro Fujita writes: (2019/02/20 6:48), Tom Lane wrote: In the case of a standard inheritance or partition tree, this seems to go through really easily, since all the children could share the same returned CTID column (I guess you'd also need a TABLEOID colu

Re: WIP: Avoid creation of the free space map for small tables

On Wed, Feb 20, 2019 at 8:08 PM Alvaro Herrera wrote: > > Please remember to keep serial_schedule in sync. > I don't understand what you mean by this? It is already present in serial_schedule. In parallel_schedule, we are just moving this test to one of the parallel groups. Do we need to take

Vectors instead of lists, specialised qsort(), binary_search(), unique()

Hello hackers, David Rowley posted some interesting stuff about an ArrayList[1] that would replace List in many places. (I probably would have replied to that thread if I hadn't changed email account, sorry.) I had similar thoughts when I needed to maintain a sorted vector for my refactoring pro

  1   2   >