Re: [GENERAL] initdb with ignore hidden option

On 05/04/2017 09:59 AM, Feld, Michael (IMS) wrote: Hi Postgres team, Our organization would like to make a feature request to ignore hidden files/directories when running an initdb. We use hidden directories for misc backup strategies, and it’s cumbersome when needing to coordi

Re: [GENERAL] initdb createuser commands

> Really? So naming them pg_initdb and pg_createdb would help to clarify their > use? Yes. > Perhaps you missed: https://www.postgresql.org/docs/9.6/static/app-pg-ctl.html I meant a man page that details the ENTIRE Postgres command line tools. > Command line aliases and other stuff I've been

Re: [GENERAL] initdb createuser commands

On 10/31/16 9:50 AM, Christofer C. Bell wrote: He's getting a lot of pushback that really feels it's coming from the wrong direction. "Just learn it." "It's always been this way." "No one agrees with you." These arguments are unconvincing. That said, there's nothing wrong with just saying, "

Re: [GENERAL] initdb createuser commands

On 10/31/2016 05:15 PM, Samuel Williams wrote: > Daniel, your reply is awesome :) I love the historical context and it > brings much clarity to the discussion! > > It's now understandable why the commands were named the way they were. > > I'm surprised that distros are making their own commands f

Re: [GENERAL] initdb createuser commands

Daniel, your reply is awesome :) I love the historical context and it brings much clarity to the discussion! It's now understandable why the commands were named the way they were. I'm surprised that distros are making their own commands for postgres.. isn't that a bit invasive? On 1 November 2

Re: [GENERAL] initdb createuser commands

Samuel Williams wrote: > John - that's an interesting example. If it's that easy, why isn't > that the approach given in tutorials and other documentation? What was > the motivation for the createuser command? initdb, createdb and createuser existed even before Postgres adopted SQL, back

Re: [GENERAL] initdb createuser commands

On 31 October 2016 at 15:50, Christofer C. Bell wrote: > > I think the OP's point is that having a hodgepodge of (on their face) > unrelated commands smells kinda unorganized at best and unprofessional at > worst. Wether or not he's right is up to the reader. For me, I agree with > his sentimen

Re: [GENERAL] initdb createuser commands

On Mon, Oct 31, 2016 at 10:50 AM, Christofer C. Bell < christofer.c.b...@gmail.com> wrote: > On Sun, Oct 30, 2016 at 11:10 PM, Melvin Davidson > wrote: > >> >> >> >> >> On Sun, Oct 30, 2016 at 8:08 PM, Samuel Williams < >> space.ship.travel...@gmail.com> wrote: >> >>> Sorry, just to clarify, b "w

Re: [GENERAL] initdb createuser commands

On Sun, Oct 30, 2016 at 11:10 PM, Melvin Davidson wrote: > > > > > On Sun, Oct 30, 2016 at 8:08 PM, Samuel Williams < > space.ship.travel...@gmail.com> wrote: > >> Sorry, just to clarify, b "worst" I don't mean functionality, I mean >> the way the commands are named and organised. >> >> On 31 Oct

Re: [GENERAL] initdb createuser commands

On Sun, Oct 30, 2016 at 8:08 PM, Samuel Williams < space.ship.travel...@gmail.com> wrote: > Sorry, just to clarify, b "worst" I don't mean functionality, I mean > the way the commands are named and organised. > > On 31 October 2016 at 13:07, Samuel Williams > wrote: > > Mike, I agree with "the po

Re: [GENERAL] initdb createuser commands

Sorry, just to clarify, b "worst" I don't mean functionality, I mean the way the commands are named and organised. On 31 October 2016 at 13:07, Samuel Williams wrote: > Mike, I agree with "the postgres way of doing things". I'm suggesting that > >> these commands are sufficiently generic that th

Re: [GENERAL] initdb createuser commands

Mike, I agree with "the postgres way of doing things". I'm suggesting that > these commands are sufficiently generic that they might clash with other commands. > It's also not obvious they are part of postgresql. > Wouldn't it make more sense to make them subcommand, of, say, a top level pga (p

Re: [GENERAL] initdb createuser commands

From: Samuel Williams Sent: Sunday, October 30, 2016 3:42 PM As a community I'd think that having feedback from a new user would be valuable since as you say, sometimes when you get ingrained into the "way of doing things" that you don't see how they could be improved or different. Samuel

