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

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

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

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

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=mips64el=9.6.4-1=1502374949=0 >

[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=mips64el=9.6.4-1=1502374949=0 https://buildd.debian.org/status/fetch.php?pkg=postgresql-10=mips64el=10%7Ebeta3-1=1502535836=0 All other

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

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

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"

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 >

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

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

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

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

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

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

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,

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

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

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

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

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

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

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.

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

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

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

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: > + 0x0043f7b0 {0x09e32600 {type=T_List (656) > length=1 head=0x09e325e0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

[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

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 >

[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

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

On Sat, May 30, 2015 at 6:08 AM, Tom Lane t...@sss.pgh.pa.us 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

[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

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

Andres Freund and...@anarazel.de 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

Re: [HACKERS] initdb -S and tablespaces

On Fri, May 8, 2015 at 7:53 PM, Andres Freund and...@anarazel.de wrote: On 2015-05-04 14:23:16 -0400, Robert Haas wrote: On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen a...@2ndquadrant.com wrote: As for the non-backpatchable 0002, I agree with Andres that it should be included in 9.5;

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 a...@2ndquadrant.com 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

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

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

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

Re: [HACKERS] initdb -S and tablespaces

On Tue, May 5, 2015 at 6:26 AM, David Rowley dgrowle...@gmail.com wrote: On 5 May 2015 at 06:23, Robert Haas robertmh...@gmail.com 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

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 5 May 2015 at 06:23, Robert Haas robertmh...@gmail.com 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:

Re: [HACKERS] initdb -S and tablespaces

On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen a...@2ndquadrant.com 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

Re: [HACKERS] initdb start server recommendation

On May 1, 2015 17:09, Andrew Dunstan and...@dunslane.net 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 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 logfile

Re: [HACKERS] initdb start server recommendation

On Fri, May 1, 2015 at 10:14 AM, Bruce Momjian br...@momjian.us 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

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

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 -S and tablespaces

On Fri, May 1, 2015 at 8:42 AM, Abhijit Menon-Sen a...@2ndquadrant.com 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

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.

[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

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

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 30, 2015 at 11:29 PM, Abhijit Menon-Sen a...@2ndquadrant.com 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

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 16, 2015 at 9:24 AM, Abhijit Menon-Sen a...@2ndquadrant.com 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

Re: [HACKERS] initdb -S and tablespaces

Robert Haas wrote: On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] initdb -S and tablespaces

Robert Haas robertmh...@gmail.com writes: On Thu, Apr 30, 2015 at 6:44 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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

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 than

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

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 30, 2015 at 6:44 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Robert Haas wrote: On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Also, it seems awfully unfortunate to me that we're duplicating a whole pile of code into xlog.c here. Maybe

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

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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

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 a...@2ndquadrant.com Date: Thu, 6 Nov 2014 00:45:56 +0530

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 the

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

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 Andres

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 seems out

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; you

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 fsync

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); + a) Please think of a

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 perform_fsync OK.

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 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 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 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. We've

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'} =

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; } Applied to

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

On Sat, Dec 20, 2014 at 07:28:33PM +0100, Tomas Vondra wrote: On 20.12.2014 19:05, Tom Lane wrote: Locale cs_CZ.WIN-1250 is evidently marked with a codeset property of ANSI_X3.4-1968 (which means old-school US-ASCII). That's certainly wrong. I believe the correct thing would be CP1250.

  1   2   3   4   5   >