Re: [HACKERS] Inherited constraints and search paths (was Re:

On Thu, 2005-05-19 at 23:27 -0400, Tom Lane wrote: > Berend Tober <[EMAIL PROTECTED]> writes: > > Now what, oh most wise one? > > OK, now I finally get the point: you are creating child tables in > different schemas than their parents live in. ... > Comments anyone? Best thing to do is to pre

Re: [HACKERS] Notification when freespaces empty

On Fri, 2005-05-20 at 14:41 +0900, ITAGAKI Takahiro wrote: > LOG: FreeSpace for "public.accounts" becomes empty. (stored=1, avg=159, > min=128) Looks useful to me, until we patch up FSMs more fully in the future. Might need rewording. Stored -> stored pages, Avg -> Avg Row Length. Probably shou

Re: [HACKERS] 8.02 rpm error

Well, there's not much discussion here. Other than the fact that a few things depend on libpq.so.3. Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up ? Dave Volkan YAZICI wrote: Hi, On 5/19/05, Tom Lane <[EMAIL PROTECTED]> wrote: 8.0.2 and up should provide/require libp

Re: [HACKERS] 8.02 rpm error

On Friday 20 May 2005 07:55, Dave Cramer wrote: > Well, there's not much discussion here. Other than the fact that a few > things depend on libpq.so.3. > Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up ? Only because libpq versioning has always been an afterthought in th

Re: [HACKERS] 8.02 rpm error

OK, so how do we fix this ? Dave Lamar Owen wrote: On Friday 20 May 2005 07:55, Dave Cramer wrote: Well, there's not much discussion here. Other than the fact that a few things depend on libpq.so.3. Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up ? Only bec

Re: [HACKERS] Inherited constraints and search paths (was Re: [GENERAL] Preserving data after updates)

Berend Tober <[EMAIL PROTECTED]> writes: >> On Thu, 2005-05-19 at 23:27 -0400, Tom Lane wrote: >>> OK, now I finally get the point: you are creating child tables in >>> different schemas than their parents live in. >> > The case in question was not one of the child table being in a different >

Re: [HACKERS] patches for items from TODO list

Sergey Ten wrote: > Markus, > > Thank you for your reply. > We considered embedding of an XML schema first followed by data. We decided > to stick to our current data format to make sure stateless XML parsers can > process it as well. Would it be better to add an option to the COPY command, > to a

Re: [HACKERS] Notification when freespaces empty

ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: > I think that this patch is useful to decide when to vacuum. > It notifies when freespace empties as follows: No, it doesn't complain that there is no freespace, it complains when a specific request can't be fulfilled; which for a large request might n

Re: [HACKERS] patches for items from TODO list

Neil Conway wrote: > Sergey Ten wrote: > > We think that putting it in the backend will make access from other > > components easier. > > In what way? > > It seems to me that this can be done just as easily in a client > application / library, without cluttering the backend with yet another > C

Re: [HACKERS] 8.02 rpm error

On Fri, May 20, 2005 at 09:43:50AM -0400, Dave Cramer wrote: > OK, so how do we fix this ? I don't know what is Redhat's standard practice, but in other RPM based distributions what is done is to distribute each library as its own package, using the soname as part of the package name (Debian also

Re: Learning curves and such (was Re: [HACKERS] pgFoundry)

Andrew Dunstan wrote: > Tom Lane said: > > Greg Stark <[EMAIL PROTECTED]> writes: > >> Tom Lane <[EMAIL PROTECTED]> writes: > >>> What it comes down to is that a mailing list encourages many-eyes-on- > >>> one-bug synergy, whereas Bugzilla is designed to send a bug report to > >>> just one pair of

Re: Learning curves and such (was Re: [HACKERS] pgFoundry)

On May 20, 2005, at 11:43 PM, Bruce Momjian wrote: Andrew Dunstan wrote: Actually, when BZ sends you mail, it's acting on choices that you have made, or someone at RedHat has made for you. You have a lot of control over what it sends. You want all the email? Tell BZ and you should get it. By

Re: [HACKERS] 8.02 rpm error

On Friday 20 May 2005 09:43, Dave Cramer wrote: > Lamar Owen wrote: > >On Friday 20 May 2005 07:55, Dave Cramer wrote: > >>Well, there's not much discussion here. Other than the fact that a few > >>things depend on libpq.so.3. > >>Isn't the standard to keep libpq.so.(n-1) whenever you bump the numb

Re: [HACKERS] 8.02 rpm error

Hi, -- Original Message --- > Now, the problem with 8.0.2/8.0.3 is that we forgot to bump the > soname before shipping 8.0, so we shipped a bogus libpq.so.3 which > is really libpq.so.4, with a wrong soname. How to fix? Maybe we > should provide a libpq3 package with the li

Re: Learning curves and such (was Re: [HACKERS] pgFoundry)

On Fri, May 20, 2005 at 11:59:00PM +0900, Michael Glaesemann wrote: > >Right, if you classify the information coming in, you can set controls > >over who sees it. What we don't do now is any kind of classification. > > This may be a bit off-the-wall, but I recall Joel Spolsky recently > writin

Re: [HACKERS] Two-phase commit issues

Tom Lane wrote: > I've started to look seriously at Heikki's patch for two-phase commit. > There are a few issues that probably deserve discussion: > > * The major missing issue that I've come across so far is that > subtransaction and multixact state isn't preserved across a crash. I am a little

Re: [HACKERS] [GENERAL] Image storage questions

I asked this on general, but got no answer on this particular point, maybe someone here knows. Are blobs are stored in the shared memory cache upon retrieval? I ask because we're trying to decide whether to store an enormous number of images in PostgreSQL, and I'd be concerned that frequen

Re: [HACKERS] 8.02 rpm error

Lamar Owen wrote: > On Friday 20 May 2005 09:43, Dave Cramer wrote: > > Lamar Owen wrote: > > >On Friday 20 May 2005 07:55, Dave Cramer wrote: > > >>Well, there's not much discussion here. Other than the fact that a few > > >>things depend on libpq.so.3. > > >>Isn't the standard to keep libpq.so.(n

Re: [HACKERS] Two-phase commit issues

Bruce Momjian writes: > I am a little confused by this. How does two-phase commit add extra > requirements on crash recovery? Uh, that's more or less the entire *POINT*. Once an open transaction is prepared, it's supposed to survive a server crash. regards, tom lane --

Re: [HACKERS] [GENERAL] Image storage questions

"Ed L." <[EMAIL PROTECTED]> writes: > I asked this on general, but got no answer on this particular > point, maybe someone here knows. Are blobs are stored in the > shared memory cache upon retrieval? pg_largeobject is treated exactly the same as any other table, if that's what you are asking

Re: [HACKERS] Two-phase commit issues

Tom Lane wrote: > Bruce Momjian writes: > > I am a little confused by this. How does two-phase commit add extra > > requirements on crash recovery? > > Uh, that's more or less the entire *POINT*. Once an open transaction is > prepared, it's supposed to survive a server crash. Wow. This is muc

Re: [HACKERS] Inherited constraints and search paths (was Re: [GENERAL]

Simon Riggs wrote: On Thu, 2005-05-19 at 23:27 -0400, Tom Lane wrote: Berend Tober <[EMAIL PROTECTED]> writes: Now what, oh most wise one? OK, now I finally get the point: you are creating child tables in different schemas than their parents live in. ... Comments anyone?

Re: [GENERAL] [HACKERS] Inherited constraints and search paths (was Re:

Simon Riggs <[EMAIL PROTECTED]> writes: > Doing anything to restrict dropping of inherited constraints seems like > wasted effort and potentially annoying anyhow. Uh, why? Arguably the constraints are as much part of the parent table definition as the columns themselves. If you had "check (f1 >

Re: [HACKERS] Two-phase commit issues

Bruce Momjian writes: > Tom Lane wrote: >> Uh, that's more or less the entire *POINT*. Once an open transaction is >> prepared, it's supposed to survive a server crash. > Wow. This is much more than I thought we were going to do. If we tried to claim that anything less was two-phase commit, we

Re: [HACKERS] Two-phase commit issues

Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Uh, that's more or less the entire *POINT*. Once an open transaction is > >> prepared, it's supposed to survive a server crash. > > > Wow. This is much more than I thought we were going to do. > > If we tried to claim that anythi

Re: [HACKERS] Two-phase commit issues

Bruce Momjian writes: > As I remember, you said two-phase wasn't 100% reliable and we just > needed a way to report failures. [ Shrug... ] I remain of the opinion that 2PC is a solution in search of a problem, because it does not solve the single point of failure issue (just moves same from the

Re: [HACKERS] Two-phase commit issues

Exactly.  A 2PC expects every participant that makes it to the prepare to commit phase to survive a server restart, controller or otherwise.  Anything less is not 2PC.  Jordan Henderson On Fri, 2005-05-20 at 12:07 -0400, Tom Lane wrote: Bruce Momjian writes: > I am

Re: [HACKERS] Allow change of kerberos service name without recompilation

We have modified your patch and it will appear in 8.1. Thanks. --- Daniel Ahlin wrote: > Hi > > This is a two part patch against 7.4.5 implementing the option of > configuring what is now set using the #defined constant PG

Re: [GENERAL] [HACKERS] Inherited constraints and search paths

On Fri, 2005-05-20 at 11:51 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > Doing anything to restrict dropping of inherited constraints seems like > > wasted effort and potentially annoying anyhow. > > Uh, why? Arguably the constraints are as much part of the parent table >

Re: [GENERAL] [HACKERS] Inherited constraints and search paths (was Re:

Simon Riggs <[EMAIL PROTECTED]> writes: > If you were going to fix that by adding a column that allows me to tell > the difference between inherited and non-inherited relations, that would > be a very useful piece of info for partition elimination. Inherited and non-inherited constraints you mean?

Re: [HACKERS] 8.02 rpm error

Now, the problem with 8.0.2/8.0.3 is that we forgot to bump the soname before shipping 8.0, so we shipped a bogus libpq.so.3 which is really libpq.so.4, with a wrong soname. How to fix? Maybe we should provide a libpq3 package with the libraries coming from the REL_7_4_STABLE cvs branch. I was ju

Re: [HACKERS] patches for items from TODO list

I've been reviewing this patch and some of the following discussion. First, postgresql patches are usually sent as context diffs. I don't object to unidiffs myself, but you should do what everybody else does. Second, it's best not to combine features in one patch. The \x escape piece should be b

Re: [HACKERS] [GENERAL] Image storage questions

On Friday May 20 2005 10:20 am, Tom Lane wrote: > "Ed L." <[EMAIL PROTECTED]> writes: > > I asked this on general, but got no answer on this > > particular point, maybe someone here knows. Are blobs are > > stored in the shared memory cache upon retrieval? > > pg_largeobject is treated exactly the

Re: [HACKERS] Two-phase commit issues

Tom Lane wrote: > [ Shrug... ] I remain of the opinion that 2PC is a solution in search > of a problem, because it does not solve the single point of failure > issue (just moves same from the database to the 2PC controller). > But some people want it anyway, and they aren't going to be satisfied >

Re: [HACKERS] patches for items from TODO list

Bruce Momjian wrote: We considered putting XML in psql or libpq in the past, but the problem is that interfaces like jdbc couldn't take advantage of it. Well, you could implement it as a C UDF and use SPI. Or write it as a C client library, and use JNI. Or just provide a Java implementation -- it

Re: [HACKERS] patches for items from TODO list

Neil Conway wrote: > Bruce Momjian wrote: > > We considered putting XML in psql or libpq in the past, but the problem > > is that interfaces like jdbc couldn't take advantage of it. > > Well, you could implement it as a C UDF and use SPI. Or write it as a C > client library, and use JNI. Or just

Re: [HACKERS] patches for items from TODO list

Folks, > - The COPY -> XML transformation is trivial -- it would be easy for > clients to roll their own. At the same time, there is no standard or > canonical XML representation for COPY output, and I can easily imagine > different clients needing different representations. So there is limited >

Re: [HACKERS] Two-phase commit issues

Tom, > > [ Shrug... ]  I remain of the opinion that 2PC is a solution in search > > of a problem, because it does not solve the single point of failure > > issue (just moves same from the database to the 2PC controller). > > But some people want it anyway, and they aren't going to be satisfied > >

Re: [HACKERS] patches for items from TODO list

Josh Berkus writes: > I'm going to second Neil here. I think the same --- given the points about lack of standardization, it seems premature to put this into the backend. I'd be for it if there were a clear standard, but ... regards, tom lane ---

Re: [HACKERS] patches for items from TODO list

I'm going to second Neil here. This feature becomes useful *only* when there is a certified or de-facto universal standard XML representation for database data. Then I could see a case for it. But there isn't. We've done it in phpPgAdmin (we made up our own standard), and a couple of p