On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Uh, no ... the global setting of add_missing_from does *not* tell you
>>> anything about whether there exist views in the database that were
Hi Hackers,
I found that bgwriter increments usage count of buffers when it writes
the buffers. I feel this behavior is strange, because the behavior of
bgwriter will affect buffer management strategy.
When backends write LRU dirty buffers, they are replaced immediately.
However, when bgwriter wri
TODO item done for 8.2:
* Add PQescapeIdentifier() to libpq
Someone probably needs to check this :)
Chris
libpq.txt.gz
Description: GNU Zip compressed data
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Uh, no ... the global setting of add_missing_from does *not* tell you
>> anything about whether there exist views in the database that were
>> created under a different setting.
> I realize that;
How about it's in the release notes and in adddepend?
Hmm, it's currently early Wednesday morning my time, and we were
thinking of wrapping RC1 Thursday or Friday. An adddepend extension
is going to get coded and tested when exactly?
Fair enough.
Also, I'm dubious about the assumption that
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Also, consider people upgrading from 7.2 to 8.1. They should only have
> to run the adddepend script to get ALL the dependencies, right?
This isn't a "dependency" though.
> How about it's in the release notes and in adddepend?
Hmm, it's cur
On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> Wild idea: how about having pg_dump include SET add_missing_from = true;
>> in the dump file if, and only if, it is set that way in the server?
>
> Uh, no ... the global setting of add_missing_fro
Should we not just make this part of contrib/adddepend?
Uh, I thought adddepend did more than just sequence dependencies, and I
Yes it does...
am worried it might mess up someone's database.
Adddepend has been around for a long time - seems to work perfectly.
Also, by doing it
manually,
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> Wild idea: how about having pg_dump include SET add_missing_from = true;
> in the dump file if, and only if, it is set that way in the server?
Uh, no ... the global setting of add_missing_from does *not* tell you
anything about whether there exist v
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2005-25-10 at 17:43 -0400, Tom Lane wrote:
>> What I suggest we do about this is change addImplicitRTE() to set
>> inFromCl true for implicitly added RTEs, so that the view rule will
>> later be dumped as if the query had been written per spec.
> S
Martijn van Oosterhout writes:
> Currently createlang and droplang use these two files mbprint.c and
> print.c to access the function printQuery() just to handle the
> displaying of the current languages. Is there any particular reason why
> it can't be made to use the version in libpq?
I believe
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I notice that in the release notes there is a large query that should be
> run if upgrading from prior to 8.1, to ensure that sequence dependencies
> are recorded.
> Should we not just make this part of contrib/adddepend?
No ... this is not a
Christopher Kings-Lynne wrote:
> Hi,
>
> I notice that in the release notes there is a large query that should be
> run if upgrading from prior to 8.1, to ensure that sequence dependencies
> are recorded.
>
> Should we not just make this part of contrib/adddepend?
Uh, I thought adddepend did m
Has the sql compatibiliy list been updated? eg. for BETWEEN SYMMETRIC?
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/sql_features.txt
All signs point to "Sort of not really".
Someone more knowledgeable than me will have to update it I think.
These look like likely ca
2. Revert the change to make add_missing_from default as false, and
wait a few more releases before making it default.
+1
No skin off our nose. What do we care if the default changes in a few
releases time - however there are probably many end-users who will see
problems upgrading...
Chris
Hi,
I notice that in the release notes there is a large query that should be
run if upgrading from prior to 8.1, to ensure that sequence dependencies
are recorded.
Should we not just make this part of contrib/adddepend?
Chris
---(end of broadcast)---
On 2005-10-25, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-10-25 at 17:43 -0400, Tom Lane wrote:
>
>> 1. Tell people they may have to set add_missing_from = true to reload
>> a dump that contains such views.
>>
>> 2. Revert the change to make add_missing_from default as false, and
>> wai
On Tue, 2005-10-25 at 17:43 -0400, Tom Lane wrote:
> 1. Tell people they may have to set add_missing_from = true to reload
> a dump that contains such views.
>
> 2. Revert the change to make add_missing_from default as false, and
> wait a few more releases before making it default.
>
> Comments?
On Tue, 2005-25-10 at 17:43 -0400, Tom Lane wrote:
> What I suggest we do about this is change addImplicitRTE() to set
> inFromCl true for implicitly added RTEs, so that the view rule will
> later be dumped as if the query had been written per spec.
Sounds reasonable. I wonder if this should be ba
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> Robert Treat wrote:
>> ISTM even a GUC to enable/disable would have been better scheme than
>> what we have now; we are basically leaving no options for those who
>> found the old behavior useful, while what we had before would at least
>> let people
Sample case:
regression=# create table t1(f1 int, f2 int);
CREATE TABLE
regression=# set add_missing_from = true;
SET
regression=# create view v1 as select t1.*;
NOTICE: adding missing FROM-clause entry for table "t1"
CREATE VIEW
regression=# \d v1
View "public.v1"
Column | Type | Modi
Robert Treat wrote:
On Tue, 2005-10-25 at 14:51, Bruce Momjian wrote:
Good point. We modified 8.1 so backslash commands do not honor \x
because things like \d look silly in \x, but \df+ looks better with \x,
no question.
Ideally I think \x should allow three modes, on, off, and auto, with
au
On Tue, 2005-10-25 at 14:51, Bruce Momjian wrote:
>
> Good point. We modified 8.1 so backslash commands do not honor \x
> because things like \d look silly in \x, but \df+ looks better with \x,
> no question.
>
> Ideally I think \x should allow three modes, on, off, and auto, with
> auto doing \
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> Currently createlang and droplang use these two files mbprint.c and
> print.c to access the function printQuery() just to handle the
> displaying of the current languages. Is there any particular reason why
> it can't be made to use th
Josh Berkus writes:
>> I tested the db files residing on a software RAID-1 composed of 2 IDE
>> 7200rpm drives on linux 2.6.12.
>
> FWIW, most performance-conscious users will be using a SCSI RAID
> array.
No worry, I'm not out to squeeze every little juice from a particular
installation, which
On Tue, 2005-10-25 at 14:42, Michael Fuhr wrote:
> On Tue, Oct 25, 2005 at 02:27:50PM -0400, Robert Treat wrote:
> > not sure exactly when this was changed, but expanded display of \df+
> > output is broken in beta4.
>
> http://archives.postgresql.org/pgsql-hackers/2005-06/msg00423.php
> http://ar
Currently createlang and droplang use these two files mbprint.c and
print.c to access the function printQuery() just to handle the
displaying of the current languages. Is there any particular reason why
it can't be made to use the version in libpq?
In particular, does anyone really rely on the pos
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Tue, Oct 25, 2005 at 02:51:04PM -0400, Bruce Momjian wrote:
> >
> > Good point. We modified 8.1 so backslash commands do not honor \x
> > because things like \d look silly in \x, but \df+ looks better with \x,
> > no question.
> >
In continuation of my previous mails.
Till now what all i figured out about the query flow in postgres has
suddenly zeroed.
Reason: analyze...
till now i was running query with out analyaze command but once you give
it ...i dont knw whts the
path query takes.Any body havign any idea.
AnujT
--
On Tue, Oct 25, 2005 at 02:51:04PM -0400, Bruce Momjian wrote:
>
> Good point. We modified 8.1 so backslash commands do not honor \x
> because things like \d look silly in \x, but \df+ looks better with \x,
> no question.
>
> Ideally I think \x should allow three modes, on, off, and auto, with
>
Good point. We modified 8.1 so backslash commands do not honor \x
because things like \d look silly in \x, but \df+ looks better with \x,
no question.
Ideally I think \x should allow three modes, on, off, and auto, with
auto doing \x if the row output is wider than the screen. If we had
this, b
On Tue, Oct 25, 2005 at 02:27:50PM -0400, Robert Treat wrote:
> not sure exactly when this was changed, but expanded display of \df+
> output is broken in beta4.
http://archives.postgresql.org/pgsql-hackers/2005-06/msg00423.php
http://archives.postgresql.org/pgsql-committers/2005-06/msg00149.php
Seneca Cunningham wrote:
> On an powerPC AIX 5.3 box, initdb from 8.1beta4 segfaults at
> src/backend/utils/hash/dynahash.c:673. No segfaults occur and all 98
> regression tests pass if a test is added to see if keycopy is memcpy and
> if it is, go through a loop memcpying one byte at a time inste
not sure exactly when this was changed, but expanded display of \df+
output is broken in beta4. compare:
[EMAIL PROTECTED] data]$ /usr/local/pgsql-8.1.x/bin/psql -p 5481
template1
Welcome to psql 8.1beta4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h fo
Yohanes,
> Yesterday in #pgsql, I was talking with neilc about determining rpc
> value in a more concrete way. So I created a program that compares
> exhaustive (all blocks are eventually read) random reads with
> sequential reads. The full source is attached.
Thanks for code.
> I tested the db
[To admin: this message was posted earlier via google group. needless
to say, it was stalled waiting for approval, please ignore that
one. Thanks.]
Hi,
Yesterday in #pgsql, I was talking with neilc about determining rpc
value in a more concrete way. So I created a program that compares
exhaustive
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> Are we all comfortable that
>>> http://archives.postgresql.org/pgsql-hackers/2005-10/msg01009.php
>>> is OK to apply?
>>
>> Yea. I can vouch for Magnus as well (he said so off list).
>> I'd vote with my own servers anyways.
> Yup, and I can also
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > On Tue, 18 Oct 2005, Tom Lane wrote:
> > >> Looking at the code, I notice that the messages are all emitted at level
> > >> NOTICE. Perhaps that was not such a good idea --- it'd be pretty much
> > >>
daveg <[EMAIL PROTECTED]> writes:
> I work with a client that runs 16Gb memory with 16Gb of swap on dual opterons
> dedicated to postgres. They have large tables and like hash joins as they are
> often the fastest way to a result, so work_mem is set fairly large. Sometimes
> postgres is very inaccu
> > > OK, running the latest patch. Observations:
> > > ...
> > > I ran tests for about an hour, randomly killing/canceling
> backends
> > > without any problems.
> >
> > Are we all comfortable that
> > http://archives.postgresql.org/pgsql-hackers/2005-10/msg01009.php
> > is OK to apply?
>
> Y
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > OK, running the latest patch. Observations:
> > ...
> > I ran tests for about an hour, randomly killing/canceling backends
> > without any problems.
>
> Are we all comfortable that
> http://archives.postgresql.org/pgsql-hackers/2005-10/msg01009.p
Christopher Kings-Lynne wrote:
The no. 1 thing that people ask about is converting ENUMs.
There was some discussion a while back about enums, but it petered out.
If I have time I intend to follow this up in the 8.2 time frame:
http://archives.postgresql.org/pgsql-hackers/2005-07/msg0095
Am Dienstag, 25. Oktober 2005 11:17 schrieb Christopher Kings-Lynne:
> Has the sql compatibiliy list been updated? eg. for BETWEEN SYMMETRIC?
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/sql_features.txt
All signs point to "Sort of not really".
--
Peter Eisentraut
http:
Has the sql compatibiliy list been updated? eg. for BETWEEN SYMMETRIC?
Chris
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Mon, Oct 24, 2005 at 06:53:30PM -0600, Michael Fuhr wrote:
> So in case anybody was going to check on that prior to the upcoming
> 8.1 release candidate, there is new timezone data available (2005n
> vs. the current 2005m) but it appears to have only minor changes
> for Kyrgyzstan and Uruguay.
Hi All,
Just thought the hackers might be interested to know that there has been
a serious surge in the number of people in #postgresql coming in with
questions related to switching from MySQL to PostgreSQL.
Maybe it's something to do with Innobase - a few of them have
specifically mentioned
46 matches
Mail list logo
