Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE

On 2018-09-20 16:19:26 -0700, Andres Freund wrote: > On 2018-09-20 19:03:16 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On 2018-09-20 18:38:36 -0400, Tom Lane wrote: > > >> hmmm ... but even with variadic, C's macro facility is so weak that > > >> I'm not sure we can reimplement these

RE: Changing the setting of wal_sender_timeout per standby

From: Michael Paquier [mailto:mich...@paquier.xyz] > But that does not apply to this single parameter, no? I would think that > a section in recovery.conf is more adapted. I can see that the patch I > proposed up-thread could be more precise though, so why not adding at an > extra paragraph?

Re: transction_timestamp() inside of procedures

On Thu, Sep 20, 2018 at 10:12:06PM -0700, Andres Freund wrote: > Isn't the point that transaction_timestamp() does *not* currently change > its value, even though the transaction (although not the outermost > statement) has finished? Ouch, yes. I see the point now. Indeed that's strange to not

Re: Function to promote standby servers

On Thu, Sep 20, 2018 at 07:59:02AM +0200, Laurenz Albe wrote: > Providing SQL access for administrative tasks seems to be a > good thing, see ALTER SYSTEM and pg_reload_conf(). > > In that vein, I propose a function pg_promote() to promote > physical standby servers. No fundamental issues from

Re: Unclear error message