Re: [GENERAL] initdb createuser commands

On 10/30/2016 03:42 PM, Samuel Williams wrote: A given the number of new users I see showing up and the number of those using a GUI like pgAdmin I am not seeing the priority. Well, maybe the reason for this is that the command line tools are not well thought out and people reach for alternativ

Re: [GENERAL] initdb createuser commands

> A given the number of new users I see showing up and the number of those > using a GUI like pgAdmin I am not seeing the priority. Well, maybe the reason for this is that the command line tools are not well thought out and people reach for alternatives. > but you are pushing against something t

Re: [GENERAL] initdb createuser commands

On 10/30/2016 12:15 AM, Samuel Williams wrote: Adrian, I like the idea of teaching the appropriate SQL to achieve the same thing. It makes a lot of sense, it's a pity the majority of documentation doesn't do this. John, if you read my earlier email you'd see that I proposed including deprecation

Re: [GENERAL] initdb createuser commands

On 10/30/2016 02:19 AM, Samuel Williams wrote: John - that's an interesting example. If it's that easy, why isn't that the approach given in tutorials and other documentation? What was the motivation for the createuser command? psql was less user friendly in the past? Compare: https://www.pos

Re: [GENERAL] initdb createuser commands

John - that's an interesting example. If it's that easy, why isn't that the approach given in tutorials and other documentation? What was the motivation for the createuser command? On 30 October 2016 at 20:20, John R Pierce wrote: > On 10/30/2016 12:15 AM, Samuel Williams wrote: >> >> But, I thin

Re: [GENERAL] initdb createuser commands

On 10/30/2016 12:15 AM, Samuel Williams wrote: But, I think having "pg_createuser" or, preferrably, "pg createuser". psql -c "create user " -- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subs

Re: [GENERAL] initdb createuser commands

Adrian, I like the idea of teaching the appropriate SQL to achieve the same thing. It makes a lot of sense, it's a pity the majority of documentation doesn't do this. John, if you read my earlier email you'd see that I proposed including deprecation notices and aliasing the commands. I appreciate

Re: [GENERAL] initdb createuser commands

On 30/10/16 11:25, John R Pierce wrote: On 10/29/2016 3:02 PM, Samuel Williams wrote: FYI,https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb, createuser, createdb and several others. I think my suggestion is still relevant and something that would improve the system for new users

Re: [GENERAL] initdb createuser commands

On Sat, Oct 29, 2016 at 6:25 PM, John R Pierce wrote: > On 10/29/2016 3:02 PM, Samuel Williams wrote: > >> FYI,https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb, >> createuser, createdb and several others. I think my suggestion is >> still relevant and something that would improve

Re: [GENERAL] initdb createuser commands

On 10/29/2016 3:02 PM, Samuel Williams wrote: FYI,https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb, createuser, createdb and several others. I think my suggestion is still relevant and something that would improve the system for new users and it would break it for the existing c

Re: [GENERAL] initdb createuser commands

On 10/29/2016 03:02 PM, Samuel Williams wrote: FYI, https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb, createuser, createdb and several others. I think my suggestion is still relevant and something that would improve the system for new users :) Seems to me the solution would be to

Re: [GENERAL] initdb createuser commands

FYI, https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb, createuser, createdb and several others. I think my suggestion is still relevant and something that would improve the system for new users :) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make change

Re: [GENERAL] initdb createuser commands

I think there is an opportunity here to make the experience for new users better. Firstly, I think having one or two top level commands, perhaps pga [postgres admin], and pg [postgres client], with well documented sub-commands. Ideally `man pg` would tell you all the client commands and `man pga`

Re: [GENERAL] initdb createuser commands

