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 prevent
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 should be
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
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 the
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
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
partition (do
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 allow
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
not
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
COPY output
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
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 eyes, or at most a
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
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 number up
?
Hi,
-- Original Message ---
snip
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
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
writing
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
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
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-1) whenever you
Bruce Momjian pgman@candle.pha.pa.us 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.
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.
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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.
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?
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 0) in
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
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 pgman@candle.pha.pa.us writes:
I am a
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
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
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?
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
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
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 same as any
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
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 --
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 provide
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
value
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
that we
Josh Berkus josh@agliodbs.com 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
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
40 matches
Mail list logo
