Re: [HACKERS] condition variables

On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro wrote: > Also, I have attached a v2->v3 diff ... Ugh. I meant a v1->v2 diff. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)

On 13/08/16 05:44, Jeff Janes wrote: On Fri, Aug 12, 2016 at 1:40 AM, Mark Kirkwood However your index rebuild gets you from 5 to 3 GB - does that really help performance significantly? It can make a big difference, depending on how much RAM you have. Yeah - I suspect this is the issue -

[HACKERS] patch proposal

Hi, During the recovery process, It would be nice if PostgreSQL generates an error by aborting the recovery process (instead of starting-up the cluster) if the intended recovery target point is not reached and give an option to DBA to resume the recovery process from where it exactly stopped.

Re: [HACKERS] to_date_valid()

On 14.08.2016 01:52, Andreas 'ads' Scherbaum wrote: Attached is a patch to "do the right thing". The verification is in "to_date()" now, the extra function is removed. Regression tests are updated - two or three of them returned a wrong date before, and still passed. They fail now.

Re: [HACKERS] Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)

>So on average in a large randomly filled index, pages spend more time nearer 50% full than 100% full. I think we can make this number more...controllable. Before split we can check whether left and right pages both are in shared buffer and if they are seriously under certain fillfactor, say

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

> > >>> I think the whole idea of a fast temporary table is that there > > >>> are no catalog entries. If there are no catalog entries, then > > >>> dependencies are not visible. If there ARE catalog entries, to > > >>> what do they refer? Without a pg_class entry for the table, > > >>> there's

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

2016-08-15 11:01 GMT+02:00 Aleksander Alekseev : > > > >>> I think the whole idea of a fast temporary table is that there > > > >>> are no catalog entries. If there are no catalog entries, then > > > >>> dependencies are not visible. If there ARE catalog entries, to >

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

> But we can change this discussion little bit different. I believe so > solution should be *global temporary tables*. These tables has > persistent catalogue entries. Data are joined with session. These > tables can be effective solution of problem with temporary tables, > can be strong benefit

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

2016-08-15 12:18 GMT+02:00 Aleksander Alekseev : > > The global temporary tables has persistent rows in the catalogue. The > > mapping to files can be marked as special and real mapping should be > > only in memory. > > > > So the changes in catalogue related to global

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

2016-08-15 12:00 GMT+02:00 Aleksander Alekseev : > > But we can change this discussion little bit different. I believe so > > solution should be *global temporary tables*. These tables has > > persistent catalogue entries. Data are joined with session. These > > tables

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

> The global temporary tables has persistent rows in the catalogue. The > mapping to files can be marked as special and real mapping should be > only in memory. > > So the changes in catalogue related to global temporary tables are > pretty less frequently. I'm afraid I still don't get it. Let

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Re: Tom Lane 2016-07-30 <1184.1469890...@sss.pgh.pa.us> > In short, I think that the way to make something like this work is to > figure out how to have "virtual" catalog rows describing a temp table. > Or maybe to partition the catalogs so that vacuuming away temp-table > rows is easier/cheaper

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Re: To Tom Lane 2016-08-15 <20160815111057.v2mqqjp4aabvw...@msg.df7cb.de> > Re: Tom Lane 2016-07-30 <1184.1469890...@sss.pgh.pa.us> > > In short, I think that the way to make something like this work is to > > figure out how to have "virtual" catalog rows describing a temp table. > > Or maybe to

[HACKERS] pg_hba_file_settings view patch

Hi All, While working on pg_hba_lookup function that can be used to lookup for an client authentication that can be matched for given input parameters, Tom raised some concrete use case issues in the following mail [1]. In this same thread, he raised some advantages of having a view similar like

Re: [HACKERS] Declarative partitioning - another take

Thanks a lot for taking a look at this. On 2016/08/11 3:22, Robert Haas wrote: > On Wed, Aug 10, 2016 at 7:09 AM, Amit Langote > wrote: >> Attached is the latest set of patches to implement declarative >> partitioning. > > Cool. I would encourage you to give

Re: [HACKERS] to_date_valid()

On 15.08.2016 10:24, Artur Zakirov wrote: On 14.08.2016 01:52, Andreas 'ads' Scherbaum wrote: Attached is a patch to "do the right thing". The verification is in "to_date()" now, the extra function is removed. Regression tests are updated - two or three of them returned a wrong date before,

Re: [HACKERS] to_date_valid()