On 10/29/2016 03:31 AM, Samuel Williams wrote: (For some reason the first time I sent this message it was blocked due to the keyword "sub-". So, I've changed that and am re-sending.) I think there is an opportunity here to make the experience for new users better. Firstly, I think having one or

Re: [GENERAL] initdb createuser commands

(For some reason the first time I sent this message it was blocked due to the keyword "sub-". So, I've changed that and am re-sending.) I think there is an opportunity here to make the experience for new users better. Firstly, I think having one or two top level commands, perhaps pga [postgres ad

Re: [GENERAL] initdb createuser commands

On 10/28/2016 4:55 PM, Samuel Williams wrote: Even if maintaining the old commands, they could print out to stderr "This command is deprecated and now wraps `pg_ctl init`. Please use that command in the future". except its the other way around. pg_ctl initdb invokes initdb, not the other way

Re: [GENERAL] initdb createuser commands

On 10/28/2016 04:55 PM, Samuel Williams wrote: as these commands have been around for like 20 years, its kinda late to change them I understand your position. For new documentation, it should be better to say `pg_ctl init` rather than `initdb`. I think that would guide users in the right dire

Re: [GENERAL] initdb createuser commands

> as these commands have been around for like 20 years, its kinda late to > change them I understand your position. For new documentation, it should be better to say `pg_ctl init` rather than `initdb`. I think that would guide users in the right direction from the start. Even if maintaining the

Re: [GENERAL] initdb createuser commands

On 10/28/2016 04:31 PM, Samuel Williams wrote: Hello, Perhaps I'm missing something. However, it seems to me that there are several "generically" named commands, e.g. initdb, createuesr which come as part of postgresql. In my mind, these commands are sufficiently generic that they might clash w

Re: [GENERAL] initdb createuser commands

On 10/28/2016 4:31 PM, Samuel Williams wrote: Just wondering as the naming of these commands seems overly generic and for a new user it's hard to know what commands are available since there is no common prefix (e.g. pg_) for these commands. as these commands have been around for like 20 years,

Re: [GENERAL] Initdb --data-checksums by default

> On Apr 22, 2016, at 3:21 AM, Stuart Bishop wrote: > > On 20 April 2016 at 14:43, Alex Ignatov wrote: >> Hello everyone! >> Today in Big Data epoch silent data corruption becoming more and more issue >> to afraid of. With uncorrectable read error rate ~ 10^-15 on multiterabyte >> disk bit ro

Re: [GENERAL] Initdb --data-checksums by default

On 21.04.2016 20:26, Vick Khera wrote: On Thu, Apr 21, 2016 at 9:00 AM, Alex Ignatov mailto:a.igna...@postgrespro.ru>> wrote: Ms Windows doesnt have ZFS support. AIX also doesnt. Z/OS also. Any other commercial Linux distros don't have ZFS support. Yes you can compile it and u

Re: [GENERAL] Initdb --data-checksums by default

On 20 April 2016 at 14:43, Alex Ignatov wrote: > Hello everyone! > Today in Big Data epoch silent data corruption becoming more and more issue > to afraid of. With uncorrectable read error rate ~ 10^-15 on multiterabyte > disk bit rot is the real issue. > I think that today checksumming data mu

Re: [GENERAL] Initdb --data-checksums by default

On Thu, Apr 21, 2016 at 9:00 AM, Alex Ignatov wrote: > Ms Windows doesnt have ZFS support. AIX also doesnt. Z/OS also. Any other > commercial Linux distros don't have ZFS support. Yes you can compile it and > use on production but... > But PG runs on the above OS, but have check sum off by defau

Re: [GENERAL] Initdb --data-checksums by default

On 20.04.2016 23:28, Vick Khera wrote: On Wed, Apr 20, 2016 at 3:43 AM, Alex Ignatov mailto:a.igna...@postgrespro.ru>> wrote: What do you think about defaulting --data-checksums in initdb? I think that ZFS storing my database files already does this and can correct for it using repli

Re: [GENERAL] Initdb --data-checksums by default

On Wed, Apr 20, 2016 at 3:43 AM, Alex Ignatov wrote: > What do you think about defaulting --data-checksums in initdb? > I think that ZFS storing my database files already does this and can correct for it using replicated copies, so why do I need a second layer of checksums?

Re: [GENERAL] Initdb --data-checksums by default

On 20.04.2016 16:58, Alvaro Herrera wrote: Alex Ignatov wrote: Hello everyone! Today in Big Data epoch silent data corruption becoming more and more issue to afraid of. With uncorrectable read error rate ~ 10^-15 on multiterabyte disk bit rot is the real issue. I think that today checksumming

Re: [GENERAL] Initdb --data-checksums by default

Alex Ignatov wrote: > Hello everyone! > Today in Big Data epoch silent data corruption becoming more and more issue > to afraid of. With uncorrectable read error rate ~ 10^-15 on multiterabyte > disk bit rot is the real issue. > I think that today checksumming data must be mandatory set by defau

Re: [GENERAL] Initdb --data-checksums by default

On 04/20/2016 02:22 AM, Alex Ignatov wrote: Why do you think that common pg-users doesn't care about their data? Also why do we have wal_level=minimal fsync=on and other stuff? Because Postgres will not run without WAL files and the setting is the least you can have. Doing so you lose the

Re: [GENERAL] Initdb --data-checksums by default

On 4/20/2016 1:00 AM, Alex Ignatov wrote: Uncorrectable read error rate ~ 10^-15- 10^-14. This error stays undetected and uncorrectable. what are your units here? disk IO is done by blocks, and the CRCs and trellis codes used by the disk drives for error detection and correction are applied

Re: [GENERAL] Initdb --data-checksums by default

On 20.04.2016 12:27, Andreas Joseph Krogh wrote: På onsdag 20. april 2016 kl. 11:22:33, skrev Alex Ignatov mailto:a.igna...@postgrespro.ru>>: [snip] Why do you think that common pg-users doesn't care about their data? Did I say that? Also why do we have wal_level=minimal fsync=

Re: [GENERAL] Initdb --data-checksums by default

På onsdag 20. april 2016 kl. 11:22:33, skrev Alex Ignatov < a.igna...@postgrespro.ru >: [snip] Why do you think that common pg-users doesn't care about their data?   Did I say that?   Also why do we have wal_level=minimal fsync=on and other stuff?   To make certain

Re: [GENERAL] Initdb --data-checksums by default

On 20.04.2016 12:10, Andreas Joseph Krogh wrote: På onsdag 20. april 2016 kl. 11:02:31, skrev Alex Ignatov mailto:a.igna...@postgrespro.ru>>: On 20.04.2016 11:40, Andreas Joseph Krogh wrote: På onsdag 20. april 2016 kl. 10:33:14, skrev Alex Ignatov mailto:a.igna...@postgrespro.ru

Re: [GENERAL] Initdb --data-checksums by default

På onsdag 20. april 2016 kl. 11:02:31, skrev Alex Ignatov < a.igna...@postgrespro.ru >:   On 20.04.2016 11:40, Andreas Joseph Krogh wrote: På onsdag 20. april 2016 kl. 10:33:14, skrev Alex Ignatov < a.igna...@postgrespro.ru >: On

Re: [GENERAL] Initdb --data-checksums by default

On 20.04.2016 11:40, Andreas Joseph Krogh wrote: På onsdag 20. april 2016 kl. 10:33:14, skrev Alex Ignatov mailto:a.igna...@postgrespro.ru>>: On 20.04.2016 11:29, Devrim Gündüz wrote: > Hi, > > On Wed, 2016-04-20 at 10:43 +0300, Alex Ignatov wrote: >> Today in Big Data e

Re: [GENERAL] Initdb --data-checksums by default

På onsdag 20. april 2016 kl. 10:33:14, skrev Alex Ignatov < a.igna...@postgrespro.ru >: On 20.04.2016 11:29, Devrim Gündüz wrote: > Hi, > > On Wed, 2016-04-20 at 10:43 +0300, Alex Ignatov wrote: >> Today in Big Data epoch silent data corruption becoming more

Re: [GENERAL] Initdb --data-checksums by default

On 20.04.2016 11:29, Devrim Gündüz wrote: Hi, On Wed, 2016-04-20 at 10:43 +0300, Alex Ignatov wrote: Today in Big Data epoch silent data corruption becoming more and more issue to afraid of. With uncorrectable read error rate ~ 10^-15 on multiterabyte disk bit rot is the real issue. I think

Re: [GENERAL] Initdb --data-checksums by default

Hi, On Wed, 2016-04-20 at 10:43 +0300, Alex Ignatov wrote: > Today in Big Data epoch silent data corruption becoming more and more  > issue to afraid of. With uncorrectable read error rate ~ 10^-15  on  > multiterabyte disk bit rot is the real issue. > I think that today checksumming data  must b

Re: [GENERAL] Initdb --data-checksums by default

On 20.04.2016 10:58, Michael Paquier wrote: On Wed, Apr 20, 2016 at 4:43 PM, Alex Ignatov wrote: Hello everyone! Today in Big Data epoch silent data corruption becoming more and more issue to afraid of. With uncorrectable read error rate ~ 10^-15 on multiterabyte disk bit rot is the real is

Re: [GENERAL] Initdb --data-checksums by default

On 20.04.2016 10:47, John R Pierce wrote: On 4/20/2016 12:43 AM, Alex Ignatov wrote: Today in Big Data epoch silent data corruption becoming more and more issue to afraid of. With uncorrectable read error rate ~ 10^-15on multiterabyte disk bit rot is the real issue. are not those uncorrect

Re: [GENERAL] Initdb --data-checksums by default

On Wed, Apr 20, 2016 at 4:43 PM, Alex Ignatov wrote: > Hello everyone! > Today in Big Data epoch silent data corruption becoming more and more issue > to afraid of. With uncorrectable read error rate ~ 10^-15 on multiterabyte > disk bit rot is the real issue. > I think that today checksumming da

Re: [GENERAL] Initdb --data-checksums by default

On 4/20/2016 12:43 AM, Alex Ignatov wrote: Today in Big Data epoch silent data corruption becoming more and more issue to afraid of. With uncorrectable read error rate ~ 10^-15on multiterabyte disk bit rot is the real issue. are not those uncorrectable errors detected by the disk hardware ? t

Re: [GENERAL] initdb of pg 9.0.13 fails on pg_authid

Sorry, gcc-4.7 and "make clean" solved the problem. -- View this message in context: http://postgresql.1045698.n5.nabble.com/initdb-of-pg-9-0-13-fails-on-pg-authid-tp5750773p5763679.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing

Re: [GENERAL] initdb of pg 9.0.13 fails on pg_authid

Hello! I also have the same problem and same configuration (x86_64, gcc 4.8.0), but -O flag didn't help me. I've used few variants, like: ./configure --prefix=/usr CFLAGS="-O" ./configure --prefix=/usr CFLAGS="-O0" ./configure --prefix=/usr CFLAGS="-O1" ./configure --prefix=/usr CFLAGS="-O2" ./conf

Re: [GENERAL] initdb of pg 9.0.13 fails on pg_authid

> Robert writes: >> I'm having some trouble installing `9.0.13`. >>> creating template1 database in /opt/pg9013/data/base/1 ... ok >>> initializing pg_authid ... FATAL: wrong number of index expressions > > Our buildfarm member anchovy has been showing similar failures for > awhile, but no other

Re: [GENERAL] initdb of pg 9.0.13 fails on pg_authid

Robert writes: > I'm having some trouble installing `9.0.13`. >> creating template1 database in /opt/pg9013/data/base/1 ... ok >> initializing pg_authid ... FATAL: wrong number of index expressions Our buildfarm member anchovy has been showing similar failures for awhile, but no others do, which

Re: [GENERAL] initdb error

I wrote: > Hah, I wondered if it might be something like that. Still, it's hard to > see how this link() would fail any security check that didn't amount to > disabling link() altogether. The UID and GID of the process, the old > file, and the directory will all match --- so exactly what rule are

Re: [GENERAL] initdb error

David Noel writes: > Ugh. It turns out I had security.bsd.hardlink_check_gid=1 and > security.bsd.hardlink_check_uid=1 in sysctl.conf. Setting them to 0 > fixed everything. That's frustrating. Sorry for all the trouble. Many > thanks for helping resolve this. Hah, I wondered if it might be someth

Re: [GENERAL] initdb error

Ugh. It turns out I had security.bsd.hardlink_check_gid=1 and security.bsd.hardlink_check_uid=1 in sysctl.conf. Setting them to 0 fixed everything. That's frustrating. Sorry for all the trouble. Many thanks for helping resolve this. On 12/15/12, Amitabh Kant wrote: > David > > I just tried instal

Re: [GENERAL] initdb error

David I just tried installing PG 9.2.2 on FreeBSD 8.3 and initdb went smoothly without any problems. the only difference would be that I had it running in a virtualbox instance. My config were as follows; FreeBSD 8.3-RELEASE-p5 (binary updated through freebsd-update) PG 9.2.2 (installed through p

Re: [GENERAL] initdb error

> You need to talk to some FreeBSD kernel hackers about why link() > might be failing here. Since you see it on UFS too, we can probably > exonerate the ZFS filesystem-specific code. > > I did some googling and found that EPERM can be issued if the filesystem > doesn't support hard links (which sh

Re: [GENERAL] initdb error

David Noel writes: > On 12/14/12, Tom Lane wrote: >> This corresponds to the execution of XLogFileInit(), and what's >> evidently happening is that we successfully create and zero-fill >> the first xlog segment file under a temporary name, but then >> the attempt to rename it into place with link

Re: [GENERAL] initdb error

On 12/14/12, Tom Lane wrote: > David Noel writes: >> I didn't have any luck with the rc script but I was able to use it to >> get a ktrace dump as root (ktrace as user pgsql doesn't seem to work). >> So hopefully that will show something(!) > > The relevant part of the ktrace output is > > 71502

Re: [GENERAL] initdb error

David Noel writes: > I didn't have any luck with the rc script but I was able to use it to > get a ktrace dump as root (ktrace as user pgsql doesn't seem to work). > So hopefully that will show something(!) The relevant part of the ktrace output is 71502 postgres CALL unlink(0x7fffc130) 7

Re: [GENERAL] initdb error

>> Interestingly, I have a second--virtually identical--server that I >> just tried initdb on. FreeBSD 8.3-RELEASE-p5, postgresql-server-9.2.2. >> Exact same "FATAL: could not open file pg_xlog" error. So it is >> reproducible. > > Does virtually identical extend to architecture, amd64? Yes... and

Re: [GENERAL] initdb error

On 12/14/2012 04:08 AM, David Noel wrote: Interestingly, I have a second--virtually identical--server that I just tried initdb on. FreeBSD 8.3-RELEASE-p5, postgresql-server-9.2.2. Exact same "FATAL: could not open file pg_xlog" error. So it is reproducible. Does virtually identical extend to

Re: [GENERAL] initdb error

On 12/13/12, David Noel wrote: > I'm running into the following error message when running initdb (FreeBSD > host): > > ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug > The files belonging to this database system will be owned by user "pgsql". > This user must also own th

Re: [GENERAL] initdb error

On Fri, Dec 14, 2012 at 4:28 PM, David Noel wrote: > > Did you use ports to install postgresql? > > Yes > > > What is the version of postgresql and freebsd you are using? > > postgresql client and server v. 9.2.2. If all else fails I could try > downgrading to a previous version of postgres. > >

Re: [GENERAL] initdb error

> Did you use ports to install postgresql? Yes > What is the version of postgresql and freebsd you are using? postgresql client and server v. 9.2.2. If all else fails I could try downgrading to a previous version of postgres. FreeBSD 8.3-RELEASE-p5 > I am getting a different output while runni

Re: [GENERAL] initdb error

> Well this has definitely moved up a support level and past anything I > know about. > For the record what version of FreeBSD are you running in case someone > is searching the archives? Any help is always appreciated. FreeBSD 8.3-RELEASE-p5. (I wonder if upgrading to 9.1 would do anything..)

Re: [GENERAL] initdb error

On Fri, Dec 14, 2012 at 3:10 AM, David Noel wrote: > On 12/13/12, Tom Lane wrote: > > David Noel writes: > >> /zdb is a zfs volume I've created for cvs and postgres. > > > > zfs eh? What happens if you point initdb at a non-zfs volume? > > > > (I"m wondering if zfs has issues with the O_DIRECT

Re: [GENERAL] initdb error

On 12/13/2012 01:40 PM, David Noel wrote: On 12/13/12, Tom Lane wrote: David Noel writes: /zdb is a zfs volume I've created for cvs and postgres. zfs eh? What happens if you point initdb at a non-zfs volume? (I"m wondering if zfs has issues with the O_DIRECT flag that we'll probably try t

Re: [GENERAL] initdb error

David Noel writes: > On 12/13/12, Tom Lane wrote: >> (I"m wondering if zfs has issues with the O_DIRECT flag that we'll >> probably try to use with pg_xlog files.) > I /boot off of a UFS volume so I created a directory there, chown and > chmod'ed it, then ran initdb again. Same error, unfortunat

Re: [GENERAL] initdb error

On 12/13/12, Tom Lane wrote: > David Noel writes: >> /zdb is a zfs volume I've created for cvs and postgres. > > zfs eh? What happens if you point initdb at a non-zfs volume? > > (I"m wondering if zfs has issues with the O_DIRECT flag that we'll > probably try to use with pg_xlog files.) I /boo

Re: [GENERAL] initdb error

David Noel writes: > /zdb is a zfs volume I've created for cvs and postgres. zfs eh? What happens if you point initdb at a non-zfs volume? (I"m wondering if zfs has issues with the O_DIRECT flag that we'll probably try to use with pg_xlog files.) regards, tom lane --

