[HACKERS] Defaut database encoding

2003-11-16 Thread Jean-Michel POURE
Dear friends, Recently, several pgAdmin3 users complained about missing accentuated characters. The problems mostly came from the ASCII database encoding, which provides arbitrary storage of accentuated characters. During installation of a Debian station, I noticed that the Debian

[HACKERS] start of transaction (was: Re: [PERFORM] Help with count(*))

2003-11-16 Thread Hannu Krosing
Redirected to -hackers Neil Conway kirjutas L, 15.11.2003 kell 22:20: Tom Lane [EMAIL PROTECTED] writes: (I believe the previous discussion also agreed that we wanted to postpone the freezing of now(), which currently also happens at BEGIN rather than the first command after BEGIN.)

Re: [HACKERS] [PATCHES] ALTER TABLE modifications

2003-11-16 Thread Rod Taylor
-- moving to -hackers Do you have special cases for type changes which don't need data transforms. I mean things like changing VARCHAR(10) to VARCHAR(20), dropping the NOT NULL constraint or changing CHECK A 3 to CHECK A 4. There are basically 3 types of change. The first is simple, a

Re: [HACKERS] start of transaction (was: Re: [PERFORM] Help with count(*))

2003-11-16 Thread Tom Lane
Hannu Krosing [EMAIL PROTECTED] writes: Probably the latest time we can start the transaction is ath the start of executor step after the first statement in a transaction is planned and optimized. The transaction has to exist before it can take locks, so the above would not fly. A complete

