Re: [HACKERS] #postgresql report

In line with my idea of keeping the hackers up to date with stuff in the IRC channel, here are the topics of the week: Ah yes, I forgot to add: * pg_dumpall -Fc option comes up occasionally Chris ---(end of broadcast)--- TIP 8: explain analyze is you

Re: [HACKERS] OWNER TO on all objects

There is one other consideration, and that is that current pg_dump likes to set session_auth to user of object before outputting drop command, when '-c' is specificed. I propose that we eliminate that set session_auth as well. If the user running the script is the owner of that object or a sup

Re: [HACKERS] OWNER TO on all objects

- How does the above point affect full dumps that include schema and data? In my proposal, the copy commands will run as the user running the script, not the table owner anymore. Presumably, the user running the script is a superuser. Given that it is possible for a table owner to revoke th

Re: [HACKERS] OWNER TO on all objects

That's a fair point, but you have to admit that it's a bit abstract while Chris has a real problem he needs to solve. Our dumps are awfully low on the SQL-compliance scale anyway :-( We could keep around an option for dumping the auth statements instead of alter statements perhaps. Sure, but we'

Re: [HACKERS] Improving postgresql.conf

The proposal is to remove the comments from postgresql.conf (like Apache) so all entries will be active. The downside is that it will not be possible to determine which values were modified from their defaults. One thing that truly annoys me about postgresql.conf is say I unhash an option and set

Re: [HACKERS] Improving postgresql.conf

Bruce Momjian <[EMAIL PROTECTED]> writes: > The proposal is to remove the comments from postgresql.conf (like > Apache) so all entries will be active. The downside is that it will not > be possible to determine which values were modified from their defaults. I think the latter is a nontrivial cos

Re: [HACKERS] OWNER TO on all objects

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Well, the advantage of SET SESSION AUTHORIZATION is that it is SQL > compliant, whereas ALTER OWNER is not. So I'm in favor of changing > nothing. That's a fair point, but you have to admit that it's a bit abstract while Chris has a real problem he

Re: [HACKERS] Improving postgresql.conf

Greg Sabino Mullane wrote: [ There is text before PGP section. ] > [ PGP not available, raw data follows ] > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Try yourself, I did the experiment changing the cpu_tuple_cost and > > commenting out the cpu_tuple_cost, after sending the SIGH

Re: [HACKERS] pg_restore recovery from error.

"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > Should a 7.5 pg_restore be able to read a 7.4.3 dump? Assuming so, since > doing upgrades could eb interesting if not, how far back can it go? Theoretically it will work back to 7.0, or whenever it was that Philip invented pg_restore. In practice

Re: [HACKERS] OWNER TO on all objects

Well, the advantage of SET SESSION AUTHORIZATION is that it is SQL compliant, whereas ALTER OWNER is not. So I'm in favor of changing nothing. That, however is a highly theoretical, and quite non-practical "solution". It leaves many of the world's postgresql database non-upgradable and "fixin

Re: [HACKERS] pg_restore recovery from error.

Marc G. Fournier wrote: > On Tue, 15 Jun 2004, Bruce Momjian wrote: > > > Chris Bowlby wrote: > >> Hi All, > >> > >> I've been attempting to recover some data from a data file that was > >> dumped and compressed using pg_dump. I've noticed that the pg_restore > >> application was supposed to hav

Re: [HACKERS] PITR Recovery

Simon Riggs <[EMAIL PROTECTED]> writes: > -finalaction refers to what to do when target is reached - the purpose > of this is to allow recovery of a database to occur when we don't have > enough space for all of the xlogs at once, so we need to do recovery in > batches. It seems to me that this is

Re: [HACKERS] pg_restore recovery from error.

On Tue, 15 Jun 2004, Bruce Momjian wrote: Chris Bowlby wrote: Hi All, I've been attempting to recover some data from a data file that was dumped and compressed using pg_dump. I've noticed that the pg_restore application was supposed to have some work put into place to help it continue of it ran i

Re: [HACKERS] pg_restore recovery from error.

Chris Bowlby wrote: > Hi All, > > I've been attempting to recover some data from a data file that was > dumped and compressed using pg_dump. I've noticed that the pg_restore > application was supposed to have some work put into place to help it > continue of it ran into an error, but I've run

Re: [HACKERS] Improving postgresql.conf

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Try yourself, I did the experiment changing the cpu_tuple_cost and > commenting out the cpu_tuple_cost, after sending the SIGHUP to > postmaster the value remain: 0.005 that is not the default value at > all. Ducking the added documentation d

Re: [HACKERS] initdb initial password

"Magnus Hagander" <[EMAIL PROTECTED]> writes: >>> I would like to add capability to initdb to accept the >>password for the >>> superuser account at invocation. Right now, I can use >>--pwprompt or -W >>> to have it ask for a password. But for the win32 GUI >>installed I'd like >>> to ask for t

Re: [HACKERS] pg_restore recovery from error.

In that table I'm pretty sure there are no other records, but I'm hoping there are some records for the tables stored after that particular table.. At 05:48 PM 6/15/2004, Tom Lane wrote: Chris Bowlby <[EMAIL PROTECTED]> writes: > pg_restore: restoring data for table "test_opens" > pg_restore: res

Re: [HACKERS] initdb initial password

Tom Lane said: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: >> I would like to add capability to initdb to accept the password for >> the superuser account at invocation. Right now, I can use --pwprompt >> or -W to have it ask for a password. But for the win32 GUI installed >> I'd like to ask fo

Re: [HACKERS] initdb initial password

>> I would like to add capability to initdb to accept the >password for the >> superuser account at invocation. Right now, I can use >--pwprompt or -W >> to have it ask for a password. But for the win32 GUI >installed I'd like >> to ask for the password in the installer, and pass it to initdb. >

Re: [HACKERS] initdb initial password

"Magnus Hagander" <[EMAIL PROTECTED]> writes: > I would like to add capability to initdb to accept the password for the > superuser account at invocation. Right now, I can use --pwprompt or -W > to have it ask for a password. But for the win32 GUI installed I'd like > to ask for the password in the

[HACKERS] initdb initial password

I would like to add capability to initdb to accept the password for the superuser account at invocation. Right now, I can use --pwprompt or -W to have it ask for a password. But for the win32 GUI installed I'd like to ask for the password in the installer, and pass it to initdb. Considering how it

Re: [HACKERS] #postgresql report

On Tue, 15 Jun 2004, Tom Lane wrote: > I wonder though, do the requestors actually know what they're asking for? > Are they really asking for encoding changes, or are they asking for > locale changes? Most people don't know exactly what they want. A lot of people use SQL_ASCII databases and don'

Re: [HACKERS] pg_restore recovery from error.

Chris Bowlby <[EMAIL PROTECTED]> writes: > pg_restore: restoring data for table "test_opens" > pg_restore: restoring data for table "test_unsubs" > pg_restore: [custom archiver] could not read data block -- expected 4096, > got 3870 > pg_restore: *** aborted because of error > It appears some o

[HACKERS] PITR Recovery

...on the assumption we now have archived xlogs, how do we do recovery? Default is to put all xlogs back into pg_xlog and then let recovery do its work...though clearly we all want finer specification than that. Based upon all our discussions to date...I propose to: 1. put more verbose instrument

Re: [HACKERS] pg_restore recovery from error.

Hi Vishal, Unfortunately, this is not an option for me, I'm working with a file that has 400505294 of 400513265 bytes that it can read successfully, however at that spot in the file, there is a block that is 3870 bytes long as opposed to the expected 4096 bytes. Running the command you gave me

Re: [HACKERS] #postgresql report

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Tuesday, June 15, 2004 12:04 PM > To: Peter Eisentraut > Cc: Christopher Kings-Lynne; Hackers > Subject: Re: [HACKERS] #postgresql report > > > Peter Eisentraut <[EMAIL PROTECTED]> w

Re: [HACKERS] #postgresql report

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Christopher Kings-Lynne wrote: >> * We have a request for how to change database encoding every other >> day > This is pretty much impossible. It's analogous to changing, say, the > endianness of all integers. You would need to rewrite the entire

Re: [HACKERS] OWNER TO on all objects

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Peter Eisentraut <[EMAIL PROTECTED]> writes: >>> That might change the precedence of the operator >> >> So I don't think this objection has a lot of weight. > IIRC, it was the objection that you put forth when I last attempted to

Re: [HACKERS] pg_restore recovery from error.

Dear Chris , pg_restore: [custom archiver] could not read data block -- expected 4096, got 3870 pg_restore: *** aborted because of error It appears some of the data itself is not readable, which is fine, but I'd like it to skip past this table and move onto the next one. Has anyone got any ide

Re: [HACKERS] #postgresql report

KL, > In line with my idea of keeping the hackers up to date with stuff in the > IRC channel, here are the topics of the week: You want me & David Fetter should keep a suppliment to this? Since we're on IRC while you're asleep, usually? Admittedly, most of the discussion for the last 2 days h

Re: [HACKERS] #postgresql report

On Tue, 15 Jun 2004, Peter Eisentraut wrote: Christopher Kings-Lynne wrote: * We have a request for how to change database encoding every other day This is pretty much impossible. It's analogous to changing, say, the endianness of all integers. You would need to rewrite the entire database. But

Re: [HACKERS] 7.4.3 running a bit late ...

On Tue, 15 Jun 2004, David Fetter wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: got everything built this evening, just giving it a bit of time to propogate out to the mirrors before announcing ... BitTorrent is up, and thanks for putting the tarballs on that VM :)