Re: [GENERAL] initdb error

David Noel writes: > On 12/13/12, Tom Lane wrote: >> You could get more information by using the --noclean switch to prevent >> removal of the datadir after failure, and then having a look at the >> debris. Is there a pg_xlog subdirectory inside /zdb/pgsql/data, and if >> so what permissions has

Re: [GENERAL] initdb error

Unfortunately no luck there. Still stick with the same error. On 12/13/12, David Noel wrote: > On 12/13/12, Adrian Klaver wrote: >> On 12/13/2012 10:47 AM, David Noel wrote: >>> On 12/13/12, Tom Lane wrote: >> >>> ygg:/usr/home/ygg> ll /zdb/pgsql/data/pg_xlog/ >>> total 2 >>> drwx-- 2 pgsq

Re: [GENERAL] initdb error

On 12/13/12, Adrian Klaver wrote: > On 12/13/2012 10:47 AM, David Noel wrote: >> On 12/13/12, Tom Lane wrote: > >> ygg:/usr/home/ygg> ll /zdb/pgsql/data/pg_xlog/ >> total 2 >> drwx-- 2 pgsql wheel 2 Dec 13 12:42 archive_status >> > > Different train of thought, away from permissions. > > H

Re: [GENERAL] initdb error

On 12/13/2012 10:47 AM, David Noel wrote: On 12/13/12, Tom Lane wrote: ygg:/usr/home/ygg> ll /zdb/pgsql/data/pg_xlog/ total 2 drwx-- 2 pgsql wheel 2 Dec 13 12:42 archive_status Different train of thought, away from permissions. How was Postgres installed? Where there any errors du

