Re: Pluggable Storage - Andres's take

On Mon, Sep 10, 2018 at 5:42 PM Haribabu Kommi wrote: > On Wed, Sep 5, 2018 at 2:04 PM Haribabu Kommi > wrote: > >> >> On Tue, Sep 4, 2018 at 10:33 AM Andres Freund wrote: >> >>> Hi, >>> >>> Thanks for the patches! >>> >>> On 2018-09-03 19:06:27 +1000, Haribabu Kommi wrote: >>> > I found couple

RE: Changing the setting of wal_sender_timeout per standby

From: Michael Paquier [mailto:mich...@paquier.xyz] > I think that the description of wal_sender_timeout and its properties should > remain where the parameter is defined, so (3) is not a good option in my > opinion. (2) has a point with the use of quotes actually, so why not just > mention options

Re: Changing the setting of wal_sender_timeout per standby

On Fri, Sep 21, 2018 at 05:37:42AM +, Tsunakawa, Takayuki wrote: > I think all of these are almost equally good. I chose (1) at first, > and you chose (3). But (2) may be the best, because it's the natural > place the user will see when configuring the standby, and it already > contains an ex

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 w

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

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 h

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 me

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 d

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 sho

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

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

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() >= QUERY

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 pr

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 t

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 error

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

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

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

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 gen

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

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

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

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

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 pa

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

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&dt=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 failu

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 when

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 M

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 for

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

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 t

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

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 hack

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 my

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 anybody

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 fails

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

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 pa

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 l

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

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 t

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 espe

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 v

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

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-09-20 09:07:21 -0400, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > FWIW, not that I want to do that now, but at some point it might make > > > sense to sub-divide this into things like number of "express

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

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 >>> (https://github.com/buca

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 calle

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 >> (https://github.com/bucardo/dbdpg/blob/master/typ

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

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

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 t

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

On 9/18/18 12:15 PM, 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, next week on Thursday, 2018-09-20. The version will be >> determined based on the state of the open items list[

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

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 cf98467

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 fo

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 C

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

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 c

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: https://github.c

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

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 do

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 !kfreebsd-i

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 mes

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 o