On Thu, 2 Nov 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Karel, where did things stand the last time this was brought up? We
> > haven't gone beta yet, can you re-submit a patch for v7.1 before beta so
> > that we can integrate the changes?
>
> I think it would be
Hi all,
I'm one of the accidentally-subscribed readers to the Hackers list. I
mainly wanted to thank Tom for typing this up. I had a great time reading
it and learned a lot. I also wanted to try and help with some personal
experience since God knows I wouldn't be able to code in C or whatever
On Oct. 30 and 31 I attended OSDN's rather grandiosely named "Open Source
Database Summit" (despite what you might infer from the name, it was just
a small, open-to-the-public conference). Their info about the conference
is at http://www.osdn.com/conf/osd/conf_index.shtml, though I'm not sure
how
I have marked 7.0.3 release tree. The new 7.0.3 items are listed below.
I apologize for the delay.
---
Jdbc fixes (Peter)
Large object fix (Tom)
Fix lean in COPY WITH OIDS leak (Tom)
okay, to date I've just been manually fixing stuff like this, but its time
to debug what the problem is here ...
so, what have you tried to do to set it as digest, and what error did you
get?
On Thu, 2 Nov 2000 [EMAIL PROTECTED] wrote:
> >> I too got somehow on the list without subscribing.
>
>> I too got somehow on the list without subscribing.
>> Something is wrong. But I
>> like it and will stay on. :)
> Marc, not sure what you are doing over there with the
> mailing lists, but
> keep it up. :-)
Hmmm! What happened to the digest mode? I can't reset the thing.
And what happened t
> I do feel strongly about this ... 7.0.3 was considered in a release state
> *before* it was committed, pending your docs changes ... personally, if we
> leave this in contrib, my vote is to hold off the release a suitable
> amount of time for testing purposes ... Jan has added a new feature that
On Thu, 2 Nov 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > I do feel strongly about this ... 7.0.3 was considered in a release state
> > *before* it was committed, pending your docs changes ... personally, if we
> > leave this in contrib, my vote is to hold off the re
At 20:12 2/11/00 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>>> 1. What if the inherited object is a table or a sequence?
>
>> The only solution I can think of for this would be to use lastsysoid from
>> template1; this is the value set when initdb runs.
>
>How does that hel
While I see both sides, this looks like an *INTERNAL* *CORE* debate.
From a USER perspective the functionality is useful. From a Software
Development perspective, the timing stinks.
I'd leave it in /contrib, and make damn sure we get the right
functionality into the 7.1 release.
LER
* V
> > > Altho this is going to force me to agree with Tom concerning Karel's
> > > patch, it should not be added to the 7.0.x branch *at all* ... 7.0.x is a
> > > *patch* release, new features are for 7.1 and 7.1 only ...
> >
> > OK, we have votes from Lamar, Ned, Jan, and someone else to keep it in
At 19:35 2/11/00 -0500, Tom Lane wrote:
>We've hacked up pg_dump so that it won't dump objects inherited from
>template1. Unfortunately I have realized there are a couple of serious
>problems:
>
>1. What if the inherited object is a table or a sequence?
>2. For that matter, even function definiti
Philip Warner <[EMAIL PROTECTED]> writes:
>> 1. What if the inherited object is a table or a sequence?
> The only solution I can think of for this would be to use lastsysoid from
> template1; this is the value set when initdb runs.
How does that help? It won't tell you anything about updated or
On Thu, 2 Nov 2000, The Hermit Hacker wrote:
> On Thu, 2 Nov 2000, Bruce Momjian wrote:
>
> > > Ned Lilly <[EMAIL PROTECTED]> writes:
> > > > Well, here in relatively minor form is the First Example of a Great
> > > > Bridge Priority (which Tom, Bruce, and Jan have all predicted would
> > > > com
On Thu, 2 Nov 2000, Bruce Momjian wrote:
> > On Thu, 2 Nov 2000, Ned Lilly wrote:
> >
> > > We recognize this is a temporary hack - and fully expect it to go away
> > > in 7.1 We actually think that the final solution might be more
> > > appropriate in pg_dump itself than pg_dumpall, but that's o
> > Also, seems like it is hidden enough in /contrib for it to stay. While
> > I would not have added it myself, I do not feel strongly enough to
> > remove Jan's commit. However, I am not going to mention it in the 7.0.3
> > release notes.
>
> I do feel strongly about this ... 7.0.3 was consid
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> I do feel strongly about this ... 7.0.3 was considered in a release state
> *before* it was committed, pending your docs changes ... personally, if we
> leave this in contrib, my vote is to hold off the release a suitable
> amount of time for testing
On Thu, 2 Nov 2000, Bruce Momjian wrote:
> > Ned Lilly <[EMAIL PROTECTED]> writes:
> > > Well, here in relatively minor form is the First Example of a Great
> > > Bridge Priority (which Tom, Bruce, and Jan have all predicted would
> > > come... ;-)
> >
> > Hmm. I wasn't aware that Jan had don
> On Thu, 2 Nov 2000, Ned Lilly wrote:
>
> > We recognize this is a temporary hack - and fully expect it to go away
> > in 7.1 We actually think that the final solution might be more
> > appropriate in pg_dump itself than pg_dumpall, but that's obviously a
> > much more breakable proposition (hen
On Thu, 2 Nov 2000, Tom Lane wrote:
> Ned Lilly <[EMAIL PROTECTED]> writes:
> > Well, here in relatively minor form is the First Example of a Great
> > Bridge Priority (which Tom, Bruce, and Jan have all predicted would
> > come... ;-)
>
> Hmm. I wasn't aware that Jan had done it at Great Bri
On Thu, 2 Nov 2000, Ned Lilly wrote:
> We recognize this is a temporary hack - and fully expect it to go away
> in 7.1 We actually think that the final solution might be more
> appropriate in pg_dump itself than pg_dumpall, but that's obviously a
> much more breakable proposition (hence the separ
We've hacked up pg_dump so that it won't dump objects inherited from
template1. Unfortunately I have realized there are a couple of serious
problems:
1. What if the inherited object is a table or a sequence? Its state may
no longer be the same as it was in template1 (eg, a table may contain
mor
> On Wed, 1 Nov 2000, Bruce Momjian wrote:
>
> > Yes, sorry about the delay. Also, I will send a report to core about
> > the summit.
>
> is there a reason why -hackers wouldn't be interested as well? *raised
> eyebrow*
Good question. I have some analysis of how other open-source database
do
On Wed, 1 Nov 2000, Bruce Momjian wrote:
> Yes, sorry about the delay. Also, I will send a report to core about
> the summit.
is there a reason why -hackers wouldn't be interested as well? *raised
eyebrow*
>
> >
> > sounds great, then hopefully we get v7.0.3 out early next week :) thanks
>
On Thu, 2 Nov 2000, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > I do have a question -- just how much configuration (and other) changes
> > occurred to REL7_0_PATCHES (since the logs seem to not be telling the
> > whole story)?
> > I say this because I found at least one such cha
HI,
I want to return a record from a FUNCTION in plpgsql procedural language.
There are very few examples to go by.
It doesn't accept RETURN RECORD.
I've tried
making a record in the declare section and returning OPAQUE.
TYPE temp IS RECORD
(id int4,
name varchar(50),
);
It gives the error java.s
On Fri, 3 Nov 2000, Hiroshi Inoue wrote:
> PL/pgSQL already prepares a plan at the first execution
> time and executes the plan repeatedly after that.
> We would have general PREPARE/EXECUTE feature in the
> near fututre. IMHO another mechanism to detect plan invali
> dation is needed.
Excellent
At 11:33 2/11/00 -0500, Tom Lane wrote:
>> Conn1: Begin
>> Conn1: lo_create/lo_close/lo_write.../lo_close
>> Conn2: Insert into xref table (which does an implicit begin/end, I think).
>> Conn1: Commit;
>
>Two connections?
Otherwise a reconnect will lose the temp table contents.
Denis Perchine <[EMAIL PROTECTED]> writes:
> When I run 2 vacuum's in parallel they hangs. Both.
> I use PostgreSQL from 7.0.x CVS (almost 7.0.3).
Hm. I don't see a hang, but I do see errors like
NOTICE: Deadlock detected -- See the lock(l) manual page for a possible cause.
ERROR: WaitOnLock:
> I'm looking at some point in time in the future doing a
> 'postgresql-upgrade' RPM that would include pre-built postmasters and
> other binaries necessary to dump any previous version PostgreSQL (since
> about 6.2.1 or so -- 6.2.1 was the first RedHat official PostgreSQL RPM,
> although there w
Tom Lane wrote:
> What really got my ire up was that this change was committed several
> days *after* core had agreed that 7.0.3 was frozen and ready to go except
> for updating the changelog, and that it was committed with no prior
Now that I've seen the back story, I must agree.
> The early r
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Doesn't current heap_open() have a flaw that even the first
> use of a relation in a transaction may cause an error
> "relation ### modified while in use" ?
Sure, that was the starting point of the discussion.
>> because that will open us up to fail
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I want it removed from 7.1 /contrib. I will do that now myself.
>
> Looks like Peter has already eliminated the need for it for 7.1 ;-).
> What remains to discuss is just whether we want it as a contrib item
> in 7.0.3.
>
> As several people menti
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Do we have a conclusion about this thread ?
> > If no,how about changing heap_open(r) so that they allocate
> > Relation descriptors after acquiring a lock on the table ?
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I want it removed from 7.1 /contrib. I will do that now myself.
Looks like Peter has already eliminated the need for it for 7.1 ;-).
What remains to discuss is just whether we want it as a contrib item
in 7.0.3.
As several people mentioned, it's harml
Me as well!!!
[EMAIL PROTECTED]
- r
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jade Rubick
> Sent: November 2, 2000 9:27 AM
> To: PostgreSQL-development
> Subject: [HACKERS] Another remove request
>
>
> I too have tried to remove myself fro
> Ned Lilly <[EMAIL PROTECTED]> writes:
> > Well, here in relatively minor form is the First Example of a Great
> > Bridge Priority (which Tom, Bruce, and Jan have all predicted would
> > come... ;-)
>
> Hmm. I wasn't aware that Jan had done it at Great Bridge's request,
> and I am going to ma
Ned Lilly <[EMAIL PROTECTED]> writes:
> Well, here in relatively minor form is the First Example of a Great
> Bridge Priority (which Tom, Bruce, and Jan have all predicted would
> come... ;-)
Hmm. I wasn't aware that Jan had done it at Great Bridge's request,
and I am going to make a point of
Ned Lilly writes:
> That's what this pg_dumpaccounts is designed to do. As you've seen,
> it's very simple - it does the same COPY stuff that pg_dumpall does
> before calling pg_dump, just without the pg_dump.
I only wonder since when the solution to a problem of the nature "I need a
program
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> DEBUG: Data Base System is in production state at Thu Nov 2 20:28:26 2000
> NOTICE: Cannot create init file pg-install/var/data/base/1/pg_internal.init.10037:
>No such file or directory
> Continuing anyway, but there's something wrong.
> N
Lamar Owen <[EMAIL PROTECTED]> writes:
> All I'm saying is that regression should be _runnable_ in all modes
> without needing anything but a shell and the PostgreSQL binary
> installation.
I think this'd be mostly a waste of effort. IMHO, 99% of the problems
the regression tests might expose wi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, your feelings on this? Does Lamar's argument change anything?
Not for me. I understand Lamar's concern, but the time to be responding
to it was two weeks ago, not today. 7.0.3 is long overdue already ---
and in fact would be out now, had you not
Ned Lilly wrote:
> Our feeling is that DBAs will want to have the ability to backup user
> and group info, which you currently can't do with pg_dump. You *can* do
> it with pg_dumpall - but only if you dump every database you've got at
> the same time. Picture a professional environment where y
On Thu, 2 Nov 2000, Bruce Momjian wrote:
> > I understand everyone's hesitation about adding a new utility this late
> > in the process - and we're happy to be overruled on that (even if it's a
> > discrete piece of code that wouldn't affect anything else...) I'm not
> > wild about putting it in
Well, here in relatively minor form is the First Example of a Great
Bridge Priority (which Tom, Bruce, and Jan have all predicted would
come... ;-)
Our feeling is that DBAs will want to have the ability to backup user
and group info, which you currently can't do with pg_dump. You *can* do
it
> I understand everyone's hesitation about adding a new utility this late
> in the process - and we're happy to be overruled on that (even if it's a
> discrete piece of code that wouldn't affect anything else...) I'm not
> wild about putting it in /contrib, but if that's what everyone wants to
On Jue 02 Nov 2000 15:27, you wrote:
> Martin A. Marques writes:
> > Are there any status and mode applications for postgres? I mean, an
> > application that will tell me the status of the server at the moment,
> > and an app to start and stop postgres.
>
> pg_ctl
Yes, I have just been checking
Tom, your feelings on this? Does Lamar's argument change anything?
I agree this is not optimial, and see arguments against its inclusion
even in /contrib.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think the issue is that we don't want to risk breaking pg_dumpall in a
> > minor release.
Bruce Momjian wrote:
> > However, the dependency upon the new version of the OS being able to run
> > the old executables could be a killer in the future if executable
> > compatibility is removed -- after all, an upgrade might not be from the
> > immediately prior version of the OS.
> That is a
Lamar Owen <[EMAIL PROTECTED]> writes:
> Now, J Random slides in the new OS CD on a backup of his main server,
> and upgrades. RedHat 7.2's installer is very smart -- if no packages
> are left that use glibc 2.0, it doesn't install the compat-libs
> necessary for glibc 2.0 apps to run.
Actually
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think the issue is that we don't want to risk breaking pg_dumpall in a
> minor release.
No we don't, but I agree with Peter that pg_dumpall is the place for
this feature in the long run. A separate contrib script is not going
to get maintained.
What
Bruce Momjian wrote:
> I think the issue is that we don't want to risk breaking pg_dumpall in a
> minor release.
> Comments?
For 7.0.x, let's leave pg_dumpall alone -- it's too important to risk
breakage without extensive beta testing prior to release. An added
contrib utility is not a problem
I think the issue is that we don't want to risk breaking pg_dumpall in a
minor release.
Comments?
> > Added utility script pg_dumpaccounts to contrib.
> >
> > Derived from pg_dumpall it just dumps users and groups.
>
> We can do the same thing with a 5-line change in pg_dumpall. We don't
> ne
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Karel, where did things stand the last time this was brought up? We
> haven't gone beta yet, can you re-submit a patch for v7.1 before beta so
> that we can integrate the changes?
I think it would be a very bad idea to try to integrate the query ca
> Bruce Momjian wrote:
> > > At the risk of being redundant, here goes. As I've explained before,
> > > the RPM upgrade environment, thanks to our standing with multiple
> > > distributions as being shipped as a part of the OS, could be run as part
>
> > OK, maybe doing it in an RPM is the wron
> I too got somehow on the list without subscribing. Something is wrong. But I
> like it and will stay on. :)
Marc, not sure what you are doing over there with the mailing lists, but
keep it up. :-)
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
I too got somehow on the list without subscribing. Something is wrong. But I
like it and will stay on. :)
Bob Kernell
Research Scientist
Surface Validation Group
Atmospheric Sciences Competency
Analytical Services & Materials, Inc.
email: [EMAIL PROTECTED]
tel: 757-827-4631
Hi All,
I am new here . I have been working alone in my
underground lab away from the world shunning any
contact with Postgre Community( not intentional) and
testing out mine and postgre's limits but I have run
into this stumbling block ..
Enough kidding..;-)
Yes I am new and I want to instal
On Mié 01 Nov 2000 20:57, Martin A. Marques wrote:
Seeing that nobody responded to my questions, here I go. ;-)
I think one of the poor partes about postgres is the administration tools. I
am not a PostgreSQL hacker (would like to be one) so I don know if there are
things like user threads, lo
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > I say this because I found at least one such change -- REL7_0_PATCHES,
> > unlike 7.0.2, has an '--enable-syslog' configure switch.
> That's probably the only one, since by back-patching it Marc was
> violating one of our standard rule
Lamar Owen <[EMAIL PROTECTED]> writes:
> I do have a question -- just how much configuration (and other) changes
> occurred to REL7_0_PATCHES (since the logs seem to not be telling the
> whole story)?
> I say this because I found at least one such change -- REL7_0_PATCHES,
> unlike 7.0.2, has an '
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > I think that at least 1 & 2 from WAL todo (checkpoints and port to
> > machines without TAS) is required before beta.
>
> I'm not sure that you do need to add support for machines without TAS.
> I pointed out a couple months ago that the non-TAS
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
>> basis of 10%-or-so fetch
> I'd say that normally you're not using cursors because you intend to throw
> away 80% or 90% of the result set, but instead you'r
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Do we have a conclusion about this thread ?
> If no,how about changing heap_open(r) so that they allocate
> Relation descriptors after acquiring a lock on the table ?
> We would use LockRelation() no longer.
That won't do by itself, because that will op
I too have tried to remove myself from this list. I've tried
pgsql-hackers-request, and I've emailed pgsql-hackers-owner
My email address is [EMAIL PROTECTED] and also [EMAIL PROTECTED] . I can only
email from the second, but I'd like to remove myself from the first. Can
someone help me out, plea
> Denis Perchine <[EMAIL PROTECTED]> writes:
> > Small technical question: what exactly CommandCounterIncrement do?
>
> It increments the command counter ;-)
>
> > And what exactly it should be used for?
>
> You need it if, within a chunk of backend code, you want subsequent
> queries to see the r
Denis Perchine <[EMAIL PROTECTED]> writes:
> Small technical question: what exactly CommandCounterIncrement do?
It increments the command counter ;-)
> And what exactly it should be used for?
You need it if, within a chunk of backend code, you want subsequent
queries to see the results of earli
Philip Warner <[EMAIL PROTECTED]> writes:
> This is for pg_dump which, when restoring BLOBs, inserts multiple rows into
> a temporary xref table. The sequence of events is:
> Conn1: Begin
> Conn1: lo_create/lo_close/lo_write.../lo_close
> Conn2: Insert into xref table (which does an implicit begi
Peter Eisentraut wrote:
>
> Bruce Momjian writes:
> > And am seeing entries like below. Can someone please explain why I am
> > seeing stuff committed in current?
> You might want to check out cvs2cl
> (http://www.red-bean.com/kfogel/cvs2cl.shtml). It sems to work nicely and
> you get much ni
Bruce Momjian wrote:
> > At the risk of being redundant, here goes. As I've explained before,
> > the RPM upgrade environment, thanks to our standing with multiple
> > distributions as being shipped as a part of the OS, could be run as part
> OK, maybe doing it in an RPM is the wrong way to go.
On Thu, 2 Nov 2000, Zeugswetter Andreas SB wrote:
>
> > Well I can re-write and resubmit this patch. Add it as a
> > compile time option
> > is not bad idea. Second possibility is distribute it as patch
> > in the contrib
> > tree. And if it until not good tested not dirty with this main tree
Hello,
My previous mail about VACUUM deadlock was silently ignored...
Now I have much more interesting trouble...
Just a minutes ago I found out that my usual routine which recreate indices
is hanged... I see the picture like this:
10907 ?SW 0:01 /home/postgres/bin/postgres 127.0.0
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> I think that at least 1 & 2 from WAL todo (checkpoints and port to
> machines without TAS) is required before beta.
I'm not sure that you do need to add support for machines without TAS.
I pointed out a couple months ago that the non-TAS support code
"Kevin O'Gorman" <[EMAIL PROTECTED]> writes:
> I'm about to launch into an experiment that will do some new things
> inside the PG server. I'm sure to have a lot of problems, and one
> of them I can already tell is going to be difficult is the business
> of contexts: memory contexts, scan context
Pam Withnall <[EMAIL PROTECTED]> writes:
> When i call the function from sql
> SELECT sptest3(4) AS x;
> I get the error:
> "NOTICE: plpgsql: ERROR during compile of sptest3 near line 1
> "RROR: parse error at or near "
The message looks just like that, eh? I bet it's unhappy because your
fun
> Well I can re-write and resubmit this patch. Add it as a
> compile time option
> is not bad idea. Second possibility is distribute it as patch
> in the contrib
> tree. And if it until not good tested not dirty with this main tree...
>
> Ok, I next week prepare it...
One thing that worries
76 matches
Mail list logo