Re: [GENERAL] initdb error

On 12/13/2012 10:42 AM, David Noel wrote: You are doing the above as the database user ex:postgres? confirmed: ygg:/usr/home/ygg> whoami pgsql The database user has permissions on /zdb/pgsql/data? confirmed: ygg:/usr/home/ygg> ll /zdb/ total 3 drwxrwxrwx 3 cvswheel 3 Dec 12 15:33 c

Re: [GENERAL] initdb error

On 12/13/12, Tom Lane wrote: > David Noel writes: >> I've tried initdb directly: >> initdb -D /zdb/pgsql/data >> ...and still seem to wind up with the error: >> creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: >> could not open file "pg_xlog/00010001" (log file 0,

Re: [GENERAL] initdb error

> You are doing the above as the database user ex:postgres? confirmed: ygg:/usr/home/ygg> whoami pgsql > The database user has permissions on /zdb/pgsql/data? confirmed: ygg:/usr/home/ygg> ll /zdb/ total 3 drwxrwxrwx 3 cvswheel 3 Dec 12 15:33 cvsroot drwxrwxrwx 2 pgsql wheel 2 Dec 13

Re: [GENERAL] initdb error

On Thu, Dec 13, 2012 at 10:05 PM, Tom Lane wrote: > David Noel writes: > > I've tried initdb directly: > > initdb -D /zdb/pgsql/data > > ...and still seem to wind up with the error: > > creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: > > could not open file "pg_xlog/0001

