RE: libpq debug log

Hi Ramanarayana, Thank you for your review and suggestion. Please see the attached updated patch. > Issues found while testing >1) If invalid value is given to PGLOGMINLEVEL, empty log file is created which >should not happen. Thank you for your test. However in my dev environment, empty log

RE: Timeout parameters

From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com] > > Maybe. Could you suggest good description? > Clients wait until the socket become readable when they try to get results > of their query. > If the socket state get readable, clients read results. > (See

Re: libpq host/hostaddr/conninfo inconsistencies

On Wed, Feb 20, 2019 at 08:12:55PM -0500, Tom Lane wrote: > The second para explains the cases in which you actually do need to > provide "host", but I'm afraid that the first sentence will have > misled people enough that they won't get the point. > > I don't think there's anything very wrong

RE: Timeout parameters

Hi, Tsunakawa-san Thank you for your comments. On Wed, Feb 20, 2019 at 5:56 PM, Tsunakawa, Takayuki wrote: > > Perhaps you could also clarify a bit more through documentation on how > > socket_timeout handles the timeout differently from statement_timeout > > and tcp_user_timeout. > Maybe.

Re: Cache lookup errors with functions manipulation object addresses

On Thu, Jan 31, 2019 at 04:08:18PM +0900, Michael Paquier wrote: > End-of-commit-fest rebase and moved to next CF. Rebased version fixing some conflicts with HEAD. -- Michael From 5844b0ba07fdd8373a7ef15a1676178cae53c40d Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Tue, 25 Dec 2018

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

On Thu, Feb 21, 2019 at 7:58 AM Amit Kapila wrote: > So here you are inserting 4-byte integer and 1024-bytes variable > length record. So the tuple length will be tuple_header (24-bytes) + > 4-bytes for integer + 4-bytes header for variable length data + 1024 > bytes of actual data. So, the

RE: Timeout parameters

From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com] > BTW, tcp_user_timeout parameter of servers and clients have same name in > my current implementation. > I think it would be better different name rather than same name. > I'll name them as the following a) or b): > a)

RE: Timeout parameters

Hi, Kirk-san. Thank you for summarizing this thread. On Tue, Feb 19, 2019 at 6:05 PM, Jamison, Kirk wrote: > 1) tcp_user_timeout parameter > As for user_timeout param, there seems to be a common agreement with regards > to its need. > I think this can be "committed" separately when it's

RE: Protect syscache from bloating with negative cache entries

From: Robert Haas [mailto:robertmh...@gmail.com] > That might be enough to justify having the parameter. But I'm not > quite sure how high the value would need to be set to actually get the > benefit in a case like that, or what happens if you set it to a value > that's not quite high enough.

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

On Thu, 21 Feb 2019 at 18:02, Thomas Munro wrote: > 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

RE: Protect syscache from bloating with negative cache entries

From: Ideriha, Takeshi/出利葉 健 > I checked it with perf record -avg and perf report. > The following shows top 20 symbols during benchmark including kernel space. > The main difference between master (unpatched) and patched one seems that > patched one consumes cpu catcache-evict-and-refill

Re: [HACKERS] COPY FREEZE and PD_ALL_VISIBLE

On Tue, Jan 15, 2019 at 8:48 PM Darafei "Komяpa" Praliaskouski < m...@komzpa.net> wrote: > Hello, > > Today I bumped into need to limit first VACUUM time on data import. > I'm using utility called osmium together with COPY FREEZE to import > openstreetmap data into database. > > osmium export -c

COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

Hi, Jeff Janes raised an issue [1] about PD_ALL_VISIBLE not being set correctly while loading data via COPY FREEZE and had also posted a draft patch. I now have what I think is a more complete patch. I took a slightly different approach and instead of setting PD_ALL_VISIBLE bit initially and

RE: Timeout parameters

From: Jamison, Kirk [mailto:k.jami...@jp.fujitsu.com] > 1) tcp_user_timeout parameter > I think this can be "committed" separately when it's finalized. Do you mean you've reviewed and tested the patch by simulating a communication failure in the way Nagaura-san suggested? > 2)

Re: Prepared transaction releasing locks before deregistering its GID

On Wed, Feb 20, 2019 at 11:50:42AM +0100, Oleksii Kliukin wrote: > RecoverPreparedTransactions calls ProcessRecords with > twophase_recover_callbacks right after releasing the TwoPhaseStateLock, so I > think lock_held should be false here (matching the similar call of > TwoPhaseGetDummyProc at

RE: SQL statement PREPARE does not work in ECPG

Hi Meskes-san, > Ah right, my bad. The workaround should have been: Thank you. It works. > As for the PREPARE statement itself, could you try the attached small > patch please. It works well for my statement "EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where id = $1;".

RE: Protect syscache from bloating with negative cache entries

>From: Tsunakawa, Takayuki >>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com] >> number of tables | 100 |1000|1 >> --- >> TPS (master) |10966 |10654 |9099 >> TPS (patch)| 11137 (+1%) |10710 (+0%) |772

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

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

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

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.

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: 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

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: 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 >

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: 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

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 >>

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

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: 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

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 >

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: 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 > > > >

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

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: 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

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 >

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

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: 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

[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

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

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

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

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 > >

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

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:

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

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: 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

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, >>

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

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: 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

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

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 =

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: 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

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

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.

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 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

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

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

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: 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

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: 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

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

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

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

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: 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

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

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

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: 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

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

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

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 *

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

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.

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: 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

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

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

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

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

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

Re: crash in pg_identify_object_as_address

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

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

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

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 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

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: 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.

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

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

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

  1   2   >