Re: [HACKERS] initdb w/ restart

On 9/28/17 15:40, Jesper Pedersen wrote: > In a case of > > initdb /tmp/pgsql > > followed by > > pg_ctl -D /tmp/pgsql/ -l /tmp/logfile restart > > you'll get > > pg_ctl: PID file "/tmp/pgsql/postmaster.pid" does not exist > Is server running? > starting server anyway > pg_ctl: could not read

[HACKERS] initdb w/ restart

Hi, In a case of initdb /tmp/pgsql followed by pg_ctl -D /tmp/pgsql/ -l /tmp/logfile restart you'll get pg_ctl: PID file "/tmp/pgsql/postmaster.pid" does not exist Is server running? starting server anyway pg_ctl: could not read file "/tmp/pgsql/postmaster.opts" The attached patch changes t

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

Re: Tom Lane 2017-08-13 <14677.1502638...@sss.pgh.pa.us> > Christoph Berg writes: > > Seems to be a gcc-7 problem affecting several packages on mips64el: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514 > > Hm, unless there is a use of sigsetjmp earlier in that clamav > routine, I wou

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

Re: Tom Lane 2017-08-13 <14517.1502638...@sss.pgh.pa.us> > I suspect you could work around this with > > boolisCompleteQuery = (context <= PROCESS_UTILITY_QUERY); > - boolneedCleanup; > + volatile bool needCleanup; > boolcommandCollected =

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

Christoph Berg writes: > Seems to be a gcc-7 problem affecting several packages on mips64el: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514 Hm, unless there is a use of sigsetjmp earlier in that clamav routine, I would not assume that that's the same issue. The bug I suspect we are l

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

Christoph Berg writes: > 10beta3 and 9.6.4 are both failing during initdb on mips64el on > Debian/sid (unstable): > All other architectures have succeeded, as well as the 9.6.4 build for > Debian/stretch (stable) on mips64el. The difference might be the > compiler version (6.3.0 vs 7.1.0). It's h

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

Re: To PostgreSQL Hackers 2017-08-13 <20170813130127.g3tcyzzvuvlpz...@msg.df7cb.de> > 10beta3 and 9.6.4 are both failing during initdb on mips64el on > Debian/sid (unstable): > > https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6&arch=mips64el&ver=9.6.4-1&stamp=1502374949&raw=0 > https

[HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

10beta3 and 9.6.4 are both failing during initdb on mips64el on Debian/sid (unstable): https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6&arch=mips64el&ver=9.6.4-1&stamp=1502374949&raw=0 https://buildd.debian.org/status/fetch.php?pkg=postgresql-10&arch=mips64el&ver=10%7Ebeta3-1&stamp=15

Re: [HACKERS] initdb initalization failure for collation "ja_JP"

I wrote: >> One question that I've got is why the ICU portion refuses to load >> any entries unless is_encoding_supported_by_icu(GetDatabaseEncoding()). >> Surely this is completely wrong? I should think that what we load into >> pg_collation ought to be independent of template1's encoding, the sa

Re: [HACKERS] initdb initalization failure for collation "ja_JP"

I wrote: > One question that I've got is why the ICU portion refuses to load > any entries unless is_encoding_supported_by_icu(GetDatabaseEncoding()). > Surely this is completely wrong? I should think that what we load into > pg_collation ought to be independent of template1's encoding, the same >

Re: [HACKERS] initdb initalization failure for collation "ja_JP"

I wrote: > Now the hard part of that is that because pg_import_system_collations > isn't using a temporary staging table, but is just inserting directly > into pg_collation, there isn't any way for it to eliminate duplicates > unless it uses if_not_exists behavior all the time. So there seem to >

Re: [HACKERS] initdb initalization failure for collation "ja_JP"

On 20/06/2017 17:37, Tom Lane wrote: I wrote: Marco Atzeri writes: Building on Cygwin latest 10 beta1 or head sourece, make check fails as: ... performing post-bootstrap initialization ... 2017-05-31 23:23:22.214 CEST [16860] FATAL: collation "ja_JP" for encoding "EUC_JP" already exists H

Re: [HACKERS] initdb initalization failure for collation "ja_JP"

On 18/06/2017 16:48, Tom Lane wrote: Marco Atzeri writes: Building on Cygwin latest 10 beta1 or head sourece, make check fails as: ... performing post-bootstrap initialization ... 2017-05-31 23:23:22.214 CEST [16860] FATAL: collation "ja_JP" for encoding "EUC_JP" already exists Hmph. Could

Re: [HACKERS] initdb initalization failure for collation "ja_JP"

I wrote: > Marco Atzeri writes: >> Building on Cygwin latest 10 beta1 or head sourece, >> make check fails as: >> ... >> performing post-bootstrap initialization ... 2017-05-31 23:23:22.214 >> CEST [16860] FATAL: collation "ja_JP" for encoding "EUC_JP" already exists > Hmph. Could we see the

Re: [HACKERS] initdb initalization failure for collation "ja_JP"

Marco Atzeri writes: > Building on Cygwin latest 10 beta1 or head sourece, > make check fails as: > ... > performing post-bootstrap initialization ... 2017-05-31 23:23:22.214 > CEST [16860] FATAL: collation "ja_JP" for encoding "EUC_JP" already exists Hmph. Could we see the results of "locale

[HACKERS] initdb initalization failure for collation "ja_JP"

Building on Cygwin latest 10 beta1 or head sourece, make check fails as: -initdb.log - The database cluster will be initialized with locales COLLATE: en_US.UTF-8 CTYPE:en_US.UTF-8 MESSAGES: C MONETARY: en_US.UTF-8 NUMERIC: en_US.UTF

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 1 July 2016 at 09:02, Michael Paquier wrote: > On Fri, Jul 1, 2016 at 9:57 AM, Alvaro Herrera > wrote: > > Craig Ringer wrote: > >> On 30 June 2016 at 20:19, Alvaro Herrera > wrote: > >> > >> > Hmm, so what about a pure 32bit build, if such a thing still exists? > If > >> > so and it causes

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jul 1, 2016 at 9:57 AM, Alvaro Herrera wrote: > Craig Ringer wrote: >> On 30 June 2016 at 20:19, Alvaro Herrera wrote: >> >> > Hmm, so what about a pure 32bit build, if such a thing still exists? If >> > so and it causes the same crash, perhaps we should have one member for >> > each VS

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Craig Ringer wrote: > On 30 June 2016 at 20:19, Alvaro Herrera wrote: > > > Hmm, so what about a pure 32bit build, if such a thing still exists? If > > so and it causes the same crash, perhaps we should have one member for > > each VS version running on 32bit x86. > > It's fine for a pure 32-bi

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 30 June 2016 at 20:19, Alvaro Herrera wrote: > Craig Ringer wrote: > > On 30 June 2016 at 07:21, Tom Lane wrote: > > > > > Alvaro Herrera writes: > > > > Tom Lane wrote: > > > >> Thanks for investigating! I'll go commit that change. I wish > someone > > > >> would put up a buildfarm critte

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Craig Ringer wrote: > On 30 June 2016 at 07:21, Tom Lane wrote: > > > Alvaro Herrera writes: > > > Tom Lane wrote: > > >> Thanks for investigating! I'll go commit that change. I wish someone > > >> would put up a buildfarm critter using VS2013, though. > > > > > Uh, isn't that what woodlouse i

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 30 June 2016 at 07:21, Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Thanks for investigating! I'll go commit that change. I wish someone > >> would put up a buildfarm critter using VS2013, though. > > > Uh, isn't that what woodlouse is using? > > Well, it wasn't reporti

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Alvaro Herrera writes: > Tom Lane wrote: >> Thanks for investigating! I'll go commit that change. I wish someone >> would put up a buildfarm critter using VS2013, though. > Uh, isn't that what woodlouse is using? Well, it wasn't reporting this crash, so there's *something* different.

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Michael Paquier wrote: > On Fri, Jun 24, 2016 at 11:51 AM, Tsunakawa, Takayuki > wrote: > >> From: pgsql-hackers-ow...@postgresql.org > >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > >> Sent: Friday, June 24, 2016 11:37 AM > >> On Fri, Jun 24, 2016 at 11:33 AM, Craig

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Tom Lane wrote: > "Haroon ." writes: > > The problem appears to be related to 'taking the address of a formal > > parameter'. NOT passing the original formal parameter to > > get_foreign_key_join_selectivity fixes it (dodges the problem) on VS2013. > > Thanks for investigating! I'll go commit t

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

"Haroon ." writes: > On Sat, Jun 25, 2016 at 6:40 PM, Tom Lane wrote: >> This leads to a couple of suggestions for dodging the problem: >> >> 2. Don't pass the original formal parameter to >> get_foreign_key_join_selectivity, ie do something like >> >> static double >> calc_joinrel_size_estimat

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Sat, Jun 25, 2016 at 6:40 PM, Tom Lane wrote: > > If that is the explanation, I'm suspicious that it's got something to do > with the interaction of a static inline-able (single-call-site) function > and taking the address of a formal parameter. We certainly have multiple > other instances of

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

"Haroon ." writes: > And if I comment these out i.e. setup_description, setup_privileges and > 'setup_schema' it seem to progress well without any errors/crashes. Presumably, what you've done there is remove every single join query from the post-bootstrap scripts. That isn't particularly useful

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Craig Ringer writes: > On 24 June 2016 at 21:34, Tom Lane wrote: >> TBH, this looks more like a compiler bug than anything else. > I tend to agree. Especially since valgrind has no complaints on x64 linux, > and neither does DrMemory for 32-bit builds with the same toolchain on the > same Window

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 21:34, Tom Lane wrote: > > TBH, this looks more like a compiler bug than anything else. I tend to agree. Especially since valgrind has no complaints on x64 linux, and neither does DrMemory for 32-bit builds with the same toolchain on the same Windows and same SDK. I don't s

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

> On Fri, Jun 24, 2016 at 1:28 PM, Craig Ringer wrote: > > I'd like more details from those whose installs are crashing. What exact > > vcvars env did you run under, with which exact cl.exe version? This is a Windows server 2012 R2 Standard. Devenv: Microsoft Visual Studio 2013 Community Version

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Craig Ringer writes: > I have absolutely no idea why it's trying to access memory at what looks > like (uint64)(-1) though. Nothing in the auto vars list: > + &restrictlist 0x0043f7b0 {0x09e32600 {type=T_List (656) > length=1 head=0x09e325e0 {data={ptr_value=...} ...} .

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer wrote: >> I was helping Haroon with this last night. I don't have access to the >> original thread and he's not around so I don't know how much he said. I'll >> repeat our findings here. Craig, I am around now looking into this. I'll update the list

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

I have been running bisect, it breaks at this commit: *commit 100340e2dcd05d6505082a8fe343fb2ef2fa5b2a* *Author: Tom Lane >* *Date: Sat Jun 18 15:22:34 2016 -0400* *Restore foreign-key-aware estimation of join relation sizes.* *This patch provides a new implementation of the logic added

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer wrote: >> I was helping Haroon with this last night. I don't have access to the >> original thread and he's not around so I don't know how much he said. I'll >> repeat our findings here. Craig, I am around now looking into this. I'll update the list

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 3:22 PM, Craig Ringer wrote: > > > On 24 June 2016 at 10:28, Michael Paquier wrote: >> >> On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer >> wrote: >> > * Launch a VS x86 command prompt >> > * devenv /debugexe bin\initdb.exe -D test >> > * Set a breakpoint in initdb.

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 10:28, Michael Paquier wrote: > On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer > wrote: > > * Launch a VS x86 command prompt > > * devenv /debugexe bin\initdb.exe -D test > > * Set a breakpoint in initdb.c:3557 and initdb.c:3307 > > * Run > > * When it traps at get_r

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 13:00, Craig Ringer wrote: > I've now reproduced it with: > I can also confirm that it _doesn't_ crash with the same SDK using a 32-bit build (running under WoW on x64). cl 18.00.40629 for x86, env: %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 12:31, Michael Paquier wrote: > On Fri, Jun 24, 2016 at 1:28 PM, Craig Ringer > wrote: > > Given that it's only been seen in VS 2013, it's particularly odd that > it's > > not biting woodlouse. > > > > I'd like more details from those whose installs are crashing. What exact >

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 1:28 PM, Craig Ringer wrote: > Given that it's only been seen in VS 2013, it's particularly odd that it's > not biting woodlouse. > > I'd like more details from those whose installs are crashing. What exact > vcvars env did you run under, with which exact cl.exe version? W

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 05:17, Umair Shahid wrote: > >> > It's still strange that it doesn't affect woodlouse. >> >> Or any of the other Windows critters... >> >> > Given that it's only been seen in VS 2013, it's particularly odd that it's not biting woodlouse. I'd like

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 11:51 AM, Tsunakawa, Takayuki wrote: >> From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier >> Sent: Friday, June 24, 2016 11:37 AM >> On Fri, Jun 24, 2016 at 11:33 AM, Craig Ringer >> wrote: >> It might be w

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > Sent: Friday, June 24, 2016 11:37 AM > On Fri, Jun 24, 2016 at 11:33 AM, Craig Ringer > wrote: > It might be worth testing that out and adding an initdb startup flag > > to creat

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 11:33 AM, Craig Ringer wrote: > Yes, quite possibly, actually. I should've just got Haroon to build me a new > initdb without the priv setting and with creation of crashdumps/ . > > It might be worth testing that out and adding an initdb startup flag to > create the directo

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 10:28, Michael Paquier wrote: > On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer > wrote: > > * Launch a VS x86 command prompt > > * devenv /debugexe bin\initdb.exe -D test > > * Set a breakpoint in initdb.c:3557 and initdb.c:3307 > > * Run > > * When it traps at get_r

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 10:21, Craig Ringer wrote: > * To get a backtrace, I had to: > > * Launch a VS x86 command prompt > * devenv /debugexe bin\initdb.exe -D test > * Set a breakpoint in initdb.c:3557 and initdb.c:3307 > * Run > * When it traps at get_restricted_token(), manually move th

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer wrote: > * Launch a VS x86 command prompt > * devenv /debugexe bin\initdb.exe -D test > * Set a breakpoint in initdb.c:3557 and initdb.c:3307 > * Run > * When it traps at get_restricted_token(), manually move the execution > pointer over the

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 05:17, Umair Shahid wrote: > On Fri, Jun 24, 2016 at 2:14 AM, Umair Shahid < > umair.sha...@2ndquadrant.com> wrote: > >> >> -- Forwarded message -- >> From: Tom Lane >> Date: Thu, Jun 23, 2016 at 9:32 PM >> Subject: Re: [pgsql-packagers] PG 9.6beta2 tarballs ar

[HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 2:14 AM, Umair Shahid wrote: > > -- Forwarded message -- > From: Tom Lane > Date: Thu, Jun 23, 2016 at 9:32 PM > Subject: Re: [pgsql-packagers] PG 9.6beta2 tarballs are ready > To: Magnus Hagander > Cc: Umair Shahid , Dave Page < > dp...@postgresql.org>,

Re: [HACKERS] initdb: introduce PG_CMD_PRINTF intestead of PG_CMD_PRINTF{1,2,3}

Alexander Kuleshov writes: > The src/bin/initdb/initdb.c provides three macros to write data to > cmdfd. All of these macro do the same, but with different amount of > arguments for fprintf(). > Attached patch introduces PG_CMD_PRINTF macro which will take set of > variadic arguments via __VA_ARG

[HACKERS] initdb: introduce PG_CMD_PRINTF intestead of PG_CMD_PRINTF{1,2,3}

Hello all, The src/bin/initdb/initdb.c provides three macros to write data to cmdfd. All of these macro do the same, but with different amount of arguments for fprintf(). Attached patch introduces PG_CMD_PRINTF macro which will take set of variadic arguments via __VA_ARGS__ to replace the PG_CMD_

Re: [HACKERS] initdb -S versus superuser check and Windows restricted mode

On Sat, May 30, 2015 at 6:08 AM, Tom Lane wrote: > I noticed that if you use "initdb -S", the code does its thing and > exits without ever calling get_restricted_token(). It doesn't get > to get_id() where the no-superuser check is, either. Is this OK, > or should we reorder the operations so th

[HACKERS] initdb -S versus superuser check and Windows restricted mode

I noticed that if you use "initdb -S", the code does its thing and exits without ever calling get_restricted_token(). It doesn't get to get_id() where the no-superuser check is, either. Is this OK, or should we reorder the operations so that fsyncing is done with the usual restricted privileges?

Re: [HACKERS] initdb start server recommendation

On Fri, May 1, 2015 at 10:14:13AM -0400, Bruce Momjian wrote: > Currently initdb outputs suggested text on starting the server: > > Success. You can now start the database server using: > > /u/pgsql/bin/postgres -D /u/pgsql/data > or > /u/pgsql/bin/pg_ctl -D

Re: [HACKERS] initdb -S and tablespaces

Andres Freund writes: > On 2015-05-08 22:08:31 -0400, Robert Haas wrote: >> Of course, even the last one isn't totally bullet-proof. Suppose one >> backend fails to absorb the new setting for some reason... > I've a hard time worrying much about that one... You should. At the very least, whate

Re: [HACKERS] initdb -S and tablespaces

On 2015-05-08 22:08:31 -0400, Robert Haas wrote: > That seems a bit better. I think it's really important, if we're > going to start to try to make fsync=off anything other than a toy, I think it's long past that. I've seen many, many people use it during initial data loading. > that we document

Re: [HACKERS] initdb -S and tablespaces

On Fri, May 8, 2015 at 7:53 PM, Andres Freund wrote: > On 2015-05-04 14:23:16 -0400, Robert Haas wrote: >> On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen >> wrote: >> > As for the non-backpatchable 0002, I agree with Andres that it should be >> > included in 9.5; but I take it you're still n

Re: [HACKERS] initdb -S and tablespaces

On 2015-05-04 14:23:16 -0400, Robert Haas wrote: > On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen > wrote: > > As for the non-backpatchable 0002, I agree with Andres that it should be > > included in 9.5; but I take it you're still not convinced? > > No, I'm not convinced. That patch will p

Re: [HACKERS] initdb start server recommendation

On 05-05-2015 16:36, Peter Eisentraut wrote: > 1. I like copying and pasting the "postgres" line during development. > That's not a reason to keep it, necessarily. > I prefer pg_ctl because of symmetry (start, stop, restart, reload and even init). > 2. If you're saying, most people shouldn't run

Re: [HACKERS] initdb start server recommendation

On Thu, May 7, 2015 at 10:17:18AM -0400, Andrew Dunstan wrote: > > On 05/07/2015 09:58 AM, Bruce Momjian wrote: > > > > >Frankly, I am not sure how they are starting the server as the > >/etc/init.d startup files don't handle multiple clusters well, and I > >have never seen instructions on how m

Re: [HACKERS] initdb start server recommendation

On 05/07/2015 09:58 AM, Bruce Momjian wrote: Frankly, I am not sure how they are starting the server as the /etc/init.d startup files don't handle multiple clusters well, and I have never seen instructions on how multi-cluster users are supposed to set things up. I assume they are copying

Re: [HACKERS] initdb start server recommendation

On Tue, May 5, 2015 at 03:36:07PM -0400, Peter Eisentraut wrote: > > BTW, why are we advocating postgres binary use at all? AFAICS the main > > postgres (or postmaster) uses are (i) startup script (which also > > advocate for 'pg_ctl -w') and (ii) disaster/debugging purposes. None of > > those use

Re: [HACKERS] initdb start server recommendation

On 5/1/15 10:55 AM, Euler Taveira wrote: > On 01-05-2015 11:14, Bruce Momjian wrote: >> Currently initdb outputs suggested text on starting the server: >> >> Success. You can now start the database server using: >> >> /u/pgsql/bin/postgres -D /u/pgsql/data >> or >>

Re: [HACKERS] initdb -S and tablespaces

On Tue, May 5, 2015 at 6:26 AM, David Rowley wrote: > On 5 May 2015 at 06:23, Robert Haas wrote: >> >> OK, committed and back-patched. > > There's a couple of problems with this that the windows buildfarm members > are not happy with. > > The attached patch seems to work locally. Thanks. I thin

Re: [HACKERS] initdb -S and tablespaces

On 5 May 2015 at 06:23, Robert Haas wrote: > > OK, committed and back-patched. > There's a couple of problems with this that the windows buildfarm members are not happy with. The attached patch seems to work locally. Regards David Rowley fsync_win32_fix.patch Description: Binary data -- S

Re: [HACKERS] initdb -S and tablespaces

On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen wrote: > At 2015-05-01 09:57:28 -0400, robertmh...@gmail.com wrote: >> >> If you don't object to this version, I'll commit it. > > Looks fine to me, thank you. OK, committed and back-patched. > As for the non-backpatchable 0002, I agree with And

Re: [HACKERS] initdb start server recommendation

On May 1, 2015 17:09, "Andrew Dunstan" wrote: > > > On 05/01/2015 10:14 AM, Bruce Momjian wrote: >> >> Currently initdb outputs suggested text on starting the server: >> >> Success. You can now start the database server using: >> >> /u/pgsql/bin/postgres -D /u/pgsql/data >>

Re: [HACKERS] initdb start server recommendation

On 05/01/2015 10:14 AM, Bruce Momjian wrote: Currently initdb outputs suggested text on starting the server: Success. You can now start the database server using: /u/pgsql/bin/postgres -D /u/pgsql/data or /u/pgsql/bin/pg_ctl -D /u/pgsql/data -l l

Re: [HACKERS] initdb start server recommendation

On 01-05-2015 11:14, Bruce Momjian wrote: > Currently initdb outputs suggested text on starting the server: > > Success. You can now start the database server using: > > /u/pgsql/bin/postgres -D /u/pgsql/data > or > /u/pgsql/bin/pg_ctl -D /u/pgsql/data -l log

Re: [HACKERS] initdb -S and tablespaces

At 2015-05-01 09:57:28 -0400, robertmh...@gmail.com wrote: > > If you don't object to this version, I'll commit it. Looks fine to me, thank you. As for the non-backpatchable 0002, I agree with Andres that it should be included in 9.5; but I take it you're still not convinced? Should I add that to

Re: [HACKERS] initdb start server recommendation

On Fri, May 1, 2015 at 10:14 AM, Bruce Momjian wrote: > Currently initdb outputs suggested text on starting the server: > > Success. You can now start the database server using: > > /u/pgsql/bin/postgres -D /u/pgsql/data > or > /u/pgsql/bin/pg_ctl -D /u/pgsq

[HACKERS] initdb start server recommendation

Currently initdb outputs suggested text on starting the server: Success. You can now start the database server using: /u/pgsql/bin/postgres -D /u/pgsql/data or /u/pgsql/bin/pg_ctl -D /u/pgsql/data -l logfile start I am now thinking pg_ctl should be

Re: [HACKERS] initdb -S and tablespaces

Hi, I agree that splitting the patch into two separate ones is a good one. On 2015-05-01 09:57:28 -0400, Robert Haas wrote: > If you don't object to this version, I'll commit it. I believe this > part *should* be back-patched, but Tom seemed to disagree, for reasons > I'm not really clear on. T

Re: [HACKERS] initdb -S and tablespaces

On Fri, May 1, 2015 at 8:42 AM, Abhijit Menon-Sen wrote: > At 2015-05-01 08:10:16 -0400, robertmh...@gmail.com wrote: >> It seems to me that, at a minimum, it would be good to split those >> controversial and definitely not-back-patchable changes into their >> own patch. > > OK, split here (0002*)

Re: [HACKERS] initdb -S and tablespaces

At 2015-05-01 08:10:16 -0400, robertmh...@gmail.com wrote: > > It seems to me that, at a minimum, it would be good to split those > controversial and definitely not-back-patchable changes into their > own patch. OK, split here (0002*). > I do mind putting it into xlog.c instead of some place that

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 30, 2015 at 11:29 PM, Abhijit Menon-Sen wrote: >> 2. I don't know why it's part of this patch. > > In 20150115133245.gg5...@awork2.anarazel.de, Andres explained his > rationale as follows: > > «What I am thinking of is that, currently, if you start the server > for initial loa

Re: [HACKERS] initdb -S and tablespaces

At 2015-04-30 16:56:17 -0700, t...@sss.pgh.pa.us wrote: > > As for the notion that this needs to be back-patched, I would say no. Not even just the "fsync after crash" part? I could separate that out from the control file changes and try to eliminate the duplication. I think that would be worth ba

Re: [HACKERS] initdb -S and tablespaces

At 2015-04-30 15:37:44 -0400, robertmh...@gmail.com wrote: > > 1. It doesn't do that. As soon as we fsync the data directory, we >reset the flag. That's not what "ever disabled" means to me. Could you suggest an acceptable alternative wording? I can't immediately think of anything better tha

Re: [HACKERS] initdb -S and tablespaces

Robert Haas writes: > On Thu, Apr 30, 2015 at 6:44 PM, Alvaro Herrera > wrote: >> Ah, so that's not the duplicate code that I was remembering -- I think >> it's walkdir() or something like that, which is in initdb IIRC. > Yeah, walkdir() is there too. But if we're going to add that to the > bac

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 30, 2015 at 6:44 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera >> wrote: >> >> Also, it seems awfully unfortunate to me that we're duplicating a >> >> whole pile of code into xlog.c here. Maybe there's no way to avoid >> >> the code

Re: [HACKERS] initdb -S and tablespaces

Robert Haas wrote: > On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera > wrote: > >> Also, it seems awfully unfortunate to me that we're duplicating a > >> whole pile of code into xlog.c here. Maybe there's no way to avoid > >> the code duplication, but pre_sync_fname() seems like it'd more > >> na

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera wrote: >> Also, it seems awfully unfortunate to me that we're duplicating a >> whole pile of code into xlog.c here. Maybe there's no way to avoid >> the code duplication, but pre_sync_fname() seems like it'd more >> naturally go in fd.c than here.

Re: [HACKERS] initdb -S and tablespaces

Robert Haas wrote: > Also, it seems awfully unfortunate to me that we're duplicating a > whole pile of code into xlog.c here. Maybe there's no way to avoid > the code duplication, but pre_sync_fname() seems like it'd more > naturally go in fd.c than here. I dunno where walkdir should go, but > a

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 16, 2015 at 9:24 AM, Abhijit Menon-Sen wrote: > Here's a variation of the earlier patch that follows all links in > PGDATA. Does this look more like what you had in mind? I'm really confused by the additional control-file field. It is documented as indicating whether fsync was ever d

Re: [HACKERS] initdb -S and tablespaces

Hi. Here's a variation of the earlier patch that follows all links in PGDATA. Does this look more like what you had in mind? -- Abhijit >From d86888b0d2f5a3a57027d26ce050a3bbb58670d3 Mon Sep 17 00:00:00 2001 From: Abhijit Menon-Sen Date: Thu, 6 Nov 2014 00:45:56 +0530 Subject: Recursively fsync

Re: [HACKERS] initdb -S and tablespaces

At 2015-04-15 11:40:34 +0530, a...@2ndquadrant.com wrote: > > Still, thanks to the example in basebackup.c, I've got most of a patch > that should follow any symlinks in PGDATA. I notice that src/bin/pg_rewind/copy_fetch.c has a traverse_datadir() function that does what we want (but it recurses i

Re: [HACKERS] initdb -S and tablespaces

At 2015-04-06 10:16:36 -0300, alvhe...@2ndquadrant.com wrote: > > Well, we have many things that can be set as symlinks; some you can > have initdb create the links for you (initdb --xlogdir), others you > can move manually. Looking at sendDir() in backend/replication/basebackup.c, I notice that t

Re: [HACKERS] initdb -S and tablespaces

Abhijit Menon-Sen wrote: Hi, > At 2015-04-03 13:32:32 -0300, alvhe...@2ndquadrant.com wrote: > > I also noticed that walkdir() thinks it is completely agnostic on > > what the passed action is; except that the comment at the bottom talks > > about how fsync on directories is important, which see

Re: [HACKERS] initdb -S and tablespaces

Hi Álvaro. Thanks for taking a look at the patch. At 2015-04-03 13:32:32 -0300, alvhe...@2ndquadrant.com wrote: > > But then, since the name is already telling us that it's all about > PGDATA, maybe we can remove the "recursively" part of the name? Sure, that makes sense too. Since you and Andre

Re: [HACKERS] initdb -S and tablespaces

Abhijit Menon-Sen wrote: > At 2015-01-15 14:32:45 +0100, and...@2ndquadrant.com wrote: > Patch attached. > > Changes: > > 1. Renamed perform_fsync to fsync_recursively (otherwise it would read >"fsync_pgdata(pg_data)") Okay, but as far as I can tell this function is very specific to PGDATA;

Re: [HACKERS] initdb -S and tablespaces

At 2015-01-15 14:32:45 +0100, and...@2ndquadrant.com wrote: > > What I am thinking of is that, currently, if you start the server for > initial loading with fsync=off, and then restart it, you're open to > data loss. So when the current config file setting is changed from off > to on, we should fsy

Re: [HACKERS] initdb -S and tablespaces

On 2015-01-15 11:02:43 +0530, Abhijit Menon-Sen wrote: > At 2015-01-14 11:59:08 +0100, and...@2ndquadrant.com wrote: > > > > > + if (ControlFile->state != DB_SHUTDOWNED && > > > + ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY) > > > + perform_fsync(data_directory); > > > + > > >

Re: [HACKERS] initdb -S and tablespaces

At 2015-01-14 11:59:08 +0100, and...@2ndquadrant.com wrote: > > > + if (ControlFile->state != DB_SHUTDOWNED && > > + ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY) > > + perform_fsync(data_directory); > > + > > a) Please think of a slightly more descriptive name than perfor

Re: [HACKERS] initdb -S and tablespaces

Hi, On 2014-11-06 17:56:53 +0530, Abhijit Menon-Sen wrote: > + /* > + * If we need to perform crash recovery, we issue an fsync on the > + * data directory and its contents to try to ensure that any data > + * written before the crash are flushed to disk. Otherwise a power > +

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 12/31/2014 12:26 PM, Tomas Vondra wrote: On 31.12.2014 17:29, Andrew Dunstan wrote: Sorry, I should have tested it. This seems to work: if ($branch eq 'REL9_0_STABLE') { $PGBuild::Options::skip_steps .= ' pl-install-check'; $main::skip_steps{'pl-install-check'} = 1

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 31.12.2014 17:29, Andrew Dunstan wrote: > > Sorry, I should have tested it. This seems to work: > >if ($branch eq 'REL9_0_STABLE') >{ > $PGBuild::Options::skip_steps .= ' pl-install-check'; > $main::skip_steps{'pl-install-check'} = 1; >} > > cheers Meh, no problem

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 12/31/2014 07:49 AM, Tomas Vondra wrote: On 28.12.2014 00:46, Noah Misch wrote: On Tue, Dec 23, 2014 at 03:32:59PM +0100, Tomas Vondra wrote: On 23.12.2014 15:21, Andrew Dunstan wrote: No, config_opts is what's passed to configure. Try something like: if ($branch eq 'REL9_0_STABLE')

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 28.12.2014 00:46, Noah Misch wrote: > On Tue, Dec 23, 2014 at 03:32:59PM +0100, Tomas Vondra wrote: >> On 23.12.2014 15:21, Andrew Dunstan wrote: >>> >>> No, config_opts is what's passed to configure. Try something like: >>> >>> if ($branch eq 'REL9_0_STABLE') >>> { >>> $skip_ste

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On Tue, Dec 23, 2014 at 03:32:59PM +0100, Tomas Vondra wrote: > On 23.12.2014 15:21, Andrew Dunstan wrote: > > > > No, config_opts is what's passed to configure. Try something like: > > > > if ($branch eq 'REL9_0_STABLE') > > { > > $skip_steps{'pl-install-check'} = 1; > > } >

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 23.12.2014 15:21, Andrew Dunstan wrote: > > No, config_opts is what's passed to configure. Try something like: > > if ($branch eq 'REL9_0_STABLE') > { > $skip_steps{'pl-install-check'} = 1; > } Applied to all three animals. Tomas -- Sent via pgsql-hackers mailing list

  1   2   3   4   5   6   >