Re: [GENERAL] initdb error

On 12/13/2012 08:35 AM, Tom Lane wrote: David Noel writes: I've tried initdb directly: initdb -D /zdb/pgsql/data ...and still seem to wind up with the error: creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file "pg_xlog/00010001" (log file 0, segm

Re: [GENERAL] initdb error

On Thu, Dec 13, 2012 at 10:00 PM, Adrian Klaver wrote: > On 12/13/2012 08:18 AM, David Noel wrote: > >> On 12/13/12, Adrian Klaver wrote: >> >>> On 12/13/2012 07:38 AM, David Noel wrote: >>> I'm running into the following error message when running initdb (FreeBSD host):

Re: [GENERAL] initdb error

David Noel writes: > I've tried initdb directly: > initdb -D /zdb/pgsql/data > ...and still seem to wind up with the error: > creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: > could not open file "pg_xlog/00010001" (log file 0, > segment 1): No such file or directo

Re: [GENERAL] initdb error

On 12/13/2012 08:18 AM, David Noel wrote: On 12/13/12, Adrian Klaver wrote: On 12/13/2012 07:38 AM, David Noel wrote: I'm running into the following error message when running initdb (FreeBSD host): ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug The files belonging to t

Re: [GENERAL] initdb error

On 12/13/12, Adrian Klaver wrote: > On 12/13/2012 07:38 AM, David Noel wrote: >> I'm running into the following error message when running initdb (FreeBSD >> host): >> >> ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug >> The files belonging to this database system will be ow