On 15.08.2016 14:33, Andreas 'ads' Scherbaum wrote: Is it right and "true" way to validate date by extra transforming and comparison? Maybe validate date by using ValidateDate(). Attached sample patch. This does not solve the problem at hand, and let's wrong dates/formats slip through:

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Why are you sending this off-list? Please let's keep the discussion on the mailing list. I suggest resending this there. On Mon, Aug 15, 2016 at 5:01 AM, Aleksander Alekseev wrote: >> > >>> I think the whole idea of a fast temporary table is that there >> > >>> are

Re: [HACKERS] Pluggable storage

On Sat, Aug 13, 2016 at 2:15 AM, Alvaro Herrera wrote: > Many have expressed their interest in this topic, but I haven't seen any > design of how it should work. That's it. My design presented at PGCon was very sketchy, and I didn't deliver any prototype yet. >

Re: [HACKERS] to_date_valid()

On 15.08.2016 13:44, Artur Zakirov wrote: On 15.08.2016 14:33, Andreas 'ads' Scherbaum wrote: Is it right and "true" way to validate date by extra transforming and comparison? Maybe validate date by using ValidateDate(). Attached sample patch. This does not solve the problem at hand, and

Re: [HACKERS] WIP: Barriers

On Sat, Aug 13, 2016 at 7:18 PM, Thomas Munro wrote: > I would like to propose "barriers" for Postgres processes. A barrier > is a very simple mechanism for coordinating parallel computation, as > found in many threading libraries. > > First, you initialise a

Re: [HACKERS] Slowness of extended protocol

Apologies, I accidentally replied off-list, here's the response I sent. Vladimir, I suggest you reply to this message with your own response... On Sat, Aug 13, 2016 at 6:32 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Shay>To be honest, the mere idea of having an SQL parser

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

On 08/14/2016 04:38 PM, Tom Lane wrote: I did a trial run following the current pgindent README procedure, and noticed that the perltidy step left me with a pile of '.bak' files littering the entire tree. This seems like a pretty bad idea because a naive "git add ." would have committed them.

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

Andrew Dunstan writes: > On 08/14/2016 04:38 PM, Tom Lane wrote: >> I did a trial run following the current pgindent README procedure, and >> noticed that the perltidy step left me with a pile of '.bak' files >> littering the entire tree. This seems like a pretty bad idea

Re: [HACKERS] WIP: Barriers

On Sun, Aug 14, 2016 at 6:54 PM, konstantin knizhnik wrote: > Barriers are really very simple and convenient mechanism for process > synchronization. > But it is actually a special case of semaphores: having semaphore primitive > it is trivial to implement a barrier.

Re: [HACKERS] Logical Replication WIP

> On 11 Aug 2016, at 17:43, Petr Jelinek wrote: > >> >> * Also I wasn’t able actually to run replication itself =) While regression >> tests passes, TAP >> tests and manual run stuck. pg_subscription_rel.substate never becomes ‘r’. >> I’ll investigate >> that more and

Re: [HACKERS] Bug in to_timestamp().

On Thursday, 11 August 2016 3:18 PM, Artur Zakirov wrote: >Here is my patch. It is a proof of concept.>Date/Time >Formatting>>There are changes in date/time formatting >rules:-> now to_timestamp() and to_date() skip spaces in the input string and 

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

> Why are you sending this off-list? Please let's keep the discussion > on the mailing list. I suggest resending this there. Sorry for that. I accidentally removed pgsql-hackers@ from CC list or maybe my email client somehow did it for me. Short after that I realized my mistake and sent a copy

Re: [HACKERS] Slowness of extended protocol

On Sat, Aug 13, 2016 at 11:20 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Tatsuo>Interesting. What would happen if a user changes some of GUC > parameters? Subsequent session accidentally inherits the changed GUC > parameter? > > Yes, that is what happens. > The idea is not to

Re: [HACKERS] [parallel query] random server crash while running tpc-h query on power2

On Sat, Aug 13, 2016 at 4:36 AM, Amit Kapila wrote: > AFAICS, your patch seems to be the right fix for this issue, unless we > need the instrumentation information during execution (other than for > explain) for some purpose. Hmm, I disagree. It should be the job of

Re: [HACKERS] Slowness of extended protocol

Shay> What? I really didn't understand your point here. All the doc is saying is Shay> that if the driver doesn't support prepared statements, then using them Please read again. PreparedStatement is the only way to execute statements in JDBC API. There's no API that allows user to specify "use

Re: [HACKERS] Logical Replication WIP

