Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> Also, I thought Peter advocated adding -g a few releases back.
>> I don't recall any such vote.
> The vote was whether -g should be used for a default compile.
> Here is the thread disc
On Wed, 2003-10-15 at 11:43, [EMAIL PROTECTED] wrote:
> Hello,
>
> I'm a student who use postgresql. I'd like to debug postgres source code.I
> tried to use "ddd" in linux. The thing what I want to do is debugging
> backend part.How can I do that. The commands that I used until now are
> following
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I notice that most of the references in the information_schema.sql are
>> not schema-qualfied.
> They don't need to be, because the references will be resolved when the
> views are parsed during initdb.
On second thought, you do have a poi
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I notice that most of the references in the information_schema.sql are
> not schema-qualfied.
They don't need to be, because the references will be resolved when the
views are parsed during initdb.
regards, tom lane
-
I looked through all the information_schema stuff, and found a few more
nits.
I notice that most of the references in the information_schema.sql are
not schema-qualfied.
eg:
FROM (pg_namespace ncon INNER JOIN pg_constraint con ON ncon.oid
Shouldn't that be:
FROM (pg_catalog.pg_namespace ncon I
Josh Berkus <[EMAIL PROTECTED]> writes:
>> No, because it only matters to people who build from a CVS pull instead
>> of using a tarball. I'd think most of the people in the first category
>> have already dealt with the issue...
> Really? 'cause I got the warning from the Beta4 tarball.
If you
TOm,
> No, because it only matters to people who build from a CVS pull instead
> of using a tarball. I'd think most of the people in the first category
> have already dealt with the issue...
Really? 'cause I got the warning from the Beta4 tarball.
--
-Josh Berkus
Aglio Database Solutions
Josh Berkus <[EMAIL PROTECTED]> writes:
> (I predict that we're going to get many more questions about Bison after we
> release 7.4, since many major Linux distros don't yet include 1.875)
No, because it only matters to people who build from a CVS pull instead
of using a tarball. I'd think most
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Of course, this makes VACUUM run longer, and if you are waiting for it
> to finish, it would be worse, like if you are running it at night or
> something.
> I think the delay has to take into account the number of active
> transactions or something.
I wa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
> I think there are two ways this can be resolved:
> 1) Leave it this way, deal with it, but then we can put everything in one
> field and let the software parse out the first sentence automatically.
>>
>> True.
> I like the first op
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> The tool is using the output to help people create postgresql.conf.
>> The postmaster isn't running.
> But how do you alter postgresql.conf it it already exists but you don't
> know the current values?
You read postgresql.conf to
On Fri, 17 Oct 2003 09:43 am, Josh Berkus wrote:
> (I predict that we're going to get many more questions about Bison after we
> release 7.4, since many major Linux distros don't yet include 1.875)
You only need bison if you are building from CVS - tarballs include the bison
output files (AFAIK -
I looked through all the information_schema stuff, and found a few more
nits.
The CHECK_CONSTRAINTS view should use pg_get_constraintdef() function
rather than consrc, for the same reasons as psql should (I haven't fixed
the latter yet, but will soon).
There are several views that display pg_type
Peter,
> If you installed from source into /usr/local/bin and you have an older
> version in /usr/bin, you may need to run 'hash -r' or 'rehash' to make the
> shell forget about the old installation in the path.
Yeah, that was it. Thanks!
(I predict that we're going to get many more questions a
Josh Berkus writes:
> Hmmm ... still getting the "Bison Too Old" warning message. How can I tell
> where Postgres is looking for Bison?
checking for bison... bison -y
^
I tells you right there.
If you installed from source into /usr/local/bin and you have an older
vers
Peter,
> > I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't
afford
> > to upgrade right now. Does such an animal exist? Help!
>
> Install it from source if you cannot find a package.
Hmmm ... still getting the "Bison Too Old" warning message. How can I tell
where Postg
Tom Lane writes:
> > I think there are two ways this can be resolved:
> > 1) Leave it this way, deal with it, but then we can put everything in one
> > field and let the software parse out the first sentence automatically.
>
> True.
>
> > 2) Make real separate "short" and "long" descriptions.
>
>
Tom Lane writes:
> I don't have an especially good alternative though ... "--describe-config"
> is the only thought that comes to mind right away.
I like that.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and
Tom Lane writes:
> The tool is using the output to help people create postgresql.conf.
> The postmaster isn't running.
But how do you alter postgresql.conf it it already exists but you don't
know the current values?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of br
Peter Eisentraut wrote:
Josh Berkus writes:
I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford
to upgrade right now. Does such an animal exist? Help!
Install it from source if you cannot find a package.
or build from an SRPM - the dependencies are quite m
Josh Berkus writes:
> I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford
> to upgrade right now. Does such an animal exist? Help!
Install it from source if you cannot find a package.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadc
On Thu, 2003-10-16 at 16:16, Greg Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Of course, this makes VACUUM run longer, and if you are waiting for it
> > to finish, it would be worse, like if you are running it at night or
> > something.
>
> My plan was that the time delay would be
Folks,
I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford
to upgrade right now. Does such an animal exist? Help!
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searc
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Of course, this makes VACUUM run longer, and if you are waiting for it
> to finish, it would be worse, like if you are running it at night or
> something.
My plan was that the time delay would be a parameter and pg_autovacuum would
set it based on the
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Also, I thought Peter advocated adding -g a few releases back. I didn't
> > > agree, but I lost the vote, so I thought it was done. Were we
> > > supresssing -g in older releases? Peter?
> >
> > I don't r
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The vote was whether -g should be used for a default compile. Of course
> > --enable-debug would continue using -g. Maybe we kept --enable-debug
> > for backward compatibility or to force -g if you modified CFLAGS?
>
> I can't see w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The vote was whether -g should be used for a default compile. Of course
> --enable-debug would continue using -g. Maybe we kept --enable-debug
> for backward compatibility or to force -g if you modified CFLAGS?
I can't see why we would have kept --enab
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oh, makes sense. How do you propose we split this up? Do I look for
> the words \nDETAIL and \nHINT and not tab in those cases?
That won't work. I think the tab-insertion has to be done while
building the message string, earlier in send_message_to_ser
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Also, I thought Peter advocated adding -g a few releases back. I didn't
> > agree, but I lost the vote, so I thought it was done. Were we
> > supresssing -g in older releases? Peter?
>
> I don't recall any such vote. Had we done t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I thought DETAIL/HINT would be separate elog calls, and hence start at
> > the beginning of the line. Are they all in on big elog string?
>
> Yes --- that's to try to ensure that the whole mess gets written to the
> log atomically.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Also, I thought Peter advocated adding -g a few releases back. I didn't
> agree, but I lost the vote, so I thought it was done. Were we
> supresssing -g in older releases? Peter?
I don't recall any such vote. Had we done that, we'd have removed
--ena
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I just realized that --help-config doesn't output the contents of
> postgresql.conf at all, but just the internal server defaults. Does the
> admin tool read postgresql.conf too and parse that to get the runtime
> values, and how does it know if the post
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I thought DETAIL/HINT would be separate elog calls, and hence start at
> the beginning of the line. Are they all in on big elog string?
Yes --- that's to try to ensure that the whole mess gets written to the
log atomically.
rega
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > uh, since you asked. I think the logic is that, at least with gcc, -g
> > is never harmful since you can compile with -O and -g and then strip
> > later if necessary.
>
> Yeah, but ...
>
> > Does it still default to -g with compilers th
Stephen wrote:
> I think adding tunable delay per-page loop into VACUUM will help keep system
> responsive at all times. In many cases, especially for mostly read-only
> tables, plain VACUUM does not need to complete immediately (VACUUM FULL
> should complete immediately). I prefer that VACUUM take
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Agreed. I like --dump-config. Better to have the verb first.
>
> My only objection to that is that "dump" suggests you will get some kind
> of snapshot of current settings, which is not what this facility does.
>
> I don't have an
> So, pg_autovacuum does deal with them separately, but doesn't make an
> effort to spread out the vacuums if all / multiple databases happen to
> need it at the same time.
>
> In practice, I don't see this as a big problem right now, but it should
> still be handled better by pg_autovacuum.
I un
Tom Lane wrote:
> I observe that the server log is now indenting DETAIL/HINT lines:
>
> LOG: server process (PID 8468) was terminated by signal 6
> LOG: terminating any other active server processes
> WARNING: terminating connection because of crash of another server process
> DETAIL: Th
I observe that the server log is now indenting DETAIL/HINT lines:
LOG: server process (PID 8468) was terminated by signal 6
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded
On Thu, 2003-10-16 at 10:16, Rod Taylor wrote:
> > The vacuum man page says, "FREEZE is not recommnded for routine use".
> > That was enough to keep me away. However if vacuum freeze was
> > considerably lighter than normal database wide vacuums then there might
> > be an advantage to using it.
I think adding tunable delay per-page loop into VACUUM will help keep system
responsive at all times. In many cases, especially for mostly read-only
tables, plain VACUUM does not need to complete immediately (VACUUM FULL
should complete immediately). I prefer that VACUUM takes its sweet time to
run
Hello,
I'm a student who use postgresql. I'd like to debug postgres source code.I
tried to use "ddd" in linux. The thing what I want to do is debugging
backend part.How can I do that. The commands that I used until now are
following.
1. ddd postgres
2. In the ddd,I tried to attach pid. (but I can
[EMAIL PROTECTED] (Seun Osewa) wrote:
[snip]
>Sometimes I wonder why its so important to model data in the "rela-
>tional way", to think of data in form of sets of tuples rather than
>tables or lists or whatever. I mean, though its elegant and based
>on mathematical principles I would like to kn
[EMAIL PROTECTED] (Andrew Dunstan) writes:
> Tom Lane wrote:
>>James Rogers <[EMAIL PROTECTED]> writes:
>>>If we suddenly wanted to optimize Postgres for performance the way
>>>Oracle does, we would be a lot more keen on the O_DIRECT approach.
>>This isn't ever going to happen, for the simple reaso
> The vacuum man page says, "FREEZE is not recommnded for routine use".
> That was enough to keep me away. However if vacuum freeze was
> considerably lighter than normal database wide vacuums then there might
> be an advantage to using it. Especially since when pg_autovaccum
> decides it's tim
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> [ griping about autoconf's default choices for CFLAGS ]
> The philosophy of the autotools is to give power to the experienced user
> (you can set your own CFLAGS) and to give portable defaults to everyone
> else (-O is technically
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> The vacuum man page says, "FREEZE is not recommnded for routine use".
> That was enough to keep me away. However if vacuum freeze was
> considerably lighter than normal database wide vacuums then there might
> be an advantage to using it.
If an
On Thu, 2003-10-16 at 01:34, Christopher Kings-Lynne wrote:
> Hi,
>
> Was just wondering if pg_autovacuum watches transaction ids and issues a
> vacuum freeze before they roll over?
Yes pg_autovacuum monitors for xid wraparound, when it sees that you are
getting close, then it issues a database
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Christopher
Kings-Lynne) transmitted:
> Was just wondering if pg_autovacuum watches transaction ids and issues
> a vacuum freeze before they roll over?
>
> If not, is it hard to do?
It doesn't do a VACUUM FREEZE; it just doe
Tom Lane writes:
> *Yes*. This is exactly the problem, really. One could reasonably
> accuse the autoconf developers of FSF imperialism, because they have
> seen to it that autoconf-based configure scripts will choose non-optimal
> CFLAGS for non-gcc compilers. These same geeks would be screami
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Agreed. I like --dump-config. Better to have the verb first.
My only objection to that is that "dump" suggests you will get some kind
of snapshot of current settings, which is not what this facility doe
51 matches
Mail list logo