Re: [HACKERS] OWNER TO on all objects

Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Christopher Kings-Lynne wrote: > >> * Is there any reason there is no RENAME TO command for operators? > > > > That might change the precedence of the operator > > ... true ... > > > and get you in a big mess with stored expressions

Re: [HACKERS] OWNER TO on all objects

Christopher Kings-Lynne wrote: > The old pg_dump would output a session auth, and then wouldn't bother > changing it until necessary. However, with ALTER OWNER, I have to > dump it for every object, even if it's the same user. Well, the advantage of SET SESSION AUTHORIZATION is that it is SQL co

Re: [HACKERS] #postgresql report

Christopher Kings-Lynne wrote: > * We have a request for how to change database encoding every other > day This is pretty much impossible. It's analogous to changing, say, the endianness of all integers. You would need to rewrite the entire database. But pg_dump & restore already does that.

[HACKERS] pg_restore recovery from error.

Hi All, I've been attempting to recover some data from a data file that was dumped and compressed using pg_dump. I've noticed that the pg_restore application was supposed to have some work put into place to help it continue of it ran into an error, but I've run into an issue here it is not con

Re: [HACKERS] #postgresql report

On Tue, 2004-06-15 at 16:05, Jeff wrote: > Don't forget we get people nearly daily who are encountering problems > because Debian stable ships with 7.2. We've grown accustomed to giving > 7.4 (or at least 7.3) advice and often those things don't work on 7.2. > (such as information_schema and s