On 13/08/16 17:34, Steve Singer wrote: On 08/05/2016 11:00 AM, Petr Jelinek wrote: Hi, as promised here is WIP version of logical replication patch. Thanks for keeping on this. This is important work Feedback is welcome. + + Publication + +A Publication object can be defined on

Re: [HACKERS] WIP: Covering + unique indexes.

14.08.2016 20:11, Andrey Borodin: The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, failed Spec compliant: tested, passed Documentation:tested, passed Hi hackers! I've read

Re: [HACKERS] Bug in to_timestamp().

Monday, 15 August 2016 9:58 PM, Robert Haas wrote: >On Mon, Aug 15, 2016 at 10:56 AM, amul sul wrote: >> On Thursday, 11 August 2016 3:18 PM, Artur Zakirov >> wrote: [Skipped..] >Well, what's the Oracle behavior in any of

Re: [HACKERS] [parallel query] random server crash while running tpc-h query on power2

On Mon, Aug 15, 2016 at 6:02 PM, Robert Haas wrote: > On Sat, Aug 13, 2016 at 4:36 AM, Amit Kapila > wrote: > > AFAICS, your patch seems to be the right fix for this issue, unless we > > need the instrumentation information during execution (other

Re: [HACKERS] Fix comment in ATExecValidateConstraint

On 2016/07/29 23:50, Robert Haas wrote: > On Mon, Jul 25, 2016 at 4:18 AM, Amit Langote > wrote: >> The comment seems to have been copied from ATExecAddColumn, which says: >> >> /* >> * If we are told not to recurse, there had better not be any >> - * child

Re: [HACKERS] Bug in to_timestamp().

On Mon, Aug 15, 2016 at 10:56 AM, amul sul wrote: > On Thursday, 11 August 2016 3:18 PM, Artur Zakirov > wrote: > >>Here is my patch. It is a proof of concept. >>Date/Time Formatting >> >>There are changes in date/time

Re: [HACKERS] WIP: Barriers

On 15.08.2016 15:42, Thomas Munro wrote: This implementation is using a spinlock for the arrival counter, and signals (via Robert's condition variables and latches) for waking up peer processes when the counter reaches the target. I realise that using signals for this sort of thing is a bit

Re: [HACKERS] Pluggable storage

On Fri, Aug 12, 2016 at 7:15 PM, Alvaro Herrera wrote: > Many have expressed their interest in this topic, but I haven't seen any > design of how it should work. Here's my attempt; I've been playing with > this for some time now and I think what I propose here is a good

Re: [HACKERS] Slowness of extended protocol

Vladimir>> Yes, that is what happens. Vladimir>> The idea is not to mess with gucs. Shay:> Wow... That is... insane... Someone might say that "programming languages that enable side-effects are insane". Lots of connection pools work by sharing the connections and it is up to developer if he can

Re: [HACKERS] patch proposal

On 8/15/16 2:33 AM, Venkata B Nagothi wrote: > During the recovery process, It would be nice if PostgreSQL generates an > error by aborting the recovery process (instead of starting-up the > cluster) if the intended recovery target point is not reached and give > an option to DBA to resume the

Re: [HACKERS] Undiagnosed bug in Bloom index

On Sat, Aug 13, 2016 at 6:22 PM, Tom Lane wrote: > Jeff Janes writes: >> I am getting corrupted Bloom indexes in which a tuple in the table >> heap is not in the index. > > Will push a fix in a bit. After 36 hours of successful running on two

Re: [HACKERS] condition variables

On Mon, Aug 15, 2016 at 1:58 AM, Thomas Munro wrote: > On Sun, Aug 14, 2016 at 9:04 AM, Thomas Munro > wrote: >> On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote: >>> [condition-variable-v1.patch] >> >> Don't

Re: [HACKERS] Slowness of extended protocol

On Mon, Aug 15, 2016 at 3:16 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Vladimir>> Yes, that is what happens. > Vladimir>> The idea is not to mess with gucs. > > Shay:> Wow... That is... insane... > > Someone might say that "programming languages that enable side-effects > are

Re: [HACKERS] New version numbering practices

Peter Eisentraut writes: > On 8/1/16 11:49 AM, Tom Lane wrote: >> Somebody needs to come up with a patch implementing this changeover. > Here is such a patch. It does not yet implement: I've pushed this with minor additional twiddling. We can work on the "UI

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

On 08/15/2016 10:19 AM, Tom Lane wrote: Andrew Dunstan writes: On 08/14/2016 04:38 PM, Tom Lane wrote: I did a trial run following the current pgindent README procedure, and noticed that the perltidy step left me with a pile of '.bak' files littering the entire tree.

Re: [HACKERS] Slowness of extended protocol

> > > I'm not going to respond to the part about dealing with prepared > statements errors, since I think we've already covered that and there's > nothing new being said. I don't find automatic savepointing acceptable, and > a significant change of the PostgreSQL protocol to support this doesn't >

Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs

On Mon, Aug 15, 2016 at 3:06 PM, Tom Lane wrote: > After doing the tedious and easily forgotten (I almost did forget) > minor version bumps for our shared libraries, > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0b9358d4406b9b45a06855d53f491cc7ce9550a9 >

Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs

Robert Haas writes: > On Mon, Aug 15, 2016 at 3:06 PM, Tom Lane wrote: >> That would give us an automatic annual change in the minor version. >> If we ever made an incompatible change in a shlib, we could advance >> its SO_MAJOR_VERSION but keep this

Re: [HACKERS] Refactoring of heapam code.

08.08.2016 12:43, Anastasia Lubennikova: 08.08.2016 03:51, Michael Paquier: On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote: Anastasia Lubennikova wrote: So there is a couple of patches. They do not cover all mentioned problems, but I'd like to get a feedback

Re: [HACKERS] Pluggable storage

13.08.2016 02:15, Alvaro Herrera: Many have expressed their interest in this topic, but I haven't seen any design of how it should work. Here's my attempt; I've been playing with this for some time now and I think what I propose here is a good initial plan. This will allow us to write

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

On 2016-05-25 21:13, Tom Lane wrote: > Robert Haas writes: >> On Sun, May 22, 2016 at 4:16 PM, Piotr Stefaniak >> wrote: >>> I think I've managed to improve pg_bsd_indent's handling of two types of >>> cases. > >> Wow, that seems pretty great.

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

Andrew Dunstan writes: > On 08/15/2016 10:19 AM, Tom Lane wrote: >> Andrew Dunstan writes: >>> We should probably specify -bext='/', which would cause the backup files >>> to be deleted unless an error occurred. >> Really? That seems a bit magic, and

[HACKERS] Let's get rid of the separate minor version numbers for shlibs

After doing the tedious and easily forgotten (I almost did forget) minor version bumps for our shared libraries, https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0b9358d4406b9b45a06855d53f491cc7ce9550a9 it suddenly struck me that in the brave new two-part-version-number world we

[HACKERS] PATCH: Exclude additional directories in pg_basebackup

Recently a hacker proposed a patch to add pg_dynshmem to the list of directories whose contents are excluded in pg_basebackup. I wasn't able to find the original email despite several attempts. That patch got me thinking about what else could be excluded and after some investigation I found the

[HACKERS] Anyone want to update our Windows timezone map?

src/timezone/README saith When there has been a new release of Windows (probably including Service Packs), the list of matching timezones need to be updated. Run the script in src/tools/win32tzlist.pl on a Windows machine running this new release and apply any new timezones that it

Re: [HACKERS] Slowness of extended protocol

> > I'm not going to respond to the part about dealing with prepared >> statements errors, since I think we've already covered that and there's >> nothing new being said. I don't find automatic savepointing acceptable, and >> a significant change of the PostgreSQL protocol to support this doesn't

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

On 08/15/2016 02:23 PM, Tom Lane wrote: Andrew Dunstan writes: On 08/15/2016 10:19 AM, Tom Lane wrote: Andrew Dunstan writes: We should probably specify -bext='/', which would cause the backup files to be deleted unless an error occurred. Really?

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On 07/10/2016 10:56 AM, Joshua D. Drake wrote: > Hackers, > > This just came across my twitter feed: > > https://lists.freedesktop.org/archives/systemd-devel/2014-April/018373.html > > tl;dr; Systemd 212 defaults to remove all IPC (including SYSV memory) > when a user "fully" logs out. That

Re: [HACKERS] multivariate statistics (v19)

On 08/10/2016 06:41 AM, Michael Paquier wrote: On Wed, Aug 3, 2016 at 10:58 AM, Tomas Vondra wrote: 1) enriching the query tree with multivariate statistics info Right now all the stuff related to multivariate statistics estimation happens in clausesel.c -

Re: [HACKERS] PATCH: Exclude additional directories in pg_basebackup

On 8/15/16 2:39 PM, David Steele wrote: That patch got me thinking about what else could be excluded and after some investigation I found the following: pg_notify, pg_serial, pg_snapshots, pg_subtrans. These directories are all cleaned, zeroed, or rebuilt on server start. If someone wanted to

Re: [HACKERS] PATCH: Exclude additional directories in pg_basebackup

On 8/15/16 4:58 PM, Jim Nasby wrote: On 8/15/16 2:39 PM, David Steele wrote: That patch got me thinking about what else could be excluded and after some investigation I found the following: pg_notify, pg_serial, pg_snapshots, pg_subtrans. These directories are all cleaned, zeroed, or rebuilt

Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 8/15/16 3:06 PM, Tom Lane wrote: > > That would give us an automatic annual change in the minor version. > > If we ever made an incompatible change in a shlib, we could advance > > its SO_MAJOR_VERSION but keep this rule for

Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs

On 8/15/16 3:06 PM, Tom Lane wrote: > That would give us an automatic annual change in the minor version. > If we ever made an incompatible change in a shlib, we could advance > its SO_MAJOR_VERSION but keep this rule for the minor version (there's > no law that says we have to reset the minor

Re: [HACKERS] New version numbering practices

I wrote: > I've pushed this with minor additional twiddling. We can work on the > "UI issues" you mentioned at leisure. One that I noted is that psql's > version-mismatch-warning messages aren't two-part-version aware, and > will print "10.0" where they should say "10". Probably that fix should

Re: [HACKERS] PATCH: Exclude additional directories in pg_basebackup

David, * David Steele (da...@pgmasters.net) wrote: > Recently a hacker proposed a patch to add pg_dynshmem to the list of > directories whose contents are excluded in pg_basebackup. I wasn't able > to find the original email despite several attempts. That would be here:

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Tue, Aug 16, 2016 at 7:19 AM, Tom Lane wrote: > src/timezone/README saith > > When there has been a new release of Windows (probably including Service > Packs), the list of matching timezones need to be updated. Run the > script in src/tools/win32tzlist.pl on a

Re: [HACKERS] Anyone want to update our Windows timezone map?

Thomas Munro writes: > On Tue, Aug 16, 2016 at 7:19 AM, Tom Lane wrote: >> We have certainly not been doing that on a regular basis (as best I can >> tell, no such changes have been made since 2010). Does anybody who uses >> Windows want to

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Tue, Aug 16, 2016 at 4:19 AM, Tom Lane wrote: > We have certainly not been doing that on a regular basis (as best I can > tell, no such changes have been made since 2010). Does anybody who uses > Windows want to deal with it? Or at least do it once so that our Windows >

Re: [HACKERS] max_parallel_degree > 0 for 9.6 beta

On Sat, Aug 13, 2016 at 11:56 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> Being cautious pays more in the long term, so seeing the number of >> bugs that showed up I'd rather vote for having it disabled by default >> in 9.6 stable, and enabled on master to

Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs

On 8/15/16 5:11 PM, Stephen Frost wrote: > Eh? Last I checked, we needed minor version bumps to ensure that > binaries compiled against later versions, which might use newer symbols, > don't try to link against older libraries (which wouldn't have those > symbols). Let's review: What we install

Re: [HACKERS] Logical Replication WIP

On 15/08/16 15:51, Stas Kelvich wrote: On 11 Aug 2016, at 17:43, Petr Jelinek wrote: * Also I wasn’t able actually to run replication itself =) While regression tests passes, TAP tests and manual run stuck. pg_subscription_rel.substate never becomes ‘r’. I’ll

Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs

Peter Eisentraut writes: > On 8/15/16 5:11 PM, Stephen Frost wrote: >> Eh? Last I checked, we needed minor version bumps to ensure that >> binaries compiled against later versions, which might use newer symbols, >> don't try to link against older libraries

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On 08/15/2016 02:43 PM, Tom Lane wrote: > Josh Berkus writes: >> On 07/10/2016 10:56 AM, Joshua D. Drake wrote: >>> tl;dr; Systemd 212 defaults to remove all IPC (including SYSV memory) >>> when a user "fully" logs out. > >> That looks like it was under discussion in April,

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

On Mon, Aug 15, 2016 at 11:19 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 08/14/2016 04:38 PM, Tom Lane wrote: >>> I did a trial run following the current pgindent README procedure, and >>> noticed that the perltidy step left me with a pile of

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

Josh Berkus writes: > On 08/15/2016 02:43 PM, Tom Lane wrote: >> Last I heard, there's an exclusion for "system" accounts, so an >> installation that's using the Fedora-provided pgsql account isn't >> going to have a problem. It's homebrew installs running under >>

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On 08/15/2016 05:18 PM, Tom Lane wrote: > Josh Berkus writes: >> On 08/15/2016 02:43 PM, Tom Lane wrote: >>> Last I heard, there's an exclusion for "system" accounts, so an >>> installation that's using the Fedora-provided pgsql account isn't >>> going to have a problem. It's

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

Michael Paquier writes: > The tree does not have any .bak file, and those refer to backup copies > normally. Perhaps it would make sense to include those in root's > .gitignore? That would save from an unfortunate manipulation of git > add in the future. We've

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

Josh Berkus writes: > On 07/10/2016 10:56 AM, Joshua D. Drake wrote: >> tl;dr; Systemd 212 defaults to remove all IPC (including SYSV memory) >> when a user "fully" logs out. > That looks like it was under discussion in April, though. Do we have > confirmation it was never

[HACKERS] Index Onlys Scan for expressions

Hi, hackers! There is a known issue that index only scan (IOS) can only work with simple index keys based on single attributes and doesn't work with index expressions. In this patch I propose a solution that adds support of IOS for index expressions. Here's an example: create table abc(a

Re: [HACKERS] LWLocks in DSM memory

On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas wrote: > Therefore, I plan to commit this patch, removing the #include > unless someone convinces me we need it, shortly after > development for v10 opens, unless there are objections before then. Hearing no objections, done.

Re: [HACKERS] Index Onlys Scan for expressions

On 08/16/2016 12:03 AM, Ildar Musin wrote: Hi, hackers! There is a known issue that index only scan (IOS) can only work with simple index keys based on single attributes and doesn't work with index expressions. In this patch I propose a solution that adds support of IOS for index expressions.

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

Josh Berkus writes: > On 08/15/2016 05:18 PM, Tom Lane wrote: >> Well, yeah, it's easy to fix once you know you need to do so. The >> complaint is basically that out-of-the-box, it's broken, and it's >> not very clear what was gained by breaking it. > You're welcome to argue

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Aug 3, 2016 at 2:13 PM, Peter Geoghegan wrote: > Since merging is a big bottleneck with this, we should probably also > work to address that indirectly. I attach a patch that changes how we maintain the heap invariant during tuplesort merging. I already mentioned this

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

On Mon, Aug 15, 2016 at 12:12 AM, Ryan Murphy wrote: > This is to fix an issue that came up for me when running initdb. > > At the end of a successful initdb it says: > > Success. You can now start the database server using: > pg_ctl -D /some/path/to/data -l

Re: [HACKERS] max_parallel_degree > 0 for 9.6 beta

Robert Haas writes: > On Sat, Aug 13, 2016 at 11:56 AM, Alvaro Herrera > wrote: >> I too prefer to keep it turned off in 9.6 and consider enabling it by >> default on a future release (10 is probably good). Interested users can >> carefully test

Re: [HACKERS] max_parallel_degree > 0 for 9.6 beta

On Mon, Aug 15, 2016 at 9:10 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, Aug 13, 2016 at 11:56 AM, Alvaro Herrera >> wrote: >>> I too prefer to keep it turned off in 9.6 and consider enabling it by >>> default on a

[HACKERS] anyelement -> anyrange

Any reason why we can create a function that accepts anyelement and returns anyarray, but can't do the same with anyrange? Could we attempt to match each range subtype looking for a match? create function range__create(anyelement,anyelement,text = '[]') RETURNS anyrange LANGUAGE plpgsql AS

Re: [HACKERS] anyelement -> anyrange

Jim Nasby writes: > Any reason why we can create a function that accepts anyelement and > returns anyarray, but can't do the same with anyrange? Because there can be more than one range type over the same element type, so we couldn't deduce which one should be used for

Re: [HACKERS] patch proposal

On Tue, Aug 16, 2016 at 2:50 AM, David Steele wrote: > On 8/15/16 2:33 AM, Venkata B Nagothi wrote: > > > During the recovery process, It would be nice if PostgreSQL generates an > > error by aborting the recovery process (instead of starting-up the > > cluster) if the

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

On 16/08/16 16:19, Andrew Dunstan wrote: On 08/15/2016 02:23 PM, Tom Lane wrote: Andrew Dunstan writes: On 08/15/2016 10:19 AM, Tom Lane wrote: Andrew Dunstan writes: We should probably specify -bext='/', which would cause the backup files to be