Re: [GENERAL] initdb error

On 12/13/2012 07:38 AM, David Noel wrote: I'm running into the following error message when running initdb (FreeBSD host): ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug The files belonging to this database system will be owned by user "pgsql". This user must also own the

Re: [GENERAL] initdb $PGDATA not working

On 02/09/12 2:38 PM, Daniel Vázquez wrote: YES /etc/sysconfig/pgsql/postgresql-9.1 I'm using /etc/sysconfig/pgsql/postgresql like in 8.4 ... my fault ... is like some overunderstand ... but no doc about it. whatever the name of the /etc/init.d/postgres** script is, it uses that same name

Re: [GENERAL] initdb $PGDATA not working

THX all !! My fault is I set the $PGDATA enviroment variable in /etc/sysconfig/pgsql/**postgresql like usual in 8.4 renaming the file to postgresql-9.1 solve the isue. Thanks guys! El 9 de febrero de 2012 22:25, Daniel Vázquez escribió: > Hi! > > I've set my PGDATA variable in profile > export P

Re: [GENERAL] initdb $PGDATA not working

On 02/09/12 1:25 PM, Daniel Vázquez wrote: I've set my PGDATA variable in profile export PGDATA=/home/mydata/pgsql/data Testing variable for correct set in enviroment $ echo $PGDATA /home/mydata/pgsql/data but when execute: $ sudo /etc/init.d/postgresql-9.1 initdb or execute: $ sudo /etc/init.

Re: [GENERAL] initdb $PGDATA not working

On Thursday, February 09, 2012 10:25:51 PM Daniel Vázquez wrote: > Hi! > > I've set my PGDATA variable in profile > export PGDATA=/home/mydata/pgsql/data > > Testing variable for correct set in enviroment > $ echo $PGDATA > /home/mydata/pgsql/data > > but when execute: > $ sudo /etc/init.d/postg

Re: [GENERAL] initdb $PGDATA not working

On 2/9/2012 3:25 PM, Daniel Vázquez wrote: Hi! I've set my PGDATA variable in profile export PGDATA=/home/mydata/pgsql/data Testing variable for correct set in enviroment $ echo $PGDATA /home/mydata/pgsql/data but when execute: $ sudo /etc/init.d/postgresql-9.1 initdb or execute: $ sudo /etc/

Re: [GENERAL] Initdb fails on openwrt in "creating template1 database"

Hi, > Do you have more than one device mounted and if so are you sure you are > working > on the right one? As often, the problem turned out to be a simple one. With OpenWRT, /var is just a symlink to /tmp - which itself is located on a ramdisk. After moving the data-directory to /postgresql, e

Re: [GENERAL] Initdb fails on openwrt in "creating template1 database"

On Dec 23, 2011, at 1:58 AM, Clemens Eisserer wrote: >>> There are about 800mb free space on /, any idea what could be the problem >>> here? >> >> Could you be running out of file system nodes? > > Don't think so - its a standard ext4 filesystem on a flush drive, > nothing special. > Also I've

Re: [GENERAL] Initdb fails on openwrt in "creating template1 database"

Clemens Eisserer writes: > Any idea what could be wrong here? Per-user disk space quota? And I wouldn't be so hasty to dismiss the out-of-inodes theory, either. There are not all that many ways to get an ENOSPC error. regards, tom lane -- Sent via pgsql-general mailing

  1   2   3   4   >