Re: [HACKERS] Free indexed_tlist memory explicitly within set_plan_refs()

2015-05-24 Thread Michael Paquier
On Mon, May 25, 2015 at 10:17 AM, Peter Geoghegan wrote: > While trying to fix a largely unrelated bug, I noticed that the new > build_tlist_index() call for the "excluded" targetlist (used by ON > CONFLICT DO UPDATE queries) does not have its memory subsequently > freed by the caller. Since every

Re: [HACKERS] Run pgindent now?

2015-05-24 Thread Bruce Momjian
On Sun, May 24, 2015 at 10:44:10AM -0400, Tom Lane wrote: > Andrew Dunstan writes: > > On 05/23/2015 11:37 PM, Tom Lane wrote: > >> No, pgindent has *always* been wonky about lines that contain a typedef > >> name but are not variable declarations. > > > Well, that sounds like something we should

Re: [HACKERS] Run pgindent now?

2015-05-24 Thread Bruce Momjian
On Sun, May 24, 2015 at 08:31:32AM -0400, Bruce Momjian wrote: > > >> Also, does somebody have an idea to keep pgindent from butchering inline > > >> asm like: > > > > > Ah, we have a file /pgtop/src/tools/pgindent/exclude_file_patterns which > > > has excluded files, and s_lock.h is one of them.

[HACKERS] Free indexed_tlist memory explicitly within set_plan_refs()

2015-05-24 Thread Peter Geoghegan
While trying to fix a largely unrelated bug, I noticed that the new build_tlist_index() call for the "excluded" targetlist (used by ON CONFLICT DO UPDATE queries) does not have its memory subsequently freed by the caller. Since every other call to build_tlist_index() does this, and comments above b

Re: [HACKERS] problems on Solaris

2015-05-24 Thread Andres Freund
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... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] problems on Solaris

2015-05-24 Thread Andrew Dunstan
On 05/24/2015 08:07 PM, Andres Freund wrote: On 2015-05-24 19:44:37 -0400, Andrew Dunstan wrote: Buildfarm members casteroides and protosciurus have been having some problems that seem puzzling. These animals both run on the same machine, but with different compilers. casteroides runs with the

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

2015-05-24 Thread Peter Geoghegan
On Sun, May 24, 2015 at 5:16 PM, Peter Geoghegan wrote: > AddForeignUpdateTargets() actually won't be called with ON CONFLICT DO > UPDATE, and so it isn't exactly true that the only obstacle to making > FDWs support ON CONFLICT DO UPDATE is around inference of arbiter > unique indexes on the forei

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

2015-05-24 Thread Peter Geoghegan
On Sun, May 24, 2015 at 4:22 PM, Peter Geoghegan wrote: > As things stand, every other possible ON CONFLICT clause will throw an > error in some way before the FDW is consulted at all, so FDW authors > need not concern themselves with those other cases (unless perhaps we > allow ON CONFLICT DO UPD

Re: [HACKERS] problems on Solaris

2015-05-24 Thread Andres Freund
On 2015-05-24 19:44:37 -0400, Andrew Dunstan wrote: > > Buildfarm members casteroides and protosciurus have been having some > problems that seem puzzling. These animals both run on the same machine, but > with different compilers. > > casteroides runs with the Sun Studio 12 compiler, and has twi

[HACKERS] problems on Solaris

2015-05-24 Thread Andrew Dunstan
Buildfarm members casteroides and protosciurus have been having some problems that seem puzzling. These animals both run on the same machine, but with different compilers. casteroides runs with the Sun Studio 12 compiler, and has twice in the last 3 days demonstrated this error: [5561ce

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

2015-05-24 Thread Peter Geoghegan
postgres_fdw supports ON CONFLICT DO NOTHING, provided no inference specification is provided. Foreign tables do not have associated unique indexes (or exclusion constraints) as far as the optimizer is concerned, and so Postgres does not accept an inference specification for foreign tables -- the o

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

2015-05-24 Thread Andrew Dunstan
On 05/24/2015 05:38 PM, Tom Lane wrote: Andres Freund writes: On 2015-05-24 12:17:35 -0700, Peter Geoghegan wrote: Having gone to the trouble of making the parser support this stuff (in a way that makes us not follow the SQL standard in a couple of places), we ought to have a similar capabili

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

2015-05-24 Thread Tom Lane
Andres Freund writes: > On 2015-05-24 12:17:35 -0700, Peter Geoghegan wrote: >> Having gone to the trouble of making the parser support this stuff (in >> a way that makes us not follow the SQL standard in a couple of >> places), we ought to have a similar capability for jsonb. I haven't >> looked

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

2015-05-24 Thread Andres Freund
On 2015-05-24 12:17:35 -0700, Peter Geoghegan wrote: > Having gone to the trouble of making the parser support this stuff (in > a way that makes us not follow the SQL standard in a couple of > places), we ought to have a similar capability for jsonb. I haven't > looked into it, but it seems like a

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

2015-05-24 Thread Andrew Dunstan
On 05/24/2015 03:17 PM, Peter Geoghegan wrote: On Thu, May 21, 2015 at 2:25 PM, Andrew Dunstan wrote: This change really makes this set of jsonb features quite a bit more compelling. I'm glad I thought of it - wish I had done so earlier. So notwithstanding the controversy upthread, I think thi

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

2015-05-24 Thread Peter Geoghegan
On Thu, May 21, 2015 at 2:25 PM, Andrew Dunstan wrote: > This change really makes this set of jsonb features quite a bit more > compelling. I'm glad I thought of it - wish I had done so earlier. So > notwithstanding the controversy upthread, I think this is a good result. I think that we should l

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

2015-05-24 Thread Tom Lane
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 >>> differentiated logic for the toplevel data directory? > pg_

Re: [HACKERS] Run pgindent now?

2015-05-24 Thread Tom Lane
Andrew Dunstan writes: > On 05/23/2015 11:37 PM, Tom Lane wrote: >> No, pgindent has *always* been wonky about lines that contain a typedef >> name but are not variable declarations. > Well, that sounds like something we should try to patch, doesn't it? > (No, I'm not volunteering.) In the past

Re: [HACKERS] Run pgindent now?

2015-05-24 Thread Andrew Dunstan
On 05/23/2015 11:37 PM, Tom Lane wrote: Bruce Momjian writes: On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote: - if (IsA(node, Aggref) || IsA(node, GroupingFunc)) + if (IsA(node, Aggref) ||IsA(node, GroupingFunc)) There's a bunch of changes like this. Looks rather odd to me

Re: [HACKERS] Run pgindent now?

2015-05-24 Thread Bruce Momjian
On Sat, May 23, 2015 at 11:37:30PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote: > >> - if (IsA(node, Aggref) || IsA(node, GroupingFunc)) > >> + if (IsA(node, Aggref) ||IsA(node, GroupingFunc)) > >> > >> There's a bunch of ch

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

2015-05-24 Thread Nils Goroll
Hi Jeff and all, On 23/05/15 22:13, Jeff Janes wrote: > Are you sure it is the read IO that causes the problem? Yes. Trouble is here that we are talking about a 361 GB table List of relations Schema |Name | Type | Owner |Size

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

2015-05-24 Thread Christoph Berg
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 > > differentiated logic for the toplevel data directory? I think we could > > just skip al

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

2015-05-24 Thread Christoph Berg
Re: Andres Freund 2015-05-24 <20150524005245.gd32...@alap3.anarazel.de> > How about, to avoid masking actual problems, we have a more > differentiated logic for the toplevel data directory? I think we could > just skip all non-directory files in there data_directory itself. None > of the files in t