Re: [HACKERS] start of transaction (was: Re: [PERFORM] Help with

2003-11-16 Thread Dennis Bjorklund
On Sun, 16 Nov 2003, Tom Lane wrote: There isn't any compelling implementation reason when to freeze the value of now(). Reasonable options are 1. at BEGIN (current behavior) 2. at transaction's external creation 3. at freezing of transaction snapshot #1 and #2 are

Re: [HACKERS] cvs head? initdb?

2003-11-16 Thread Jan Wieck
Bruce Momjian wrote: I figured it should begin with debug_ or log_, maybe: debug_shared_buffers = 10 # seconds If it's just that and since nobody else seemed to care ... changed. Jan -- #==# # It's easier to get forgiveness

Re: [HACKERS] cvs head? initdb?

2003-11-16 Thread Jan Wieck
Robert Treat wrote: but how do you test this if you cant run them both against each other to compare? (initally running vs 7.4 does tell you something, but even now, 7.5 improved cross datatype index improvments could skew the results of any comparisons) Right. But with the current two

[HACKERS] interesting SIGNAL 10 (BUSERR) on CVS

2003-11-16 Thread Larry Rosenman
running 7.4RC2+ (from last week). I got the following: $ debug -ic -c core* /usr/local/pgsql/bin/postgres Warning: No debugging information in /usr/local/pgsql/bin/postgres Core image of postgres (process p1) created CORE FILE [_bt_getroot] SIGNALED 10 (bus code[BUS_OBJERR] address[0xbb12c550])

Re: [HACKERS] cvs head? initdb?

2003-11-16 Thread Bruce Momjian
Jan Wieck wrote: Robert Treat wrote: but how do you test this if you cant run them both against each other to compare? (initally running vs 7.4 does tell you something, but even now, 7.5 improved cross datatype index improvments could skew the results of any comparisons) Right.

Re: [HACKERS] interesting SIGNAL 10 (BUSERR) on CVS

2003-11-16 Thread Larry Rosenman
--On Sunday, November 16, 2003 12:59:43 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: I got the following: $ debug -ic -c core* /usr/local/pgsql/bin/postgres Warning: No debugging information in /usr/local/pgsql/bin/postgres Core image of postgres (process

Re: [HACKERS] interesting SIGNAL 10 (BUSERR) on CVS

2003-11-16 Thread Tom Lane
Larry Rosenman [EMAIL PROTECTED] writes: I got the following: $ debug -ic -c core* /usr/local/pgsql/bin/postgres Warning: No debugging information in /usr/local/pgsql/bin/postgres Core image of postgres (process p1) created CORE FILE [_bt_getroot] SIGNALED 10 (bus code[BUS_OBJERR]

Re: [HACKERS] interesting SIGNAL 10 (BUSERR) on CVS

2003-11-16 Thread Tom Lane
Larry Rosenman [EMAIL PROTECTED] writes: Is it repeatable? It's hard to see how _bt_getroot() could core except maybe in the presence of serious data corruption in the index ... it happened once, and postgres did a restart. The cronjob that triggered it (WebCalendar's sendreminders script),

Re: [HACKERS] interesting SIGNAL 10 (BUSERR) on CVS

2003-11-16 Thread Larry Rosenman
--On Sunday, November 16, 2003 13:15:27 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: Is it repeatable? It's hard to see how _bt_getroot() could core except maybe in the presence of serious data corruption in the index ... it happened once, and postgres did

[HACKERS] Bittorrent test

2003-11-16 Thread David Fetter
Kind people, I think that the bittorrent (cf http://bitconjurer.org/BitTorrent) server is ready to go at http://bt.postgresql.org. Bug/failure reports more than welcome :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100cell: +1 415 235 3778

[HACKERS] We're finally there ...

2003-11-16 Thread Marc G. Fournier
'k, I just tag'd REL7_4 and built the bundles ... the files are available under ftp://ftp.postgresql.org/pub/source/v7.4beta, and I've open'd up the ftp server there to 100 connections so that ppl can get in and test it ... It is 6:15pm AST here right now ... at ~9pm, I will move those files to

Re: [HACKERS] We're finally there ...

2003-11-16 Thread bpalmer
'k, I just tag'd REL7_4 and built the bundles ... the files are available under ftp://ftp.postgresql.org/pub/source/v7.4beta, and I've open'd up the ftp server there to 100 connections so that ppl can get in and test it ... ftp3.us.postgresql.org is in sync as well if anyone is interested.

Re: [HACKERS] start of transaction (was: Re: [PERFORM] Help with count(*))

2003-11-16 Thread Neil Conway
Hannu Krosing [EMAIL PROTECTED] writes: For me, the start of transaction is not about time, but about grouping a set of statements into one. So making the exact moment of start be the first statement that actually does something with data seems perfectly reasonable. This might be a perfectly

[HACKERS] start of transaction (was: Re: [PERFORM] Help with count(*))

2003-11-16 Thread Neil Conway
Tom Lane [EMAIL PROTECTED] writes: That's defensible when the user issued the BEGIN himself. When the BEGIN is coming from some interface library's autocommit logic, it's a lot less defensible. If you consult the archives, you will find actual user complaints about why is now() returning a

Re: [HACKERS] start of transaction (was: Re: [PERFORM] Help with count(*))

2003-11-16 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: Hmmm... I agree this behavior isn't ideal, although I can see the case for viewing this as a mistake by the application developer: they are assuming that they know exactly when transactions begin, which is not a feature provided by their language

Re: [HACKERS] start of transaction (was: Re: [PERFORM] Help with count(*))

2003-11-16 Thread Bruce Momjian
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Hmmm... I agree this behavior isn't ideal, although I can see the case for viewing this as a mistake by the application developer: they are assuming that they know exactly when transactions begin, which is not a feature provided by

[HACKERS] Release now live ...

2003-11-16 Thread Marc G. Fournier
'k, I just moved the release into the /pub/source/v7.4 directory from the v7.4beta one ... RC2 is still in place, so that I don't break a bunch of links ... tomorrow night, I'll remove the RC2 ... ---(end of broadcast)--- TIP 9: the planner will

Re: [HACKERS] start of transaction (was: Re: [PERFORM] Help with count(*))

2003-11-16 Thread Greg Stark
Neil Conway [EMAIL PROTECTED] writes: What does BEGIN actually do now, from a user's perspective? I think you're thinking about this all wrong. BEGIN doesn't do anything. It's not a procedural statement, it's a declaration. It declares that the block of statements form a transaction so reads