Re: [HACKERS] [PATCH] Generalized JSON output functions

On Sat, May 23, 2015 at 3:03 AM, Ryan Pedela wrote: > On Fri, May 22, 2015 at 10:51 AM, Merlin Moncure > wrote: > >> On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera >> wrote: >> > Andrew Dunstan wrote: >> >> >> >> On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote: >> > >> >> >Attached is a patch

[HACKERS] [Postgresql NLS support] : Help on using NLS , Custom dictionary to enhance our website search functionality

Hi All, We have newbie to Postgresql. Background: We have site hosted on Ruby on Rails using Postgresql database.It is a eCommerce site and for which we need to provide the NLS supported Search functionality to help end users while searching by using Synonyms, related word , Plurals and Singular

Re: [HACKERS] Supporting TAP tests with MSVC and Windows

On Fri, Apr 24, 2015 at 11:26 AM, Michael Paquier wrote: > On Mon, Apr 20, 2015 at 9:01 PM, Michael Paquier > wrote: >> On Sun, Apr 19, 2015 at 10:01 PM, Michael Paquier >> wrote: >>> Note as well that this patch uses the following patches fixing >>> independent issues: >>> ... >> >> Attached is

Re: [HACKERS] fsync bug faq for publication?

On May 26, 2015 07:31, "Tom Lane" wrote: > > Josh Berkus writes: > > We need to get a notice out to our users who might update their servers > > and get stuck behind the fsync bug. As such, I've prepared a FAQ. > > Please read, correct and improve this FAQ so that it's fit for us to > > announce

Re: [HACKERS] fsync bug faq for publication?

Josh Berkus writes: > We need to get a notice out to our users who might update their servers > and get stuck behind the fsync bug. As such, I've prepared a FAQ. > Please read, correct and improve this FAQ so that it's fit for us to > announce to users as soon as possible: > https://wiki.postgre

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

At 2015-05-26 03:54:51 +0200, and...@anarazel.de wrote: > > Say a symlink goes to a binary, which is currently being executed: > ETXTBSY. Or the file is in a readonly filesystem: EROFS. So we'd > need to ignore a lot of errors, possibly ignoring valid ones. Right. That's why I started out by bein

[HACKERS] fsync bug faq for publication?

Hackers, We need to get a notice out to our users who might update their servers and get stuck behind the fsync bug. As such, I've prepared a FAQ. Please read, correct and improve this FAQ so that it's fit for us to announce to users as soon as possible: https://wiki.postgresql.org/wiki/May_2015

Re: [HACKERS] Missing importing option of postgres_fdw

On 2015/05/26 3:15, Tom Lane wrote: Etsuro Fujita writes: On 2015/05/22 23:50, Tom Lane wrote: So I think worrying about convalidated is pretty pointless. Really, it is up to the user to determine what constraints should be attached to the foreign table, and IMPORT FOREIGN SCHEMA can't help m

Re: [HACKERS] anole: assorted stability problems