On Thu, Sep 20, 2018 at 09:45:09PM +0200, Laurenz Albe wrote: > That message is wrong, because "rel" and not "pkrel" is the partitioned table. > I think it should be > > ereport(ERROR, > (errcode(ERRCODE_WRONG_OBJECT_TYPE), > errmsg("foreign key cannot be

Re: transction_timestamp() inside of procedures

Hi, On 2018-09-21 13:55:36 +0900, Michael Paquier wrote: > On Thu, Sep 20, 2018 at 07:40:40PM -0400, Bruce Momjian wrote: > > This surprised me since I expected a new timestamp after commit. Is > > this something we want to change or document? Are there other > > per-transaction behaviors we

Re: transction_timestamp() inside of procedures

On Thu, Sep 20, 2018 at 07:40:40PM -0400, Bruce Momjian wrote: > This surprised me since I expected a new timestamp after commit. Is > this something we want to change or document? Are there other > per-transaction behaviors we should adjust? I don't quite follow your argument here.

Re: Proposal for Signal Detection Refactoring

On 2018-09-21 13:46:11 +0900, Michael Paquier wrote: > On Thu, Sep 20, 2018 at 03:08:34PM +0200, Chris Travers wrote: > > So here's a small patch. I will add it for the next commit fest unless > > anyone has any reason I shouldn't. > > - return InterruptPending && (QueryCancelPending ||

Re: Proposal for Signal Detection Refactoring

On Thu, Sep 20, 2018 at 03:08:34PM +0200, Chris Travers wrote: > So here's a small patch. I will add it for the next commit fest unless > anyone has any reason I shouldn't. - return InterruptPending && (QueryCancelPending || ProcDiePending); + return PENDING_INTERRUPT_LEVEL() >=

Re: Strange failure in LWLock on skink in REL9_5_STABLE

Thomas Munro writes: > On Fri, Sep 21, 2018 at 4:06 PM Tom Lane wrote: >> Why would we fix it rather than just removing it? > I assumed we wouldn't remove an extern C function extension code > somewhere might use. Though admittedly I'd be surprised if anyone > used this one. Unless it looks

Re: Changing the setting of wal_sender_timeout per standby

On Fri, Sep 21, 2018 at 02:28:07AM +, Tsunakawa, Takayuki wrote: > I find it more user friendly to include a description somewhere that > the user can tune the timeout per standby, like I added a tip in the > description of wal_sender_timeout. I'm afraid users won't know > whether and how to

Re: Strange failure in LWLock on skink in REL9_5_STABLE

On Fri, Sep 21, 2018 at 4:06 PM Tom Lane wrote: > Thomas Munro writes: > > ... There may be ways to fix the dsm_resize() path > > based on the observation that you don't need to fallocate() if you > > made the mapping smaller, and if you made it bigger then you could > > always undo that on

Re: Strange failure in LWLock on skink in REL9_5_STABLE

On 2018-09-20 23:46:54 -0400, Tom Lane wrote: > Andres Freund writes: > > I've made sure that the setting is off now however, I'm not > > trusting the related logic very much... > > Was it on before? Yes.

Re: Strange failure in LWLock on skink in REL9_5_STABLE

Thomas Munro writes: > ... There may be ways to fix the dsm_resize() path > based on the observation that you don't need to fallocate() if you > made the mapping smaller, and if you made it bigger then you could > always undo that on error (or not) and you haven't thrown away any > data. Hmm...

Re: Strange failure in LWLock on skink in REL9_5_STABLE

On Fri, Sep 21, 2018 at 3:21 PM Andres Freund wrote: > I'm quite suspicious of the logic around: > > /* > * If we received a query cancel or termination signal, we > will have > * EINTR set here. If the caller said that errors are OK > here,

Re: Problem while setting the fpw with SIGHUP

On Wed, Sep 19, 2018 at 02:20:34PM +0900, Michael Paquier wrote: > On Tue, Sep 18, 2018 at 04:15:42PM +0900, Kyotaro HORIGUCHI wrote: >> My latest patch tries to remove the window by imposing all >> responsibility to apply config file changes to the shared FPW >> flag on the checkpointer.

Re: generating bootstrap entries for array types

On 9/21/18, Tom Lane wrote: > I did some other minor hacking (mostly, fixing the documentation) > and pushed it. Thank you. -John Naylor

Re: [WIP] [B-Tree] Retail IndexTuple deletion

The v6 version of quick vacuum, which utilizes the amtargetdelete() interface for retail indextuple deletion. Now it is more simple and laconic. It must be applied after Retail-IndexTuple-Deletion-Access-Method.patch. BENCHMARKS: --- Initial script: pgbench -i -s $scale # initial DB

Re: Strange failure in LWLock on skink in REL9_5_STABLE

Andres Freund writes: > On 2018-09-20 23:15:45 -0400, Tom Lane wrote: >> https://www.postgresql.org/docs/devel/static/kernel-resources.html#SYSTEMD-REMOVEIPC > That shouldn't be relevant here - I'm not running the buildfarm from an > interactive session and then logging out. So that code

Re: Strange failure in LWLock on skink in REL9_5_STABLE

On 2018-09-20 23:15:45 -0400, Tom Lane wrote: > Thomas Munro writes: > > On Fri, Sep 21, 2018 at 2:59 PM Tom Lane wrote: > >> I was just looking at that, and my guess is that it was caused by > >> something doing an ipcrm or equivalent, and is unrelated to your patch. > >> Especially since skink

Re: Strange failure in LWLock on skink in REL9_5_STABLE

On 2018-09-20 22:59:29 -0400, Tom Lane wrote: > Thomas Munro writes: > > Andres pinged me off-list to point out this failure after my commit > > fb389498be: > > > ! FATAL: semop(id=332464133) failed: Invalid argument > > I was just looking at that, and my guess is that it was caused by >

Re: Strange failure in LWLock on skink in REL9_5_STABLE

Thomas Munro writes: > On Fri, Sep 21, 2018 at 2:59 PM Tom Lane wrote: >> I was just looking at that, and my guess is that it was caused by >> something doing an ipcrm or equivalent, and is unrelated to your patch. >> Especially since skink has succeeded with that patch in several other >>

Re: Strange failure in LWLock on skink in REL9_5_STABLE

On Fri, Sep 21, 2018 at 2:59 PM Tom Lane wrote: > Thomas Munro writes: > > Andres pinged me off-list to point out this failure after my commit > > fb389498be: > > > ! FATAL: semop(id=332464133) failed: Invalid argument > > I was just looking at that, and my guess is that it was caused by >

Re: Strange failure in LWLock on skink in REL9_5_STABLE

Thomas Munro writes: > Andres pinged me off-list to point out this failure after my commit > fb389498be: > ! FATAL: semop(id=332464133) failed: Invalid argument I was just looking at that, and my guess is that it was caused by something doing an ipcrm or equivalent, and is unrelated to your

Re: logical decoding bug when mapped relation with toast contents is rewritten repeatedly

Hi, On 2018-09-14 16:13:46 +0200, Tomas Vondra wrote: > > > > I suspect the proper fix would be to have a new HEAP_INSERT_NO_LOGICAL > > option, and specify that in raw_heap_insert() iff > > RelationIsLogicallyLogged(state->rs_old_rel) or something like that. > > > > Attached is a *prototype*

Strange failure in LWLock on skink in REL9_5_STABLE

Hello, Andres pinged me off-list to point out this failure after my commit fb389498be: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2018-09-20%2005%3A24%3A34 Change Set for this build: fb389498be Tue Sep 18 11:19:22 2018 UTC Allow DSM allocation to be interrupted. The failure

RE: Changing the setting of wal_sender_timeout per standby

From: Michael Paquier [mailto:mich...@paquier.xyz] > Thanks for the new version. Per my comments up-thread here, you cannot > actually use PGC_BACKEND: > https://www.postgresql.org/message-id/20180919061303.GB19808@paquier.x > yz > > This would break the case where this parameter is reloaded

Re: Bug fix for glibc broke freebsd build in REL_11_STABLE

Hi, On 2018-09-13 14:29:59 -0700, Andres Freund wrote: > On 2018-09-04 17:51:30 -0700, Andres Freund wrote: > > My current proposal is thus to do add a check that does > > #if defined(__clang__) && defined(__i386__) && !defined(__SSE2_MATH__) > > something-that-fails > > #endif > > in an autoconf

Re: FETCH FIRST clause PERCENT option

Hi, On 2018-09-20 17:06:36 -0700, Mark Dilger wrote: > I should think that spilling anything to a tuplestore would only be needed > if the query contains an ORDER BY expression. If you query > > FETCH FIRST 50 PERCENT * FROM foo; > > you should just return every other row, discarding the

Re: FETCH FIRST clause PERCENT option

> On Aug 16, 2018, at 7:34 AM, Andres Freund wrote: > > Hi, > > On 2018-08-16 17:27:45 +0300, Surafel Temesgen wrote: >> FETCH FIRST with PERCENT option is SQL standard that state limit count to >> be specified in a percentage in addition to specify it in exact count and >> listed as one of

Re: Changing the setting of wal_sender_timeout per standby

On Wed, Sep 19, 2018 at 06:21:52AM +, Tsunakawa, Takayuki wrote: > How embarrassing... I'm sorry to cause you trouble to point out a > silly mistake like this (I thought I would write as you suggested, but > it seems that I was not who I usually am.) The revised patch > attached. Thanks

transction_timestamp() inside of procedures

This function shows that only clock_timestamp() advances inside a procedure, not statement_timestamp() or transaction_timestamp(): CREATE OR REPLACE PROCEDURE test_timestamp () AS $$ DECLARE str TEXT; BEGIN WHILE TRUE LOOP

Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE

On 2018-09-20 19:03:16 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-09-20 18:38:36 -0400, Tom Lane wrote: > >> hmmm ... but even with variadic, C's macro facility is so weak that > >> I'm not sure we can reimplement these with it. What would the > >> expansion look like? > > >

On-disk compatibility for nbtree-unique-key enhancement

I would like to get some feedback on dealing with on-disk compatibility for my nbtree patch, which is in the current CF [1]. I thought I'd start a new thread on these questions, since it's probably the most sensitive aspect of the project, and can be discussed in a fairly contained way. My patch

Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE

Andres Freund writes: > On 2018-09-20 18:38:36 -0400, Tom Lane wrote: >> hmmm ... but even with variadic, C's macro facility is so weak that >> I'm not sure we can reimplement these with it. What would the >> expansion look like? > There's a dirty hack to count arguments in vararg macros: >

Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE

On 2018-09-20 18:38:36 -0400, Tom Lane wrote: > Thomas Munro writes: > > . o O ( hmm, we now have variadic macros ) > > hmmm ... but even with variadic, C's macro facility is so weak that > I'm not sure we can reimplement these with it. What would the > expansion look like? There's a dirty

Re: Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE

Thomas Munro writes: > . o O ( hmm, we now have variadic macros ) hmmm ... but even with variadic, C's macro facility is so weak that I'm not sure we can reimplement these with it. What would the expansion look like? (It constantly annoys me that C's so weak here. In the language I used for

Unreadable, unmaintainable code in tab completion

At some point, somebody had the bright idea that various queries in tab-complete.c should be named like this: Query_for_list_of_tsvmf Query_for_list_of_tmf Query_for_list_of_tpm Query_for_list_of_tm Even assuming that you can fill in the unstated "relations of these relkinds", I challenge

Re: FETCH FIRST clause PERCENT option

On Fri, Aug 31, 2018 at 11:42 PM Surafel Temesgen wrote: > On Tue, Aug 28, 2018 at 7:33 PM Erik Rijkers wrote: >> >> ; >> >> TRAP: FailedAssertion("!(slot != ((void *)0))", File: "execTuples.c", >> Line: 42 > > The attache patch include a fix for the crash .can you check it again? FYI this

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

On Wed, Sep 19, 2018 at 9:56 PM, Andrey Lepikhov wrote: > Note, that the interface of _bt_moveright() and _bt_binsrch() functions with > combination of scankey, scantid and nextkey parameters is too semantic > loaded. > Everytime of code reading i spend time to remember, what this functions do >

Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE

On Fri, Sep 21, 2018 at 9:22 AM Tom Lane wrote: > Arthur Zakirov writes: > > On Thu, Aug 30, 2018 at 05:54:23PM +0100, Dagfinn Ilmari Mannsåker wrote: > >> And just after hitting send, I noticed I'd typed ALTER TABLE instead of > >> ALTER DATABASE, including in the commit message :( > >> Fixed

Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE

Arthur Zakirov writes: > On Thu, Aug 30, 2018 at 05:54:23PM +0100, Dagfinn Ilmari Mannsåker wrote: >> And just after hitting send, I noticed I'd typed ALTER TABLE instead of >> ALTER DATABASE, including in the commit message :( >> Fixed patch attached. > The patch seems reasonable. It fixes the

Re: [patch] Support LLVM 7

Re: To Andres Freund 2018-09-20 <20180920210315.gb21...@msg.df7cb.de> > Server beendete die Verbindung unerwartet Something ate the attachments. Sorry. FATAL: fatal llvm error: Cannot select: 0x57e61d40: ch,glue = X86ISD::CALL 0x57e61cb0, 0x57e61e18, Register:i32 $edi, RegisterMask:Untyped,

Re: [patch] Support LLVM 7

Re: Andres Freund 2018-09-20 <20180920173238.f5idtzdlpkjsu...@alap3.anarazel.de> > That's pretty clearly an LLVM bug. Could you enable jit_dump_bitcode and > send the bitcode files (I assume there should be something like > ..bc and the same with .optimized.bc) from the > data directory? > > Not

Re: Allow parallelism for deferrable serializable txns

On Thu, Sep 6, 2018 at 2:14 PM Andres Freund wrote: > afaict for deferrable READ ONLY DEFERRABLE transactions we could > trivially allow parallelism? Am I missing something? I think you are right. What's more, DEFERRABLE transactions seem very likely to be cases where parallelism would be

Re: [patch] Support LLVM 7

Re: Andres Freund 2018-09-20 <20180920173009.ywi5grbotl7um...@alap3.anarazel.de> > Hm, this is pretty helpful. Sorry to ask, but could you a) turn on > jit_debugging_support (connection start) b) jit_dump_bitcode. > > Then reproduce again. After that, it'd be helpful to get: > 1) /proc/cpuinfo

Unclear error message

In backend/commands/tablecmds.c, function ATAddForeignKeyConstraint, I find: if (rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE) { if (!recurse) ereport(ERROR, (errcode(ERRCODE_WRONG_OBJECT_TYPE), errmsg("foreign key referencing partitioned table

Re: generating bootstrap entries for array types

I wrote: > I did some other minor hacking (mostly, fixing the documentation) > and pushed it. BTW, I hadn't thought to measure before, but this patch cut the size of pg_type.dat by almost 40%. Nice! regards, tom lane

Re: generating bootstrap entries for array types

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Tom Lane writes: >> I'm inclined to think the right way is to do the expansion always, >> and teach reformat_dat_file.pl to drop autogenerated array types >> on the way out, making this work more like the existing facilities

Re: generating bootstrap entries for array types

On 9/20/18, Dagfinn Ilmari Mannsåker wrote: > Hi again John, Hi Ilmari, My apologies -- your messages ended up in my spam folder. I only saw this thread again when Tom replied. Thanks for the review! I'll keep a look out for any future messages. -John Naylor

Re: shared-memory based stats collector

Hi, On 2018-09-20 09:55:27 +0200, Antonin Houska wrote: > I've spent some time reviewing this version. > > Design > -- > > 1. Even with your patch the stats collector still uses an UDP socket to >receive data. Now that the shared memory API is there, shouldn't the >messages be sent

Re: [patch] Support LLVM 7

Hi, On 2018-09-20 10:10:44 +0200, Christoph Berg wrote: > In the meantime, there's a third architecture where llvm itself > compiled, but explodes with PG11 - x32: > > SELECT '' AS tf_12, BOOLTBL1.*, BOOLTBL2.* > FROM BOOLTBL1, BOOLTBL2 > WHERE BOOLTBL2.f1 <> BOOLTBL1.f1; > ! FATAL:

Re: [patch] Support LLVM 7

On 2018-09-20 15:18:14 +0200, Christoph Berg wrote: > Re: To Andres Freund 2018-09-20 <20180920081044.ga16...@msg.df7cb.de> > > > > 2018-09-15 10:49:25.052 UTC [26458] DETAIL: Failed process was > > > > running: SELECT '' AS tf_12, BOOLTBL1.*, BOOLTBL2.* > > > >FROM BOOLTBL1,

Re: Query is over 2x slower with jit=on

On 2018-09-20 09:07:21 -0400, Stephen Frost wrote: > Greetings, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2018-09-19 23:26:52 -0400, Tom Lane wrote: > > > Andres Freund writes: > > > > JIT: > > > > Functions: 2 > > > > Generation Time: 0.680 ms > > > > Inlining: true > > > >

Re: generating bootstrap entries for array types

Tom Lane writes: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: >> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: >>> Doing this in genbki.pl makes DBD::Pg lose its array type information, >>> since it uses Catalog::ParseData() to get it >>>

Re: v11 transaction semantics inside procedures

Hi čt 20. 9. 2018 v 17:55 odesílatel Dave Cramer napsal: > Is there somewhere that the transaction semantics inside a procedure are > documented ? From what I can tell transactions start from the first DML > statement and end implicitly when the procedure exits. Commit or Rollback > can be

Re: generating bootstrap entries for array types

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: >> Doing this in genbki.pl makes DBD::Pg lose its array type information, >> since it uses Catalog::ParseData() to get it >>

v11 transaction semantics inside procedures

Is there somewhere that the transaction semantics inside a procedure are documented ? From what I can tell transactions start from the first DML statement and end implicitly when the procedure exits. Commit or Rollback can be called anytime inside the transaction and this implicitly starts another

Re: [patch] Support LLVM 7

Re: To Andres Freund 2018-09-20 <20180920081044.ga16...@msg.df7cb.de> > > > 2018-09-15 10:49:25.052 UTC [26458] DETAIL: Failed process was running: > > > SELECT '' AS tf_12, BOOLTBL1.*, BOOLTBL2.* > > > FROM BOOLTBL1, BOOLTBL2 > > > WHERE BOOLTBL2.f1 <> BOOLTBL1.f1; > > > 2018-09-15

Proposal for Signal Detection Refactoring

After the patch we did for the race condition here, one point which was brought up which I thought was quite relevant was the fact that checking global flags feels a little ugly. I would like to set up a patch which refactors this as follows: 1. We create an enum of cancellation levels:

Re: fast default vs triggers

On 09/19/2018 10:35 PM, Andrew Dunstan wrote: On 09/18/2018 03:36 PM, Andrew Dunstan wrote: Tomas Vondra has pointed out to me that there's an issue with triggers not getting expanded tuples for columns with fast defaults. Here is an example that shows the issue:    andrew=# create

Re: Query is over 2x slower with jit=on

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-09-19 23:26:52 -0400, Tom Lane wrote: > > Andres Freund writes: > > > JIT: > > > Functions: 2 > > > Generation Time: 0.680 ms > > > Inlining: true > > > Inlining Time: 7.591 ms > > > Optimization: true > > >

Re: [HACKERS] Bug in to_timestamp().

On Thu, Sep 20, 2018 at 6:09 AM amul sul wrote: > On Thu, Sep 20, 2018, 3:22 AM Alexander Korotkov > wrote: >> It's hard to understand whether it was expected, because it wasn't >> properly documented. More important that it's the same behavior we >> have before cf984672, and purpose of

Re: when set track_commit_timestamp on, database system abort startup

On Wed, Sep 19, 2018 at 12:12 PM, Kyotaro HORIGUCHI wrote: > At Sat, 15 Sep 2018 19:26:39 +0900, Masahiko Sawada > wrote in >> >> To fix that maybe we can disable commitTs if >> >> controlFile->track_commit_timestamp == false and the >> >> track_commit_timestamp == true even in crash recovery.

Re: generating bootstrap entries for array types

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed The v2 patch is IMO ready to commit. The documentation in the

Re: generating bootstrap entries for array types

Hi again John, ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > Doing this in genbki.pl makes DBD::Pg lose its array type information, > since it uses Catalog::ParseData() to get it > (https://github.com/bucardo/dbdpg/blob/master/types.c#L439). May I > suggest moving gen_array_types() to

Re: PostgreSQL 11 {Beta 4, RC1} Release: 2018-09-20

On 9/20/18 1:13 AM, Haroon wrote: > On Tue, 18 Sep 2018 at 21:15, Jonathan S. Katz > wrote: > > On 9/13/18 12:51 PM, Jonathan S. Katz wrote: > > Hi, > > > > We are planning to have another release of PostgreSQL 11, either > Beta 4 > > or RC1,

Re: doc - add missing documentation for "acldefault"

On 09/19/2018 12:30 PM, John Naylor wrote: > On 9/19/18, Tom Lane wrote: >> However, I don't object to documenting any function that has its >> own pg_description string. > > Speaking of, that description string seems to have been neglected. > I've attached a remedy for that. Thanks, will take

RE: Size and size_t in dsa API

>> As a non-expert developer's opinion, I think mixing of Size and size_t makes >> difficult >to understand source code. > >Agreed. Let's change them all to size_t and back-patch that to keep future >back-patching easy. Patch attached. Thank you for the quick action. I'm happy now. I confirmed

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

We're seeing a segmentation fault when creating a partition of a partitioned table with a primary key when there is a sql_drop trigger on Postgres 11beta4. We discovered it because the Citus extension creates a sql_drop trigger, but it's otherwise unrelated to the Citus extension:

Re: Size and size_t in dsa API

On Thu, Sep 20, 2018 at 6:28 PM Ideriha, Takeshi wrote: > As a non-expert developer's opinion, I think mixing of Size and size_t makes > difficult to understand source code. Agreed. Let's change them all to size_t and back-patch that to keep future back-patching easy. Patch attached. --

Re: Is it possible for postgres_fdw to push down queries on co-located tables?

(2018/09/18 23:20), Jinhua Luo wrote: Sorry, the example is not so proper. I just think even if it's a simple example, e.g. join two co-located tables, the planner should work out to push down it. Can you confirm the postgresql could detect co-located tables on the same foreign server and push

Re: [HACKERS] proposal: schema variables

rent/static/sql-createtable.html > > -- > Arthur Zakirov > Postgres Professional: http://www.postgrespro.com > Russian Postgres Company > schema-variables-20180920-01.patch.gz Description: application/gzip

Re: [patch] Support LLVM 7

Re: Andres Freund 2018-09-20 <20180919222600.myk5nec6unhrj...@alap3.anarazel.de> > > I did an upload of postgresql-11 beta3 with llvm 7 enabled on the > > architectures where it is available (or supposed to become available), > > that is, on !alpha !hppa !hurd-i386 !ia64 !kfreebsd-amd64

Re: shared-memory based stats collector

I've spent some time reviewing this version. Design -- 1. Even with your patch the stats collector still uses an UDP socket to receive data. Now that the shared memory API is there, shouldn't the messages be sent via shared memory queue? [1] That would increase the reliability of

impact of SPECTRE and MELTDOWN patches

Hi I would like to know what are the recommandation to resolve the problem of performance impact after applying the SPECTRE and MELTDOWN patches ? Do we have to add more CPUs ? NB : I have tested on one of our production database and I get an impact

Re: Postgres 11 release notes

On 8/25/18 11:24 PM, Peter Geoghegan wrote: > On Sat, Aug 25, 2018 at 2:18 PM, Bruce Momjian wrote: >>> I think that's less "our" logic and more yours, that has become >>> established because you've done most of the major release notes for a >>> long time. I'm not trying to say that that's wrong

Size and size_t in dsa API

Hi, I'm trying to use DSA API and confused a little bit about $subject. Some type of return value or arguments are defined as size_t but others are as Size. Example: - dsa_area *dsa_create_in_place(void *place, size_t size, int tranche_id, dsm_segment *segment) - Size

Re: Connection slots reserved for replication

Hello. I agree to the objective. At Mon, 17 Sep 2018 14:25:56 +0200, Alexander Kukushkin wrote in > Hi, > > 2018-09-14 12:23 GMT+02:00 Masahiko Sawada : > > >> 2. If we know that this is neither superuser nor replication connection, we > >> should check that there are at least

Function to promote standby servers

Providing SQL access for administrative tasks seems to be a good thing, see ALTER SYSTEM and pg_reload_conf(). In that vein, I propose a function pg_promote() to promote physical standby servers. If there are no fundamental objections, I'll add it to the next commitfest. Yours, Laurenz Albe