[ADMIN] changing default object rights
Dear colleagues, For the last few hours I tried to implement $subj, to no avail. I tried to use create rule (no grant statement allowed), create function (syntax error on $1), etc. I have roles mng and rdr, and want that any newly created class (table, view, seq, index) will be available for wrining to mng and for queriyng to rdr. Any hints? Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[ADMIN] Getting "ERROR: canceling autovacuum task"
I'm getting this loading some large (1 million row) tables. Is this anything to be concerned about? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] Postgres Backup and Restore
> Are you sure that the destination database has the same encoding > declaration as the source did? That's what I'd be looking at - I had similar problems a few weeks ago. See this thread: http://archives.postgresql.org/pgsql-admin/2007-12/msg00235.php THINK BEFORE YOU PRINT - Save paper if you don't really need to print this ***Confidentiality and Privilege Notice*** The material contained in this message is privileged and confidential to the addressee. If you are not the addressee indicated in this message or responsible for delivery of the message to such person, you may not copy or deliver this message to anyone, and you should destroy it and kindly notify the sender by reply email. Information in this message that does not relate to the official business of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta. Weatherbeeta, its employees, contractors or associates shall not be liable for direct, indirect or consequential loss arising from transmission of this message or any attachments e-mail. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Postgres Backup and Restore
> > Are you sure that the destination database has the same encoding > > declaration as the source did? > > That's what I'd be looking at - I had similar problems a few weeks ago. > See > this thread: > http://archives.postgresql.org/pgsql-admin/2007-12/msg00235.php I've been thinking about this, and while I don't agree it's a bug, I think that perhaps PostgreSQL should raise a notice or warning that the destination database has different encoding than the file being restored...? Obviously I'm not the only one (seemingly) caught out by this so I'm sure it would save some heartache for people. THINK BEFORE YOU PRINT - Save paper if you don't really need to print this ***Confidentiality and Privilege Notice*** The material contained in this message is privileged and confidential to the addressee. If you are not the addressee indicated in this message or responsible for delivery of the message to such person, you may not copy or deliver this message to anyone, and you should destroy it and kindly notify the sender by reply email. Information in this message that does not relate to the official business of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta. Weatherbeeta, its employees, contractors or associates shall not be liable for direct, indirect or consequential loss arising from transmission of this message or any attachments e-mail. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] Postgres Backup and Restore
> "Phillip Smith" <[EMAIL PROTECTED]> writes: > > I've been thinking about this, and while I don't agree it's a bug, I > think > > that perhaps PostgreSQL should raise a notice or warning that the > > destination database has different encoding than the file being > restored...? > > If Postgres actually *knows* that the encodings are different, it can > deal with that. The cases that are problematic are where the software > has been misinformed for one reason or another. I doubt that a warning > issued (or not) on the basis of misinformation will be especially helpful. How has the software been misinformed and how can we avoid it then? :) The start of the pgdump sets the client encoding, so shouldn't that tell PG that things could get strange? THINK BEFORE YOU PRINT - Save paper if you don't really need to print this ***Confidentiality and Privilege Notice*** The material contained in this message is privileged and confidential to the addressee. If you are not the addressee indicated in this message or responsible for delivery of the message to such person, you may not copy or deliver this message to anyone, and you should destroy it and kindly notify the sender by reply email. Information in this message that does not relate to the official business of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta. Weatherbeeta, its employees, contractors or associates shall not be liable for direct, indirect or consequential loss arising from transmission of this message or any attachments e-mail. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [ADMIN] Postgres Backup and Restore
"Phillip Smith" <[EMAIL PROTECTED]> writes: > I've been thinking about this, and while I don't agree it's a bug, I think > that perhaps PostgreSQL should raise a notice or warning that the > destination database has different encoding than the file being restored...? If Postgres actually *knows* that the encodings are different, it can deal with that. The cases that are problematic are where the software has been misinformed for one reason or another. I doubt that a warning issued (or not) on the basis of misinformation will be especially helpful. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] Getting "ERROR: canceling autovacuum task"
Dean Gibson (DB Administrator) wrote: > I'm getting this loading some large (1 million row) tables. Is this > anything to be concerned about? No, it's normal. It means the autovacuum task was cancelled in order to avoid blocking your regular Postgres sessions. If it's only during table loading, there's no problem -- the table will be processed later eventually. If it happens all the time, I would advise setting a cron job to carry out the vacuum task. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] Postgres Backup and Restore
"Phillip Smith" <[EMAIL PROTECTED]> writes: > How has the software been misinformed and how can we avoid it then? :) Well, if that were entirely clear then we could fix it. > The start of the pgdump sets the client encoding, so shouldn't that tell PG > that things could get strange? The problems seem to arise when the data doesn't actually have the claimed encoding. We've been gradually tightening the encoding checks over the years, so data that older versions let pass without comment might now be recognized as malformed. In the OP's case there may be something else going on (such as an actual encoding-conversion bug). I've encouraged him to try to trace things forward from his original input data and see if we can find out exactly where it went off the rails. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