On 2015-05-20 16:21:57 -0300, Alvaro Herrera wrote: > In HEAD only. Previous branches seem mostly clean, so there's something > going wrong. Spinlocks going wrong perhaps? > > http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anole&dt=2015-05-20%2016%3A30%3A26&stg=check > ! PANIC: stu

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Tue, May 26, 2015 at 12:10 AM, Andres Freund wrote: > > On 2015-05-20 19:56:39 +0530, Amit Kapila wrote: > > I have done some tests with this patch to see the benefit with > > and it seems to me this patch helps in reducing the contention > > around ProcArrayLock, though the increase in TPS (in

Re: [HACKERS] brin regression test intermittent failures

I wrote: > Peter Geoghegan writes: >> I meant to get around to looking into it, but FWIW I see BRIN-related >> Valgrind issues. e.g.: > Fixed, see 79f2b5d583e2e2a7; but AFAICS this has no real-world impact > so it does not explain whatever is happening on chipmunk. BTW, after some further trawli

Re: [HACKERS] Asynchronous DRAM Self-Refresh

On 05/23/2015 10:49 AM, Jeremy Harris wrote: > On 22/05/15 22:30, Josh Berkus wrote: >> At CoreOS Fest, Intel presented about a technology which they used to >> improve write times for the nonrelational data store Etcd. It's called >> Asynchronous DRAM Self-Refresh, or ADR. This is supposedly a f

Re: [HACKERS] problems on Solaris

On 2015-05-25 09:12:35 +0200, Stefan Kaltenbrunner wrote: > On 05/25/2015 03:17 AM, Andres Freund wrote: > > On 2015-05-24 21:01:54 -0400, Andrew Dunstan wrote: > >> Yes, but it wasn't running these tests until a few days ago when its > >> buildfarm software was upgraded. > > > > But barriers are

Re: [HACKERS] Run pgindent now?

Bruce Momjian writes: > On Tue, May 26, 2015 at 01:15:17AM +0200, Andres Freund wrote: >> Maybe I'm missing something major here, but why? Afaict it's just only >> used for formatting decisions that could be made without it just as well? > Uh, well, formatting decisions is what pgindent does. It

Re: [HACKERS] brin regression test intermittent failures

Peter Geoghegan writes: > I meant to get around to looking into it, but FWIW I see BRIN-related > Valgrind issues. e.g.: Fixed, see 79f2b5d583e2e2a7; but AFAICS this has no real-world impact so it does not explain whatever is happening on chipmunk. regards, tom lane --

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 2015-05-25 21:33:03 -0400, Robert Haas wrote: > On Mon, May 25, 2015 at 2:20 PM, Tom Lane wrote: > > Perhaps, but if we didn't have permission to write the file, it's hard to > > argue that it's our responsibility to fsync it. So this seems like it's > > adding complexity without really adding

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, May 25, 2015 at 2:20 PM, Tom Lane wrote: >> Andres Freund writes: >>> On 2015-05-25 14:14:10 -0400, Stephen Frost wrote: Not really sure I see that as helping. >>> On most OSs, except windows and some obscure unixes, a readonly

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On Mon, May 25, 2015 at 2:20 PM, Tom Lane wrote: > Andres Freund writes: >> On 2015-05-25 14:14:10 -0400, Stephen Frost wrote: Additionally we could attempt to fsync with a readonly fd before trying the read-write fd... > >>> Not really sure I see that as helping. > >> On most OSs, exce

Re: [HACKERS] Update README.tuplock?

On 2015-05-26 AM 03:12, Alvaro Herrera wrote: > Alvaro Herrera wrote: >> Jim Nasby wrote: >>> On 5/25/15 4:38 AM, Amit Langote wrote: Commit f741300c90141ee274f19a13629ae03a9806b598 ("Have multixact be truncated by checkpoint, not vacuum") changed who truncates multixact. README.tup

Re: [HACKERS] Run pgindent now?

On Tue, May 26, 2015 at 01:15:17AM +0200, Andres Freund wrote: > On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote: > > > A longer-term fix would be to make pgindent less stupid about this sort > > > of usage, but nobody's yet volunteered to dig into the guts of that code. > > > > I assume a typed

Re: [HACKERS] Run pgindent now?

On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote: > > A longer-term fix would be to make pgindent less stupid about this sort > > of usage, but nobody's yet volunteered to dig into the guts of that code. > > I assume a typedefs list is going to be a requirement of any decent C > indenting tool.

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 05:34:12PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote: > >> Something is wrong. See aclchk.c changes. > > > Yes, this is what I was concerned about. "aclitem" was a typedef in 9.0 > > and 9.1, and the

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 06:48:47PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote: > > > Bruce Momjian wrote: > > > > > > > OK, makes sense. You can see the old and 'all' diffs here: > > > > > > > > http://momjian.us

Re: [HACKERS] brin regression test intermittent failures

On Mon, May 25, 2015 at 3:25 PM, Tom Lane wrote: > Also worth noting is that there's a completely different failure symptom > that's shown up a few times, eg here: > > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk&dt=2015-05-25%2009%3A56%3A55 > > This makes it look like brintest

Re: [HACKERS] Run pgindent now?

Alvaro Herrera writes: > Tom Lane wrote: >> A longer-term fix would be to make pgindent less stupid about this sort >> of usage, but nobody's yet volunteered to dig into the guts of that code. > We've discussed in the past that we could use something other than BSD's > indent -- astyle has been m

Re: [HACKERS] brin regression test intermittent failures

Andrew Dunstan writes: > There's something odd about the brin regression tests. They seem to > generate intermittent failures, which suggests some sort of race > condition or ordering failure. > See for example >

Re: [HACKERS] Run pgindent now?

Tom Lane wrote: > A longer-term fix would be to make pgindent less stupid about this sort > of usage, but nobody's yet volunteered to dig into the guts of that code. We've discussed in the past that we could use something other than BSD's indent -- astyle has been mentioned. It seems that with s

Re: [HACKERS] Run pgindent now?

Bruce Momjian wrote: > On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > > > OK, makes sense. You can see the old and 'all' diffs here: > > > > > > http://momjian.us/expire/ > > > > Something is wrong. See aclchk.c changes. > > Yes, this is what

Re: [HACKERS] Buggy logic in nodeIndexscan.c queue handling

On 05/25/2015 06:35 PM, Tom Lane wrote: When deciding whether to pop entries from the queue (line 191), the comparison is done against scandesc->xs_orderbyvals, which as the comment states are the last values physically returned by the index. I think this is wrong, or at least pretty inefficient

Re: [HACKERS] Run pgindent now?

Bruce Momjian writes: > On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote: >> Something is wrong. See aclchk.c changes. > Yes, this is what I was concerned about. "aclitem" was a typedef in 9.0 > and 9.1, and the use of that as a typedef in 9.4 is certainly odd: > - ac

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > > OK, makes sense. You can see the old and 'all' diffs here: > > > > http://momjian.us/expire/ > > Something is wrong. See aclchk.c changes. Yes, this is what I was concerned about. "aclitem" was a

Re: [HACKERS] [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

On 2015-05-25 14:11:34 -0700, Josh Berkus wrote: > If it's any consolation, the folks at kernel.org are having a bad week > too: http://lwn.net/Articles/645720/ This doesn't seem to come even close to their problems ;). A problem that you can fix by making permissions isn't that bad. Greetings,

Re: [HACKERS] [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

All, If it's any consolation, the folks at kernel.org are having a bad week too: http://lwn.net/Articles/645720/ -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.p

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 05/25/2015 01:21 PM, Tom Lane wrote: > And from the other direction, where exactly is it written that > distros/users will only create problematic files at the top level of > $PGDATA? I'd have zero confidence in such an assertion applied to > tablespace directories, for sure. Yes, absolutely.

Re: [HACKERS] [Pgbuildfarm] buildfarm olinguito vs python

"Davin M. Potts" writes: > At Alvaro's suggestion, I'm forwarding my questions (see email thread > further below) to this list. > In short, building of PL/Python has been disabled on OpenBSD since 2005. > The errors seen at the time (on OpenBSD and FreeBSD, both) may or may > not still be an issu

Re: [HACKERS] [Pgbuildfarm] buildfarm olinguito vs python

On 05/25/2015 03:35 PM, Andrew Dunstan wrote: On 05/25/2015 12:38 PM, Davin M. Potts wrote: At Alvaro's suggestion, I'm forwarding my questions (see email thread further below) to this list. In short, building of PL/Python has been disabled on OpenBSD since 2005. The errors seen at the time (

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Alvaro Herrera writes: > Tom Lane wrote: >> Well, that opens us to errors of omission, ie failing to fsync things we >> should have. Maybe that's an okay risk, but personally I'd judge that >> "fsync everything and ignore (some?) errors" is probably a more robust >> approach over time. > How is

Re: [HACKERS] Run pgindent now?

Bruce Momjian wrote: > One issue I discussed is doing a pgindent-only release so users doing a > diff would not have pgindent diffs mixed with fixes. I doubt anyone is reading hand-generated diffs these days. Those that want to read diffs are much better served by looking at the git repo directl

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Tom Lane wrote: > Stephen Frost writes: > > I've not followed this thread all that closely, but I do tend to agree > > with the idea of "only try to mess with files that are *clearly* ours to > > mess with." > > Well, that opens us to errors of omission, ie failing to fsync things we > should hav

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Andres Freund writes: > On 2015-05-25 14:14:10 -0400, Stephen Frost wrote: >>> Additionally we could attempt to fsync with a readonly fd before trying >>> the read-write fd... >> Not really sure I see that as helping. > On most OSs, except windows and some obscure unixes, a readonly fd is > allo

Re: [HACKERS] [Pgbuildfarm] buildfarm olinguito vs python

At Alvaro's suggestion, I'm forwarding my questions (see email thread further below) to this list. In short, building of PL/Python has been disabled on OpenBSD since 2005. The errors seen at the time (on OpenBSD and FreeBSD, both) may or may not still be an issue with modern builds of Python. Can

Re: [HACKERS] Run pgindent now?

Bruce Momjian writes: > On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote: >> As we discussed upthread, if we're trying to minimize cross-branch >> pgindent differences then we probably need to use the same typedefs >> list in all branches. I believe Andrew's already set up buildfarm >> su

Re: [HACKERS] Run pgindent now?

Bruce Momjian writes: > On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote: >> Some of those diffs would disappear if you'd used an up-to-date typedefs >> list ... not a lot, but some. > Uh, you mean a current 9.4.X typedef list? Should I try that? As we discussed upthread, if we're tryin

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Here is a re-run of pgindent on 9.4: > > http://momjian.us/expire/pgindent-9.4.diff > > Some of those diffs would disappear if you'd used an up-to-date typedefs > list ... not a lot, but some. Uh, you mean

[HACKERS] about lob(idea)

Maybe it makes sense to add ability to store large objects in the same table space as the table. Or an opportunity - to specify table space for a large object. Do you have anything in todolists about it? Thank's. PS it feature is  real  need -- Alex S

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On 2015-05-20 19:56:39 +0530, Amit Kapila wrote: > I have done some tests with this patch to see the benefit with > and it seems to me this patch helps in reducing the contention > around ProcArrayLock, though the increase in TPS (in tpc-b tests > is around 2~4%) is not very high. > > pgbench (TPC

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 2015-05-25 14:02:28 -0400, Tom Lane wrote: > Stephen Frost writes: > > I've not followed this thread all that closely, but I do tend to agree > > with the idea of "only try to mess with files that are *clearly* ours to > > mess with." > > Well, that opens us to errors of omission, ie failing to

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

* Andres Freund (and...@anarazel.de) wrote: > On 2015-05-25 14:14:10 -0400, Stephen Frost wrote: > > That seems overly complicated, for my 2c at least. I don't particularly > > like trying to mess with files that might be rightfully considered "not > > ours" either. > > I'd not consider an fsync

Re: [HACKERS] Update README.tuplock?

Alvaro Herrera wrote: > Jim Nasby wrote: > > On 5/25/15 4:38 AM, Amit Langote wrote: > > >Commit f741300c90141ee274f19a13629ae03a9806b598 ("Have multixact be > > >truncated > > >by checkpoint, not vacuum") changed who truncates multixact. README.tuplock > > >still says VACUUM is in charge of the t

Re: [HACKERS] Run pgindent now?

Tom Lane wrote: > Alvaro Herrera writes: > > FWIW the multixact code is now slightly different between HEAD and > > 9.3/9.4, also. So if that needs further patches, they will be fun to > > backpatch. > > Well, sure, intentional cross-branch changes are always a hazard. > But pgindent diffs are a

Re: [HACKERS] Run pgindent now?

Bruce Momjian wrote: > OK, makes sense. You can see the old and 'all' diffs here: > > http://momjian.us/expire/ Something is wrong. See aclchk.c changes. Also, sometime ago we changed pgindent rules so that dot-space-space is not turned into dot-tab in comments anymore, and many places

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

* Andres Freund (and...@anarazel.de) wrote: > On 2015-05-25 14:02:28 -0400, Tom Lane wrote: > > Stephen Frost writes: > > > I've not followed this thread all that closely, but I do tend to agree > > > with the idea of "only try to mess with files that are *clearly* ours to > > > mess with." > > >

Re: [HACKERS] Run pgindent now?

On 2015-05-25 14:55:54 -0400, Bruce Momjian wrote: > One issue I discussed is doing a pgindent-only release so users doing a > diff would not have pgindent diffs mixed with fixes. I find a pgindent only release a pretty pointless goal. That's what git is for. -- Sent via pgsql-hackers mailing l

Re: [HACKERS] Run pgindent now?

Alvaro Herrera writes: > FWIW the multixact code is now slightly different between HEAD and > 9.3/9.4, also. So if that needs further patches, they will be fun to > backpatch. Well, sure, intentional cross-branch changes are always a hazard. But pgindent diffs are a hazard that we could mechanic

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 12:49:41PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > If we wanted to do this on backbranches, I think we would create a diff > > file of the minor release just before running pgindent and stamping so > > users could see the non-pgindent content of the release. > >

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Stephen Frost writes: > I've not followed this thread all that closely, but I do tend to agree > with the idea of "only try to mess with files that are *clearly* ours to > mess with." Well, that opens us to errors of omission, ie failing to fsync things we should have. Maybe that's an okay risk,

Re: [HACKERS] [Pgbuildfarm] buildfarm olinguito vs python

Davin M. Potts wrote: > At Alvaro's suggestion, I'm forwarding my questions (see email thread > further below) to this list. > > In short, building of PL/Python has been disabled on OpenBSD since 2005. > The errors seen at the time (on OpenBSD and FreeBSD, both) may or may > not still be an issue

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 2015-05-25 14:14:10 -0400, Stephen Frost wrote: > That seems overly complicated, for my 2c at least. I don't particularly > like trying to mess with files that might be rightfully considered "not > ours" either. I'd not consider an fsync to be "messing" with files, especially if they're in PGD

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 01:28:16PM -0400, Tom Lane wrote: > What we need to consider right now is whether to include back branches > in the existing practice of reindenting between development cycles. > This is somewhat urgent because we already did HEAD, so we have already > created a divergence f

Re: [HACKERS] Missing importing option of postgres_fdw

Etsuro Fujita writes: > On 2015/05/22 23:50, Tom Lane wrote: >> So I think worrying about convalidated is pretty pointless. Really, >> it is up to the user to determine what constraints should be attached >> to the foreign table, and IMPORT FOREIGN SCHEMA can't help much. > Agreed. So, I'd like

Re: [HACKERS] [Pgbuildfarm] buildfarm olinguito vs python

On 05/25/2015 12:38 PM, Davin M. Potts wrote: At Alvaro's suggestion, I'm forwarding my questions (see email thread further below) to this list. In short, building of PL/Python has been disabled on OpenBSD since 2005. The errors seen at the time (on OpenBSD and FreeBSD, both) may or may not sti

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 09:00:25PM +0200, Andres Freund wrote: > On 2015-05-25 14:55:54 -0400, Bruce Momjian wrote: > > One issue I discussed is doing a pgindent-only release so users doing a > > diff would not have pgindent diffs mixed with fixes. > > I find a pgindent only release a pretty point

Re: [HACKERS] Run pgindent now?

Bruce Momjian writes: > On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote: >> The point is for the back branches to absorb pgindent-induced changes that >> have already happened in HEAD, so I'm not sure what you're getting at. > My point is uses of new typedefs names added in HEAD which ar

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 03:20:47PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote: > >> The point is for the back branches to absorb pgindent-induced changes that > >> have already happened in HEAD, so I'm not sure what you're getting at

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote: > >> As we discussed upthread, if we're trying to minimize cross-branch > >> pgindent differences then we probably need to use the same typedefs > >> list

Re: [HACKERS] Run pgindent now?

On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote: > >> Some of those diffs would disappear if you'd used an up-to-date typedefs > >> list ... not a lot, but some. > > > Uh, you mean a current 9.4.X typed

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

* Andres Freund (and...@anarazel.de) wrote: > On 2015-05-25 13:38:01 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On May 24, 2015 7:52:53 AM PDT, Tom Lane wrote: > > > If we'd merge it with initdb's list I think I'd not be that bad. I'm > > > thinking of some header declaring it, rough

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 2015-05-25 13:38:01 -0400, Tom Lane wrote: > Andres Freund writes: > > On May 24, 2015 7:52:53 AM PDT, Tom Lane wrote: > > If we'd merge it with initdb's list I think I'd not be that bad. I'm > > thinking of some header declaring it, roughly like the rmgr list. > > pg_log/ is a counterexampl

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Andres Freund writes: > On May 24, 2015 7:52:53 AM PDT, Tom Lane wrote: >> Christoph Berg writes: >>> pg_log/ is also admin domain. What about only recursing into >>> well-known directories + postgresql.auto.conf? >> The idea that this code would know exactly what's what under $PGDATA >> scares

Re: [HACKERS] Run pgindent now?

Tom Lane wrote: > What we need to consider right now is whether to include back branches > in the existing practice of reindenting between development cycles. > This is somewhat urgent because we already did HEAD, so we have already > created a divergence from HEAD to 9.4 which is going to cause u

Re: [HACKERS] Run pgindent now?

Andres Freund writes: > On 2015-05-20 11:47:15 -0400, Robert Haas wrote: >> On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote: >>> To do it before every minor release would require re-indenting HEAD >>> as well (since the whole point is to keep HEAD and the back branches >>> consistent). I think

Re: [HACKERS] Update README.tuplock?

Jim Nasby wrote: > On 5/25/15 4:38 AM, Amit Langote wrote: > >Commit f741300c90141ee274f19a13629ae03a9806b598 ("Have multixact be truncated > >by checkpoint, not vacuum") changed who truncates multixact. README.tuplock > >still says VACUUM is in charge of the truncation. I think it's an oversight

Re: [HACKERS] Update README.tuplock?

On 5/25/15 4:38 AM, Amit Langote wrote: Commit f741300c90141ee274f19a13629ae03a9806b598 ("Have multixact be truncated by checkpoint, not vacuum") changed who truncates multixact. README.tuplock still says VACUUM is in charge of the truncation. I think it's an oversight in updating the README unle

Re: [HACKERS] xid wrap / optimize frozen tables?

On 5/24/15 6:42 AM, Nils Goroll wrote: shared_buffers = 325GB FWIW, a lot of people report performance loss with shared buffers that large. At a minimum, if you're going to set them that large then you want to make sure that the OS has a bare minimum of memory in use for it's disk ca

Re: [HACKERS] Run pgindent now?

* Andres Freund (and...@anarazel.de) wrote: > On 2015-05-20 11:47:15 -0400, Robert Haas wrote: > > On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote: > > > To do it before every minor release would require re-indenting HEAD > > > as well (since the whole point is to keep HEAD and the back branches

Re: [HACKERS] Run pgindent now?

On 2015-05-20 11:47:15 -0400, Robert Haas wrote: > On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote: > > To do it before every minor release would require re-indenting HEAD > > as well (since the whole point is to keep HEAD and the back branches > > consistent). I think we'd get too much push-bac

Re: [HACKERS] Run pgindent now?

Bruce Momjian writes: > Here is a re-run of pgindent on 9.4: > http://momjian.us/expire/pgindent-9.4.diff Some of those diffs would disappear if you'd used an up-to-date typedefs list ... not a lot, but some. That is rather a lot of diffs, but the thing I think people ought to take away fr

Re: [HACKERS] Run pgindent now?

Bruce Momjian writes: > If we wanted to do this on backbranches, I think we would create a diff > file of the minor release just before running pgindent and stamping so > users could see the non-pgindent content of the release. What for? Those who want to see that can look at our git repo. > A

Re: [HACKERS] WIP: Enhanced ALTER OPERATOR

Hello Hackers. I reworked the patch. Now, the syntax is similar to CREATE OPERATOR. And as I wrote earlier problems with the cache I have not found. If someone can suggest how it could be verified that would be happy. New syntax example: ALTER OPERATOR === (boolean, boolean) SET (COMMUTATOR = =)

Re: [HACKERS] Run pgindent now?

On Sat, May 23, 2015 at 12:32:34PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Are we ready for a pgindent run? Back branches? > > I think we could do it in HEAD, but it doesn't seem like we have consensus > about whether to touch the back branches. Suggest just HEAD for now and > we can

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On May 24, 2015 7:52:53 AM PDT, Tom Lane wrote: >Christoph Berg writes: >> Re: To Andres Freund 2015-05-24 <20150524075244.gb27...@msg.df7cb.de> >>> Re: Andres Freund 2015-05-24 ><20150524005245.gd32...@alap3.anarazel.de> How about, to avoid masking actual problems, we have a more diffe

Re: [HACKERS] [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

* Andres Freund (and...@anarazel.de) wrote: > On May 25, 2015 8:52:33 AM PDT, Bruce Momjian wrote: > >On Mon, May 25, 2015 at 04:37:59PM +0100, Greg Stark wrote: > >> What exactly is failing? > >> > >> Is it that fsync is returning -1 ? Should we just ignore errors from > >> fsync if it happens i

Re: [HACKERS] [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

Greg Stark writes: > What exactly is failing? > Is it that fsync is returning -1 ? According to the original report from Christoph Berg, it was open() not fsync() that was failing, at least in permissions-based cases. I'm not sure if we should just uniformly ignore all failures in this phase. T

Re: [HACKERS] [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

On May 25, 2015 8:52:33 AM PDT, Bruce Momjian wrote: >On Mon, May 25, 2015 at 04:37:59PM +0100, Greg Stark wrote: >> What exactly is failing? >> >> Is it that fsync is returning -1 ? Should we just ignore errors from >> fsync if it happens in this stage? That might be safer than >> determining wh

Re: [HACKERS] [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

On Mon, May 25, 2015 at 04:37:59PM +0100, Greg Stark wrote: > What exactly is failing? > > Is it that fsync is returning -1 ? Should we just ignore errors from > fsync if it happens in this stage? That might be safer than > determining which files should or shouldn't be fsynced. Interesting idea.

Re: [HACKERS] [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

What exactly is failing? Is it that fsync is returning -1 ? Should we just ignore errors from fsync if it happens in this stage? That might be safer than determining which files should or shouldn't be fsynced. That would also have an impact on people starting up on a flaky file system perhaps. I'

[HACKERS] Buggy logic in nodeIndexscan.c queue handling

When deciding whether to pop entries from the queue (line 191), the comparison is done against scandesc->xs_orderbyvals, which as the comment states are the last values physically returned by the index. I think this is wrong, or at least pretty inefficient, in the case that the last index tuple wa

[HACKERS] Re: [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

* Magnus Hagander (mag...@hagander.net) wrote: > On May 25, 2015 5:12 PM, "Stephen Frost" wrote: > > This was back-patched all the way and released with the latest round of > > minor releases, and given that it means crash recovery fails for a large > > number of deployed systems, I think we need

Re: [HACKERS] [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

On May 25, 2015 5:12 PM, "Stephen Frost" wrote: > > All, > > (sending to -core to request a release) > > * and...@tao11.riddles.org.uk (and...@tao11.riddles.org.uk) wrote: > > Operating system: Debian (and probably others) > > > The addition of a recursive fsync of the data dir on startup (in th

Re: [HACKERS] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

All, (sending to -core to request a release) * and...@tao11.riddles.org.uk (and...@tao11.riddles.org.uk) wrote: > Operating system: Debian (and probably others) > The addition of a recursive fsync of the data dir on startup (in the absence > of a clean shutdown) causes startup to fail if the d

Re: [HACKERS] Order of columns in query is important?!

On 2015-05-25 PM 06:26, Colin 't Hart wrote: > > It seems that the order of columns in a query can make a difference in > execution times. > > In my brief investigation, queries on table(a,b,c,d,e,f,g,h) of the form > > select * from table order by non-indexed-column limit 25; > select a,b,c,d,e

Re: [HACKERS] Missing importing option of postgres_fdw

On 2015/05/22 23:50, Tom Lane wrote: > Etsuro Fujita writes: >> I agree with you on that point. And I think one option for that is that >> IMPORT FOREIGN SCHEMA only imports CHECK constraints of remote tables >> from a remote server that have convalidated = true. (If doing so, we >> wouldn't nee

Re: [HACKERS] best place for "rtree" strategy numbers

Adjacent strategy number of range types don't match the central definitions. Attached patch changes it. Also, maybe it is better to include stratnum.h on rangetypes.h and inet.h rather than the .c files as the definitions are used in the headers. I wouldn't re-define them, anyway. Two definitio

[HACKERS] Update README.tuplock?

Hi, Commit f741300c90141ee274f19a13629ae03a9806b598 ("Have multixact be truncated by checkpoint, not vacuum") changed who truncates multixact. README.tuplock still says VACUUM is in charge of the truncation. I think it's an oversight in updating the README unless I am missing something. I attemp

Re: [HACKERS] Order of columns in query is important?!

PS I should have mentioned that it wasn't me that discovered this but "Evgeny" on dba.stackexchange He was reporting a much greater disparity in times. See http://dba.stackexchange.com/questions/102403/why-is-select-much-faster-than-selecting-all-columns-by-name Thanks, Colin -- Sent via pgs

[HACKERS] Order of columns in query is important?!

Hi, I hope this is the best place to report this or should I be on pgsql-general or pgsql-bugs? It seems that the order of columns in a query can make a difference in execution times. In my brief investigation, queries on table(a,b,c,d,e,f,g,h) of the form select * from table order by non-inde

[HACKERS] Construction of Plan-node by CSP (RE: Custom/Foreign-Join-APIs)

> -Original Message- > Sent: Friday, May 15, 2015 8:44 AM > To: 'Tom Lane'; Kohei KaiGai > Cc: Robert Haas; Thom Brown; Shigeru Hanada; pgsql-hackers@postgreSQL.org > Subject: RE: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API) > > > A possible compromise that we could perh

[HACKERS] Re: 9.5 release notes may need ON CONFLICT DO NOTHING compatibility notice for FDW authors

On 25 May 2015 at 00:22, Peter Geoghegan wrote: > > There is no support for ON CONFLICT DO UPDATE with postgres_fdw, but > that's really only because an inference specification (or explicitly > named constraint) is always required for DO UPDATE. The deparsing > support actually added will have de

Re: [HACKERS] problems on Solaris

On 05/25/2015 03:17 AM, Andres Freund wrote: > On 2015-05-24 21:01:54 -0400, Andrew Dunstan wrote: >> Yes, but it wasn't running these tests until a few days ago when its >> buildfarm software was upgraded. > > But barriers are used in other places too... fwiw: spoonbill just failed in the same p