Re: [HACKERS] #postgresql report

* Jeff ([EMAIL PROTECTED]) wrote: > True enough, however it is still a common topic on the channel. It's good to let people who are asking know there's an option though. I'm on the channel too, and do let people know when I see them asking about it but I'm in 20-odd other channels. :) > Not every

Re: [HACKERS] 7.4.3 running a bit late ...

"Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > got everything built this evening, just giving it a bit of time to > propogate out to the mirrors before announcing ... BitTorrent is up, and thanks for putting the tarballs on that VM :) Cheers, D -- David Fetter [EMAIL

Re: [HACKERS] #postgresql report

On Jun 15, 2004, at 11:25 AM, Stephen Frost wrote: Back-ports of up to 7.4.2 are available for the Debian stable release at backports.org. True enough, however it is still a common topic on the channel. Not everyone is too keen on using backports either. Just reporting what I was seeing in the ch

Re: [HACKERS] #postgresql report

* Jeff ([EMAIL PROTECTED]) wrote: > Don't forget we get people nearly daily who are encountering problems > because Debian stable ships with 7.2. We've grown accustomed to giving > 7.4 (or at least 7.3) advice and often those things don't work on 7.2. > (such as information_schema and set retu

Re: [HACKERS] #postgresql report

Don't forget we get people nearly daily who are encountering problems because Debian stable ships with 7.2. We've grown accustomed to giving 7.4 (or at least 7.3) advice and often those things don't work on 7.2. (such as information_schema and set returning functions) Hopefully this will go a

Re: [HACKERS] #postgresql report

* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote: > In line with my idea of keeping the hackers up to date with stuff in the > IRC channel, here are the topics of the week: > > * We have a request for granting on all tables every other day (already > in TODO) Hopefully with options to do it

Re: [HACKERS] "An old version of the database format was found."

David Garamond <[EMAIL PROTECTED]> writes: > A very minor rant. > I usually run 7.4.1 at home, but today I need to do some testing on > 7.2.1 so I downgraded my RPM installation. When trying to start > postgresql with /etc/init.d/postgresql, it fails with this message: > "An old version of the d

Re: [HACKERS] OWNER TO on all objects

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Christopher Kings-Lynne wrote: >> * Is there any reason there is no RENAME TO command for operators? > That might change the precedence of the operator ... true ... > and get you in a big mess with stored expressions everywhere. Not with respect to