* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Subject pretty much says it all. I've put up with this error in the
> > past when it has caused me trouble but it's now starting to hit our
> > clients on occation which is just unacceptable.
>
> Have you
Stephen Frost <[EMAIL PROTECTED]> writes:
> Subject pretty much says it all. I've put up with this error in the
> past when it has caused me trouble but it's now starting to hit our
> clients on occation which is just unacceptable.
Have you tracked down the exact scenario making it happen?
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> On 12/18/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> There is already an option to sleep early in backend startup for the
>> normal case. Not sure if it works for bootstrap, autovacuum, etc,
>> but I could see making it do so.
> You are probably referr
Chris Browne <[EMAIL PROTECTED]> writes:
> We're getting a bit of an anomaly relating to pg_stat_activity...
> ...
> That PID has been dead for several days, but this connection is marked
> as being open, still, after lo many days.
This probably just means that the "backend termination" stats mess
On Wed, Dec 20, 2006 at 17:49:15 +0100,
Kaare Rasmussen <[EMAIL PROTECTED]> wrote:
> I'm not sure, but as far as I remember, it will be a short release cycle for
> 8.3 in order to finish some big items that couldn't be ready in time for 8.2.
I believe the point of the short release cycle was m
"Jim Nasby" <[EMAIL PROTECTED]> writes:
> On the other hand, this would be the only part of the system where
> the official interface/API is a system catalog table.
I don't think it was ever intended by anyone that that would be the
long-term solution. Where we are currently at is experimenting
"Takayuki Tsunakawa" <[EMAIL PROTECTED]> wrote:
> I have to report a sad result. Your patch didn't work. Let's
> consider the solution together. What you are addressing is very
> important for the system designers in the real world -- smoothing
> response time.
You were running the test on th
On Thu, 12 Oct 2006 14:24:22 -0400
"D'Arcy J.M. Cain" wrote:
> On Thu, 12 Oct 2006 14:17:33 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
> > "D'Arcy J.M. Cain" writes:
> > > Cool. So what do I do with the patch? Should I add the currency
> > > symbol back in and commit or should I resubmit the p
On 12/20/06, Takayuki Tsunakawa <[EMAIL PROTECTED]> wrote:
> > [Conclusion]
> > I believe that the problem cannot be solved in a real sense by
> > avoiding fsync/fdatasync(). We can't ignore what commercial databases
> > have done so far. The kernel does as much as he likes when PostgreSQL
> > re
Jim Nasby wrote:
On Dec 20, 2006, at 7:56 AM, Florian G. Pflug wrote:
Jim Nasby wrote:
I'm teaching a class this week and a student asked me about OIDs. He
related the story of how in Sybase, if you moved a database from one
server from another, permissions got all screwed up because user IDs
I was looking at upgrading to 8.2, but I make extensive use of the IP4
module. It doesn't make properly due to the changes in the inet/cidr
types, notably the removal of the type (is_cidr) field of the
inet_struct, which the module uses when casting: ip4_cast_to_cidr,
ip4r_cast_to_cidr, and a ch
Mario wrote:
I'd like to help :-) I wanted to avoid a core dumped but you told
me that's a normal thing for a SIGQUIT signal.
Did you try running `ulimit -c 0` first? That should do what you want -
prevent generation of the dump file.
Regards, Philip.
--
Philip Yarra
Senior Software Eng
On 12/20/06, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
wiki [1]. I tried to put names and links behind the items where ever
possible. Let me know if there is something missing or if you know any
other information (links, names) etc. that should be mentioned.
I know Mark Cave-Ayland was inter
Lukas Kahwe Smith wrote:
> Hi,
>
> I just collected all the items mentioned in this thread as well as what
> people quickly came up with on IRC and put it on a list in the developer
> wiki [1]. I tried to put names and links behind the items where ever
> possible. Let me know if there is someth
Andrew Dunstan wrote:
Russell Smith wrote:
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
Force references to go through macros which implement the lookup
for the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
Zdenek Kotala wrote:
Gregory Stark wrote:
"Martijn van Oosterhout" writes:
Here's what I did: you can step over functions in initdb until it fails
(although I alredy know which part it's failing I guess). Restart. Then
you go into that function and step until the new backend has been
started.
On 12/20/06, Takayuki Tsunakawa <[EMAIL PROTECTED]> wrote:
[Conclusion]
I believe that the problem cannot be solved in a real sense by
avoiding fsync/fdatasync(). We can't ignore what commercial databases
have done so far. The kernel does as much as he likes when PostgreSQL
requests him to fsy
Hi,
I just collected all the items mentioned in this thread as well as what
people quickly came up with on IRC and put it on a list in the developer
wiki [1]. I tried to put names and links behind the items where ever
possible. Let me know if there is something missing or if you know any
othe
On Wed, Dec 20, 2006 at 09:15:05AM -0500, Stephen Frost wrote:
> > It doesn't really address the question of how you know which one to
> > use at any particular line of code; or even more to the point, what
> > mechanism will warn you if you use the wrong one.
>
> That'd be the point of doing the
On Dec 20, 2006, at 7:56 AM, Florian G. Pflug wrote:
Jim Nasby wrote:
I'm teaching a class this week and a student asked me about OIDs.
He related the story of how in Sybase, if you moved a database
from one server from another, permissions got all screwed up
because user IDs no longer matc
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Greg Sabino Mullane wrote:
> > It would help if you could get a stack trace at the moment of the
> > problem, but I'm not sure how to do that.
>
> Perhaps insert an abort() call right before the elog(ERROR)
> that's reporting this.
Kaare Rasmussen wrote:
I'm not sure, but as far as I remember, it will be a short release cycle for
8.3 in order to finish some big items that couldn't be ready in time for 8.2.
But which items are more or less expected for 8.3? I recall
- Hierarchical Queries
- On disk bitmap index
- Clustere
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Jeff Davis: I've not changed the function, so it's not the plan cache)
Tom Lane wrote:
> Does the mentioned OID actually correspond to the OID of the table it's
> supposed to be opening, or is it wrong? Is anything being done to
> the table schema
[EMAIL PROTECTED] (Kaare Rasmussen) writes:
> I'm not sure, but as far as I remember, it will be a short release cycle for
> 8.3 in order to finish some big items that couldn't be ready in time for 8.2.
>
> But which items are more or less expected for 8.3? I recall
> - Hierarchical Queries
> -
On Wed, Dec 20, 2006 at 05:49:15PM +0100, Kaare Rasmussen wrote:
> I'm not sure, but as far as I remember, it will be a short release
> cycle for 8.3 in order to finish some big items that couldn't be
> ready in time for 8.2.
>
> But which items are more or less expected for 8.3? I recall
> - Hie
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Greg Sabino Mullane wrote:
>> I'm encountering some disconcerting problems on a 8.1.3 database.
>> Very occasionally, I get a "could not open relation with OID xxx".
Does the mentioned OID actually correspond to the OID of the table it's
supposed to be
Greg Sabino Mullane wrote:
> I'm encountering some disconcerting problems on a 8.1.3 database.
> Very occasionally, I get a "could not open relation with OID xxx".
> This always occurs inside of a plpgsql function, and always refers
> to a normal, stable table that has not been dropped. The first
On Wed, 2006-12-20 at 18:06 +, Greg Sabino Mullane wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> I'm encountering some disconcerting problems on a 8.1.3 database.
> Very occasionally, I get a "could not open relation with OID xxx".
> This always occurs inside of a plpgsql fun
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm encountering some disconcerting problems on a 8.1.3 database.
Very occasionally, I get a "could not open relation with OID xxx".
This always occurs inside of a plpgsql function, and always refers
to a normal, stable table that has not been droppe
We (Oleg and me) are glad to present tsearch2 in core of pgsql patch. In basic,
layout, functions, methods, types etc are the same as in current tsearch2 with a
lot of improvements:
- pg_ts_* tables now are in pg_catalog
- parsers, dictionaries, configurations now have owner and namespace sim
> The remainder of this email talks about general principles for all
> developers, not just for company employees. If we need more text in
> this area, it should be added to the developer's FAQ. Feel free to
> suggest additions to that.
>
> I am kind of stumped that we have so much text in the
Heikki Linnakangas wrote:
> Jonah Harris wrote:
> > We could also mention all the Ingres-based offshoots that were
> > commercial. Let me think of some other examples... but there may not
> > be that many seeing as there aren't really that many PostgreSQL-like
> > communities. I guess I could men
I'm not sure, but as far as I remember, it will be a short release cycle for
8.3 in order to finish some big items that couldn't be ready in time for 8.2.
But which items are more or less expected for 8.3? I recall
- Hierarchical Queries
- On disk bitmap index
- Clustered/replication solutions
We're getting a bit of an anomaly relating to pg_stat_activity...
oxrstld=# SELECT * from pg_stat_activity where current_query <> '';
datid| datname | procpid | usesysid | usename | current_query |
query_start
+-+-+--+-+---
Peter Eisentraut wrote:
Am Mittwoch, 20. Dezember 2006 13:42 schrieb Tom Dunstan:
I suppose we should think about mysql refugees at some point, though. I
wonder what they do. The documentation is silent on the matter (and all
their examples are in lower case). Mysql is generally case insensit
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume space waste will be mostly fixed when we have 0/1 byte headers
> for varlena data types.
Hardly. int float timestamp etc types will all still have alignment issues.
regards, tom lane
---(end of
Andrew Dunstan wrote:
> > Now, we are rewriting the table from scratch anyway, the on disk
> > format is changing. What is stopping us from switching the column
> > order at the same time. The only thing I can think is that the
> > catalogs will need more work to update them. It's a middle si
David Fetter wrote:
> On Tue, Dec 19, 2006 at 05:40:12PM -0500, Bruce Momjian wrote:
> > Lukas Kahwe Smith wrote:
> > > Hi,
> > >
> > > I think another point you need to bring out more clearily is that
> > > the community is also often "miffed" if they feel they have been
> > > left out of the des
Am Mittwoch, 20. Dezember 2006 13:42 schrieb Tom Dunstan:
> I suppose we should think about mysql refugees at some point, though. I
> wonder what they do. The documentation is silent on the matter (and all
> their examples are in lower case). Mysql is generally case insensitive,
> right?
Maybe you
ITAGAKI Takahiro wrote:
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > OK, if I understand correctly, instead of doing a buffer scan, write(),
> > and fsync(), and recyle the WAL files at checkpoint time, you delay the
> > scan/write part with the some delay.
>
> Exactly. Actual behavior of che
Martijn van Oosterhout wrote:
Also, it's not just I/O functions that are the issue, consider the
enum-to-integer cast.
er, what cast? :-)
IIRC Tom hasn't provided one. If you don't break the enum abstraction
there should be no need for one, and given the implementation it's not
quite tri
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>>> Perhaps an array of int4 would be better? How much
> Done
> http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
>>> The patch needs more cleanup before applying, too, eg make comments
>>> match code, get rid of unused keywords added to gram.y.
> Cl
Andrew Dunstan wrote:
Or we could divide the positive number space in two, by starting at 2^14
(attnums are int2). Then a simple bitmask test would work to distinguish
them.
Perhaps divide-by-four, then it would be possible to have calculated
columns (as mentioned recently on one of the lis
>> Perhaps an array of int4 would be better? How much
Done
http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
The patch needs more cleanup before applying, too, eg make comments
match code, get rid of unused keywords added to gram.y.
Cleaned.
--
Teodor Sigaev
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> This isn't really a compromise. Remember that this discussion started
> with consideration of optimal record layout (minimising space use by
> reducing or eliminating alignment padding). The above proposal really
> does nothing for that.
While I agr
Jonah Harris wrote:
> We could also mention all the Ingres-based offshoots that were
> commercial. Let me think of some other examples... but there may not
> be that many seeing as there aren't really that many PostgreSQL-like
> communities. I guess I could mention more if I had a clear
> underst
On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
> Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
> > If you can show me a reasonably bulletproof or machine-checkable way to
> > keep the two kinds of column numbers distinct, I'd be all for it.
>
> The only way I can see is
On Tue, Dec 19, 2006 at 10:12:34PM +, Gregory Stark wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> >> Oh, you mean MB vs Mb. Man, it had to be that simple :)
> >
> > ISTM we had discussed whether guc.c should accept units strings in
> > a
Russell Smith wrote:
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
Force references to go through macros which implement the lookup for
the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It doesn't really addre
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Force references to go through macros which implement the lookup for the
> > appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
> > PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
>
> It doesn't really
Martijn van Oosterhout wrote:
On Wed, Dec 20, 2006 at 07:20:14AM -0600, Kenneth Marshall wrote:
On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
If you can show me a reasonably bulletproof or machine-checkab
Am Mittwoch, 20. Dezember 2006 14:20 schrieb Kenneth Marshall:
> On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
> > Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
> > > If you can show me a reasonably bulletproof or machine-checkable way to
> > > keep the two kinds of col
On Wed, Dec 20, 2006 at 09:14:50PM +0900, Takayuki Tsunakawa wrote:
> > That implies that fsyncing a datafile blocks fsyncing the WAL. That
> > seems terribly unlikely (although...). What OS/Kernel/Filesystem is
> > this. I note a sync bug in linux for ext3 that may have relevence.
>
> Oh, really?
On Wed, Dec 20, 2006 at 07:20:14AM -0600, Kenneth Marshall wrote:
> On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
> > Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
> > > If you can show me a reasonably bulletproof or machine-checkable way to
> > > keep the two kinds of
Jim Nasby wrote:
I'm teaching a class this week and a student asked me about OIDs. He
related the story of how in Sybase, if you moved a database from one
server from another, permissions got all screwed up because user IDs no
longer matched. I explained that exposing something like an integer
Tom Lane wrote:
(Hmm, I wonder what Tom Dunstan's enum patch does about case
sensitivity...)
Currently enum labels are case sensitive. I was a bit ambivalent about
it... case insensitivity can lead to less surprises in some cases, but
many programming languages that have enums are case sensi
Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
> If you can show me a reasonably bulletproof or machine-checkable way to
> keep the two kinds of column numbers distinct, I'd be all for it.
The only way I can see is to make the domains of the numbers distinct.
--
Peter Eisentraut
http://d
> That implies that fsyncing a datafile blocks fsyncing the WAL. That
> seems terribly unlikely (although...). What OS/Kernel/Filesystem is
> this. I note a sync bug in linux for ext3 that may have relevence.
Oh, really? What bug? I've heard that ext3 reports wrong data to
iostat when it perform
On Tue, Dec 19, 2006 at 11:29:24PM -0500, Tom Lane wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Force references to go through macros which implement the lookup for the
> > appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
> > PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
>
As a starting point, you can look at these two functions:
src/backend/optimizer/path/indxpath.c : find_usable_indexes()
src/backend/optimizer/util/pathnode.c : add_path()
Hope this helps.
On 12/20/06, Felipe Rondon Rocha <[EMAIL PROTECTED]> wrote:
Hi,
can you halp me?
Thks,
Felipe
- Or
From: "ITAGAKI Takahiro" <[EMAIL PROTECTED]>
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>> Do you use the same delay autovacuum uses?
>
> What do you mean 'the same delay'? Autovacuum does VACUUM, not
CHECKPOINT.
> If you think cost-based-delay, I think we cannot use it here. It's
hard to
> estimat
On 19/12/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
This normally a SIGQUIT, and on my machine at least the default action for
that is a core dump. Perhaps you need to say what you are trying to do and
why.
I'd like to help :-) I wanted to avoid a core dumped but you told
me that's a no
On 19/12/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
I think the problem Mario is really trying to solve is quitting at
psql's "Password: " prompt. Ctrl-C is ignored at that point apparently.
SIGQUIT (thus Ctrl-\ in most people's setup) does it but it also dumps
core.
yes, that is true an
Hi,
can you halp me?
Thks,
Felipe
- Original Message -
From: "Martijn van Oosterhout"
To: "Felipe Rondon Rocha" <[EMAIL PROTECTED]>
Sent: Tuesday, December 19, 2006 8:39 AM
Subject: Re: Fw: [HACKERS] choosing use an index or not
No idea, ask on -hackers...
I only know the concepts
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
Force references to go through macros which implement the lookup for the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It doesn't really address the question of how
On Wed, Dec 20, 2006 at 08:10:56PM +0900, Takayuki Tsunakawa wrote:
> One question is the disk utilization. While bgwriter is fsync()ing,
> %util of WAL disk drops to almost 0. But the the bandwidth of
> Ultra320 SCSI does not appear to be used fully. Any idea?
That implies that fsyncing a data
Hello, Itagaki-san, all
I have to report a sad result. Your patch didn't work. Let's
consider the solution together. What you are addressing is very
important for the system designers in the real world -- smoothing
response time.
Recall that unpatched PostgreSQL showed the following tps's in c
On Wed, Dec 20, 2006 at 01:39:58AM +, Tom Dunstan wrote:
> Not with this patch, and AFAIK not possible generally, without writing
> separate I/O functions for each type. I'd love to be able to do that,
> but I don't think it's possible currently. The main stumbling block is
> the output func
The documentation at
http://www.postgresql.org/docs/8.2/interactive/config-setting.html states
that:
Boolean values may be written as ON, OFF, TRUE, FALSE, YES, NO, 1, 0 (all
case-insensitive) or any unambiguous prefix of these.
But the following doesn't work:
postgres=# set enable_seqscan = of
On Tue, Dec 19, 2006 at 05:40:12PM -0500, Bruce Momjian wrote:
> Lukas Kahwe Smith wrote:
> > Hi,
> >
> > I think another point you need to bring out more clearily is that
> > the community is also often "miffed" if they feel they have been
> > left out of the design and testing phases. This is so
On Tue, Dec 19, 2006 at 07:17:13PM -0800, Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 22:04 -0500, Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > >> I remember the president of Great Bridge
> > >> saying that the company needs the community, but not visa-vera --- if
> > >>
71 matches
Mail list logo
