[BUGS] BUG #6371: Installation process
The following bug has been logged on the website: Bug reference: 6371 Logged by: Vitaly Email address: vital...@gmail.com PostgreSQL version: 9.1.2 Operating system: Windows 7 x86 Description: Installation stops after "Initialising the database..." without any alerts or other actions - just show message "Initialising the database...". I checked the data directory and all need files was there. But no account for postgres user. I waited for a long time. Then I broke installation. I've already tried to install with administrator account. No differernce. However, there is no such bug with v9.0.6. Thank you. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6370: manual does not discuss transactional DDL
The following bug has been logged on the website: Bug reference: 6370 Logged by: Ryan Culpepper Email address: r...@cs.utah.edu PostgreSQL version: Unsupported/Unknown Operating system: not applicable Description: This is a documentation bug (or feature request), not a software bug. There seems to be no discussion of transactional DDL in the manual itself (that I could find). A brief Google search turned up the following relevant pages: - http://wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis - http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL_2009 (see section "Transactional DDL") - http://archives.postgresql.org/pgsql-advocacy/2007-08/msg00273.php (and other messages in that thread) But I could not find a place in the manual that authoritatively states that DDL is transactional. (Such a page should probably also discuss things like session variables, etc.) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6372: Error while creating database with fsync parameter as on incase of CIFS
The following bug has been logged on the website: Bug reference: 6372 Logged by: Anjali Arora Email address: anjali_...@yahoo.co.in PostgreSQL version: 9.0.4 Operating system: Cent OS Description: The 8.2.2 postgres version works well with default fsync value on CIFS 2.6.32. This problem seems to be specific to postgres 9.0.4 release Error Message: PST ERROR: could not fsync file "base/16409": Invalid argument Dec 30 03:00:26 devok64-8 postgres_cifs_kaz_1[15812]: [2-2] [local] 15812 2011-12-30 03:00:26.511 PST STATEMENT: CREATE DATABASE "KazDB Please help to make it work. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6372: Error while creating database with fsync parameter as on incase of CIFS
On Mon, Jan 2, 2012 at 17:27, wrote: > The following bug has been logged on the website: > > Bug reference: 6372 > Logged by: Anjali Arora > Email address: anjali_...@yahoo.co.in > PostgreSQL version: 9.0.4 > Operating system: Cent OS > Description: > > The 8.2.2 postgres version works well with default fsync value on CIFS > 2.6.32. It does not, really. It may appear to, but it does not. > This problem seems to be specific to postgres 9.0.4 release > > Error Message: > > PST ERROR: could not fsync file "base/16409": Invalid argument Dec 30 > 03:00:26 devok64-8 postgres_cifs_kaz_1[15812]: [2-2] [local] 15812 > 2011-12-30 03:00:26.511 PST STATEMENT: CREATE DATABASE "KazDB > > Please help to make it work. PostgreSQL does not support data directory over CIFS. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: BUG #6264: Superuser does not have inherent Replication permission
On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote: > On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote: > > On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote: > > > Noah Misch writes: > > >> Let's look at the behavior of DDL-exposed access constraints for > > >> precedent. ?We > > >> currently have three paradigms for applying access control to superusers: > > > > > >> 1. Settings that affect superusers and regular users identically. ?These > > >> include > > >> ALTER ROLE ... LOGIN | VALID UNTIL. > > > > > >> 2. Rights that superusers possess implicitly and irrevocably; the actual > > >> setting > > >> recorded in pg_authid or elsewhere has no effect. ?These include GRANT > > >> ... ON > > >> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. > > > > > >> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE > > >> ROLE > > >> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. > > > > > >> I think we should merge #3 into #2; nothing about the REPLICATION setting > > >> justifies a distinct paradigm. > > > > > > Yeah, there's much to be said for that. ?I thought the notion of a > > > privilege that superusers might not have was pretty bogus to start with. > > > That seems fine for 9.2, but I am still not in favor of changing the > > behavior in back branches. This is not such a confusing behavior that > > we can't document our way out of it. > > > > (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order > > and we can document our way out of that, this is small potatoes by > > comparison.) > > Quite so. Let's do it that way. Patch attached. diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 86c2729..c5db6ef 100644 *** a/doc/src/sgml/high-availability.sgml --- b/doc/src/sgml/high-availability.sgml *** *** 797,819 archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r' It is very important that the access privileges for replication be set up so that only trusted users can read the WAL stream, because it is easy to extract privileged information from it. Standby servers must ! authenticate to the primary as an account that has the ! REPLICATION privilege. So a role with the ! REPLICATION and LOGIN privileges needs to be ! created on the primary. - - - It is recommended that a dedicated user account is used for replication. - While the REPLICATION privilege is granted to superuser - accounts by default, it is not recommended to use superuser accounts - for replication. While REPLICATION privilege gives very high - permissions, it does not allow the user to modify any data on the - primary system, which the SUPERUSER privilege does. - - - Client authentication for replication is controlled by a pg_hba.conf record specifying replication in the --- 797,810 It is very important that the access privileges for replication be set up so that only trusted users can read the WAL stream, because it is easy to extract privileged information from it. Standby servers must ! authenticate to the primary as a superuser or an account that has the ! REPLICATION privilege. It is recommended to create a ! dedicated user account with REPLICATION and LOGIN ! privileges for replication. While REPLICATION privilege gives ! very high permissions, it does not allow the user to modify any data on ! the primary system, which the SUPERUSER privilege does. Client authentication for replication is controlled by a pg_hba.conf record specifying replication in the diff --git a/doc/src/sgml/recovery-config.index 8647024..7e39c0d 100644 *** a/doc/src/sgml/recovery-config.sgml --- b/doc/src/sgml/recovery-config.sgml *** *** 325,333 restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows The connection string should specify the host name (or address) of the primary server, as well as the port number if it is not the same as the standby server's default. ! Also specify a user name corresponding to a role that has the ! REPLICATION and LOGIN privileges on the ! primary (see ). A password needs to be provided too, if the primary demands password authentication. It can be provided in the --- 325,332 The connection string should specify the host name (or address) of the primary server, as well as the port number if it is not the same as the standby server's default. ! Also specify a user name corresponding to a suitably-privileged role ! on the primary (see ). A password needs to be provided too, if the primary demands password authentication. It can be provided in the
Re: [BUGS] BUG #6372: Error while creating database with fsync parameter as on incase of CIFS
Magnus Hagander writes: > On Mon, Jan 2, 2012 at 17:27, wrote: >> PST ERROR: could not fsync file "base/16409": Invalid argument Dec 30 >> 03:00:26 devok64-8 postgres_cifs_kaz_1[15812]: [2-2] [local] 15812 >> 2011-12-30 03:00:26.511 PST STATEMENT: CREATE DATABASE "KazDB The specific error seems to be coming from copydir.c's attempt to fsync a directory. We are already ignoring EBADF there, and could presumably fix at least this symptom if we ignored EINVAL. > PostgreSQL does not support data directory over CIFS. I'm wondering what's your basis for asserting we don't support CIFS in general? It's probably not terribly bulletproof, but any worse than NFS? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6372: Error while creating database with fsync parameter as on incase of CIFS
On Mon, Jan 2, 2012 at 21:14, Tom Lane wrote: > Magnus Hagander writes: >> On Mon, Jan 2, 2012 at 17:27, wrote: >>> PST ERROR: could not fsync file "base/16409": Invalid argument Dec 30 >>> 03:00:26 devok64-8 postgres_cifs_kaz_1[15812]: [2-2] [local] 15812 >>> 2011-12-30 03:00:26.511 PST STATEMENT: CREATE DATABASE "KazDB > > The specific error seems to be coming from copydir.c's attempt to fsync > a directory. We are already ignoring EBADF there, and could presumably > fix at least this symptom if we ignored EINVAL. Sure, we could - and I guess if you're running over CIFS, reliability might not be the biggest concern in the first place... >> PostgreSQL does not support data directory over CIFS. > > I'm wondering what's your basis for asserting we don't support CIFS in > general? It's probably not terribly bulletproof, but any worse than NFS? Yes, it is a lot worse than NFS from experience. I can't find a reference to it anywhere now, but IIRC there are bigger issues - with blocksizes, with syncing not properly, with write ordering. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6372: Error while creating database with fsync parameter as on incase of CIFS
Magnus Hagander writes: > On Mon, Jan 2, 2012 at 21:14, Tom Lane wrote: >> I'm wondering what's your basis for asserting we don't support CIFS in >> general? It's probably not terribly bulletproof, but any worse than NFS? > Yes, it is a lot worse than NFS from experience. I can't find a > reference to it anywhere now, but IIRC there are bigger issues - with > blocksizes, with syncing not properly, with write ordering. Hmm. I searched the list archives and couldn't find any previous discussion of such things, but that may just prove that no one thinks it's worth attempting. Anyway the immediate question is which errnos are reasonable for copydir to ignore. Just looking at the standard's description of fsync's error conditions: The fsync() function shall fail if: [EBADF] The fildes argument is not a valid descriptor. [EINTR] The fsync() function was interrupted by a signal. [EINVAL] The fildes argument does not refer to a file on which this operation is possible. [EIO] An I/O error occurred while reading from or writing to the file system. it seems like EINVAL is a considerably more reasonable thing to return than EBADF, if the filesystem is trying to tell you that it won't fsync a directory. So I'm a bit surprised this question hasn't come up for other filesystems. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6372: Error while creating database with fsync parameter as on incase of CIFS
On Mon, Jan 2, 2012 at 21:28, Tom Lane wrote: > Magnus Hagander writes: >> On Mon, Jan 2, 2012 at 21:14, Tom Lane wrote: >>> I'm wondering what's your basis for asserting we don't support CIFS in >>> general? It's probably not terribly bulletproof, but any worse than NFS? > >> Yes, it is a lot worse than NFS from experience. I can't find a >> reference to it anywhere now, but IIRC there are bigger issues - with >> blocksizes, with syncing not properly, with write ordering. > > Hmm. I searched the list archives and couldn't find any previous > discussion of such things, but that may just prove that no one thinks > it's worth attempting. Yeah, I don't think it was in our archives, it was somewhere else. And as a disclaime r- it may have been about the win32 cifs *client*. It was at the time just talking windows cifs client -> windows cifs server. > Anyway the immediate question is which errnos are reasonable for copydir > to ignore. Just looking at the standard's description of fsync's error > conditions: > > The fsync() function shall fail if: > [EBADF] > The fildes argument is not a valid descriptor. > [EINTR] > The fsync() function was interrupted by a signal. > [EINVAL] > The fildes argument does not refer to a file on which this operation > is possible. > [EIO] > An I/O error occurred while reading from or writing to the file system. > > it seems like EINVAL is a considerably more reasonable thing to return > than EBADF, if the filesystem is trying to tell you that it won't fsync > a directory. So I'm a bit surprised this question hasn't come up for > other filesystems. Agreed. But do we really want to accept this with fsync=on? It basically means fsync=maybe, no? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6372: Error while creating database with fsync parameter as on incase of CIFS
Magnus Hagander writes: > On Mon, Jan 2, 2012 at 21:28, Tom Lane wrote: >> it seems like EINVAL is a considerably more reasonable thing to return >> than EBADF, if the filesystem is trying to tell you that it won't fsync >> a directory. So I'm a bit surprised this question hasn't come up for >> other filesystems. > Agreed. But do we really want to accept this with fsync=on? It > basically means fsync=maybe, no? Well, given the number of cases that the code already ignores when isdir is true, I don't think that argument holds much water at all. However, I'm not real eager to change this just on the basis of the CIFS case. If we find another filesystem that returns the same errno, though, I would vote to change it. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6372: Error while creating database with fsync parameter as on incase of CIFS
Excerpts from Tom Lane's message of lun ene 02 17:28:33 -0300 2012: > Anyway the immediate question is which errnos are reasonable for copydir > to ignore. Just looking at the standard's description of fsync's error > conditions: > > The fsync() function shall fail if: > [EBADF] > The fildes argument is not a valid descriptor. > [EINTR] > The fsync() function was interrupted by a signal. > [EINVAL] > The fildes argument does not refer to a file on which this operation is > possible. > [EIO] > An I/O error occurred while reading from or writing to the file system. > > it seems like EINVAL is a considerably more reasonable thing to return > than EBADF, if the filesystem is trying to tell you that it won't fsync > a directory. So I'm a bit surprised this question hasn't come up for > other filesystems. Probably because other filesystems do allow you to fsync directories. In fact for some cases they _require_ it ... remember the fiasco when MTA writers were told that they needed to fsync their queue dirs in order for all queued email to persist? -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6372: Error while creating database with fsync parameter as on incase of CIFS
Alvaro Herrera writes: > Excerpts from Tom Lane's message of lun ene 02 17:28:33 -0300 2012: >> it seems like EINVAL is a considerably more reasonable thing to return >> than EBADF, if the filesystem is trying to tell you that it won't fsync >> a directory. So I'm a bit surprised this question hasn't come up for >> other filesystems. > Probably because other filesystems do allow you to fsync directories. > In fact for some cases they _require_ it ... remember the fiasco when > MTA writers were told that they needed to fsync their queue dirs in > order for all queued email to persist? Yeah, the long and the short of it is that if the filesystem won't accept an fsync on a directory, we have to assume that it doesn't need it and will manage metadata persistence safely without prodding. The only real question here is whether an EINVAL could mean something besides "fsync on directory is not accepted". If there are any scenarios where it represents a transient/fixable error, then we'd want to report it. It's far from clear to me that there are any though. What it could mean in general is not at issue, because we know the target is a directory that we just created moments before. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
