Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Plan B would be to remove that restriction and teach btree and gist to
>> cope. While a btree couldn't use a nonconsecutive restriction as part
>> of its where-to-scan logic, I don't see any good reason why it couldn'
We are currently seeing a whole lot of complaints due to the fact that
8.0 tends to default to Unicode encoding in environments where previous
versions defaulted to SQL-ASCII. That says to me that a whole lot of
people were getting along just fine in SQL-ASCII, and therefore that
moving further aw
Tom Lane <[EMAIL PROTECTED]> writes:
> Plan B would be to remove that restriction and teach btree and gist to
> cope. While a btree couldn't use a nonconsecutive restriction as part
> of its where-to-scan logic, I don't see any good reason why it couldn't
> still perform the test before returnin
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> That would cripple a system that many users are perfectly content with now.
> Well, I wasn't thinking of using a 7-bit encoding always, just as a
> replacement for the cases where we currently choose SQL_ASCII. Does that
> soun
I suppose you are running on some BSD variant? BSD is notorious for
promising more than it can deliver with respect to number of open files
per process. This is a kernel bug, not a Postgres bug.
Good guess. Freebsd 4.8 or so.
Chris
---(end of broadcast)---
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> I'm having some problems with lo_open inside of DBD::Pg (which
> uses libpq) and need help in debugging the problem.
lo_open doesn't work unless inside a transaction block (and even
if it did work, the result would be useless to you).
I believe
On Fri, May 13, 2005 at 02:39:25AM -, Greg Sabino Mullane wrote:
> I'm having some problems with lo_open inside of DBD::Pg (which
> uses libpq) and need help in debugging the problem. The problem
> is that a call to lo_open works perfectly, *unless* it is the
> first thing that this connection
On Fri, May 13, 2005 at 09:45:15AM +0800, Christopher Kings-Lynne wrote:
> A few days back the load increased on our database server to the point
> where it could not get enough file handles. This causes the backends to
> crash, get restarted only to crash again, on and on.
>
> We fixed it by
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> A few days back the load increased on our database server to the point
> where it could not get enough file handles. This causes the backends to
> crash, get restarted only to crash again, on and on.
> We fixed it by bumping kern.maxfiles, b
A few days back the load increased on our database server to the point
where it could not get enough file handles. This causes the backends to
crash, get restarted only to crash again, on and on.
We fixed it by bumping kern.maxfiles, but was just wondering if this is
a scenario that PostgreSQL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm having some problems with lo_open inside of DBD::Pg (which
uses libpq) and need help in debugging the problem. The problem
is that a call to lo_open works perfectly, *unless* it is the
first thing that this connection to the database has done, in
On Thursday 12 May 2005 19:59, David Fetter wrote:
> On Thu, May 12, 2005 at 05:52:43PM -0400, Robert Treat wrote:
> > On Thursday 12 May 2005 01:32, Christopher Kings-Lynne wrote:
> > > > FWIW, I don't see the issue as "internal vs external" at all.
> > > > What's bothering me is whether these vie
Hi,
A few days back the load increased on our database server to the point
where it could not get enough file handles. This causes the backends to
crash, get restarted only to crash again, on and on.
We fixed it by bumping kern.maxfiles, but was just wondering if this is
a scenario that Postgr
Christopher Kings-Lynne wrote:
As lead phpPgAdmin developer, I'm officially in favour of them. The
main reason being all the extra fruit they have that shows database
size, etc.
As non-lead phpPgAdmin developer, I'd be against using them in
phppgadmin. (note this doesnt mean I am against them i
As lead phpPgAdmin developer, I'm officially in favour of them. The
main reason being all the extra fruit they have that shows database
size, etc.
As non-lead phpPgAdmin developer, I'd be against using them in phppgadmin.
(note this doesnt mean I am against them in pgsql itself)
Hehe, talk about
On Thu, May 12, 2005 at 05:52:43PM -0400, Robert Treat wrote:
> On Thursday 12 May 2005 01:32, Christopher Kings-Lynne wrote:
> > > FWIW, I don't see the issue as "internal vs external" at all.
> > > What's bothering me is whether these views can be considered
> > > sufficiently more stable and bet
Andrew,
> I still don't have any strong views, but I do want the target audience
> specified - I have seen conflicting messages on that. Power users? Admin
> Tool builders? Client library builders? These groups don't all have the
> same needs.
DBAs, tool builders (primarily existing-tool-integrat
On Thursday 12 May 2005 01:32, Christopher Kings-Lynne wrote:
> > FWIW, I don't see the issue as "internal vs external" at all. What's
> > bothering me is whether these views can be considered sufficiently
> > more stable and better designed than the physical system catalogs
> > to justify recomme
"Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> If I have on-disk bitmap
> ON (a, b, c)
> will the planner pick an index scan for
> WHERE a = 42 AND b = 'foo'
> (i.e. only part of the index attributes are involved)? Any modifications
> needed to achieve this functionality?
Hmm. That
Peter Eisentraut wrote:
> Am Donnerstag, 12. Mai 2005 14:57 schrieb Oliver Jowett:
>
>>My 8.0.0 (what I happen to have on hand) initdb creates a SQL_ASCII
>>cluster by default unless I specify -E.
>
>
> Then you use the locale C. We could create a 7-bit encoding and map it to
> locale C, I sup
* Tom Lane <[EMAIL PROTECTED]> [12.05.2005 23:09]:
> 1. Be sure that all the indexable WHERE conditions are passed to the
>indexscan as indexquals. This might be, say,
> WHERE a = 42 and b = 'foo'
If I have on-disk bitmap
ON (a, b, c)
will the planner pick an index scan for
On Thursday 12 May 2005 13:04, Josh Berkus wrote:
> Andreas,
>
> > First, as some other msg states the views will estimate the sizes,
> > dbsize uses actual file sizes. Second, in contrast to CKL, I would *not*
> > use these fancy new system views, because they mean yet another
> > dependency for p
On Thursday 12 May 2005 10:24, Tom Lane wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
> > What currently happens is that backends respond to kill -15 (_NOT_ -9)
> > by cleaning up and exiting. This code path is used for implementing the
> > stop -mfast option, which means that as it curre
"Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> I have questions on how to implement on-disk bitmap scan.
I think your best plan might be
1. Be sure that all the indexable WHERE conditions are passed to the
indexscan as indexquals. This might be, say,
WHERE a = 42 and b = 'foo'
2.
Josh Berkus wrote:
1) would some kind of new system views in theory be valuable and accepted
I still don't have any strong views, but I do want the target audience
specified - I have seen conflicting messages on that. Power users? Admin
Tool builders? Client library builders? These groups don
On Thu, May 12, 2005 at 03:30:59PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (elein) writes:
> > Also, if you do not trust the newsysview team to develop good views
> > (with input for hackers), how can you possibly expect every dba and tool
> > maker to access the system catalog in a consistent
Tom,
> I never said that they couldn't develop useful views. I do question
> the assumption that they can be all things to all people. I think the
> claims being made in this thread are highly overblown. In particular
> I doubt that views that expose everything anyone might want to know
> are g
[EMAIL PROTECTED] (elein) writes:
> Also, if you do not trust the newsysview team to develop good views
> (with input for hackers), how can you possibly expect every dba and tool
> maker to access the system catalog in a consistent and accurate manner.
I never said that they couldn't develop usef
Greetings.
I have questions on how to implement on-disk bitmap scan.
I've been working on on-disk bitmaps as an ordinary Index Access Method, but
now it's clear to me, that it'll lose all it's strengths this way. One on-disk
bitmap has exactly one list of indexed table's TIDs and potentially unl
On Thu, May 12, 2005 at 01:23:17AM -0400, Tom Lane wrote:
> "Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> > I think it's important to consider the perspective of both developers
> > and users, and the internal views clearly creates issues for the
> > developers.
>
> FWIW, I don't see th
Sergey Ten wrote:
Thank you to all who replied for your time.
We have checked http://momjian.postgresql.org/cgi-bin/pgpatches and
http://momjian.postgresql.org/cgi-bin/pgpatches2, and could not find
patches
with words "copy" or "xml" in the subject. Could you please clarify what
the
website versi
Thank you to all who replied for your time.
We have checked http://momjian.postgresql.org/cgi-bin/pgpatches and
http://momjian.postgresql.org/cgi-bin/pgpatches2, and could not find patches
with words "copy" or "xml" in the subject. Could you please clarify what the
website version is and where it
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 09, 2005 5:36 PM
> To: Dann Corbit
> Subject: RE: "Priority Mechanisms for OLTP and Transactional Web
> Applications"
>
>
> So how should we move forward on this? Do you have an application in
>
>./configure --with-perl --with-dblink --with-newsysviews
This would make installing and upgrading BSD ports easier.
David
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's
Andreas,
> First, as some other msg states the views will estimate the sizes,
> dbsize uses actual file sizes. Second, in contrast to CKL, I would *not*
> use these fancy new system views, because they mean yet another
> dependency for pgAdmin.
I like that. You're in favor of including the serv
Andrew,
> * Move some things from /contrib into main tree
> * Move some /contrib modules out to their own project sites
A contrib shuffle is on my personal TODO list. Look for a list in a couple
weeks.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(
On Thu, 2005-05-12 at 13:48 +0100, Mark Cave-Ayland wrote:
> > From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
> >
> > >>perhaps the CRC-32 routines could be written in in-line assembler
> > >
> > >
> > > If you can do this, step right up. :-)
> > >
> > > Best Regards, Simon Riggs
> >
Marc G. Fournier wrote:
'k, now i'm confused ... what are you looking at here, in contrib, as
being 'admintools'? Right now, anything in contrib is 'add-on' anyway,
so they'd still be as confused, I'd think ...
Well at least it would be contained in the full tarball, not coming from
a 3rd site
On 2005-05-11, Tom Lane <[EMAIL PROTECTED]> wrote:
> There are a number of issues that would have to be solved to make this
> actually work, but on first glance it seems like a possibly attractive
> idea.
>
> Besides, I can't wait to hear the moans from the newsysviews crew when
> the implications
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Argument 3: backwards compatibility. Do you remember how tablespaces
> introduction broke pgAdmin?
This argument, at least, is bogus. See my original comments to Josh:
it is not credible that these views will be significantly more stable
than the un
On Thu, 12 May 2005, Andreas Pflug wrote:
Marc G. Fournier wrote:
... but stuff like admintools should be on pgfoundry ...
This is a quite *ix centric attitude. Please note that probably >90 % of
win32 installations have them installed by default (from the win32
installer). People moving to Linux
Marc G. Fournier wrote:
... but stuff like admintools should be on pgfoundry ...
This is a quite *ix centric attitude. Please note that probably >90 % of
win32 installations have them installed by default (from the win32
installer). People moving to Linux because they need better performance
(wh
> FWIW, I don't see the issue as "internal vs external" at all. What's
> bothering me is whether these views can be considered sufficiently
> more stable and better designed than the physical system catalogs
> to justify recommending that application designers should rely on
> the views instead of
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Thu, May 12, 2005 at 10:48:50AM -0400, Tom Lane wrote:
>> If you are looking for an existing tool to adapt, I think the sinval
>> messaging mechanism is a FAR better prototype.
> Hmm. The problem is that it's easy to do something if the sinval queue
On Thu, May 12, 2005 at 10:48:50AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Thu, May 12, 2005 at 10:09:23AM -0400, Tom Lane wrote:
> >> Please review the archived discussions about reimplementing NOTIFY using
> >> only shared memory, no tables.
>
> > Maybe this ca
Am Donnerstag, 12. Mai 2005 14:57 schrieb Oliver Jowett:
> My 8.0.0 (what I happen to have on hand) initdb creates a SQL_ASCII
> cluster by default unless I specify -E.
Then you use the locale C. We could create a 7-bit encoding and map it to
locale C, I suppose.
> > Certainly, making 7-bit AS
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Thu, May 12, 2005 at 10:09:23AM -0400, Tom Lane wrote:
>> Please review the archived discussions about reimplementing NOTIFY using
>> only shared memory, no tables.
> Maybe this can be done using two SLRU areas like we did for multixact.
If you are
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Another thought I had along that line was use a different signal to
> simply do a "query cancel" and set a global flag that is more or less
> "get out when you're done with query cancel". Then if that flag is set,
> just close the connection and proce
On Thu, 12 May 2005, Andrew Dunstan wrote:
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
First, I *really* wish we'd call it something else. Contrib conveys
"unsupported" to people.
And that's exactly what it is supposed to mean. We say, these modules do
not
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> In 8.0, the de facto default encoding is no longer SQL_ASCII, so that
>> problem should go away over time.
> My 8.0.0 (what I happen to have on hand) initdb creates a SQL_ASCII
> cluster by default unless I specify -E.
This wo
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> What currently happens is that backends respond to kill -15 (_NOT_ -9)
> by cleaning up and exiting. This code path is used for implementing the
> stop -mfast option, which means that as it currently exists, the cleanup
> only has to be good enough t
On Thu, May 12, 2005 at 10:09:23AM -0400, Tom Lane wrote:
> Andras Kadinger <[EMAIL PROTECTED]> writes:
> > ... I therefore invented pg_notify:
>
> Please review the archived discussions about reimplementing NOTIFY using
> only shared memory, no tables.
Maybe this can be done using two SLRU areas
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
First, I *really* wish we'd call it something else. Contrib conveys
"unsupported" to people.
And that's exactly what it is supposed to mean. We say, these modules
do not necessarily meet our stan
Andras Kadinger <[EMAIL PROTECTED]> writes:
> ... I therefore invented pg_notify:
Please review the archived discussions about reimplementing NOTIFY using
only shared memory, no tables. The pg_listener table causes a number of
performance problems, and I think that getting rid of it should be a t
> > Not kill -9. Kill -9 is "safe" because it causes a complete
> restart of
> > the postmaster (it's the same as a backend crash, really).
> Kill -INT
> > is also safe, because it does a simlpe query cancel.
>
> Hmm, would it be possible to use another signal for "cancel
> the current query
On Thu, May 12, 2005 at 10:55:22AM +0200, Magnus Hagander wrote:
> Not kill -9. Kill -9 is "safe" because it causes a complete restart of
> the postmaster (it's the same as a backend crash, really). Kill -INT is
> also safe, because it does a simlpe query cancel.
Hmm, would it be possible to use
Peter Eisentraut wrote:
> Am Donnerstag, 12. Mai 2005 04:42 schrieb Oliver Jowett:
>
>>I suppose that we can't change the semantics of SQL_ASCII without
>>backwards compatibility problems. I wonder if introducing a new encoding
>>that only allows 7-bit ascii, and making that the default, is the wa
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
> Sent: 12 May 2005 02:46
> To: Simon Riggs
> Cc: Mark Cave-Ayland (External); 'Tom Lane'; 'Bruce Momjian';
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
>
>
> >
Russell Smith <[EMAIL PROTECTED]> writes:
> I suppose the question is, at what point are contrib modules
> re-reviewed for inclusion into core? And if they are continuing not
> to make it, is there something else that should be done with them?
Basically, if someone wants a contrib module in core
On 2005-05-12, Andreas Pflug <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews wrote:
>> dbsize looks at the actual size of files on disk; newsysviews does not,
>> it shows estimated sizes as taken from relpages.
>
> Which shows *net* size only, not actual size because non-vacuumed rows
> are not co
> Personally, I'd like UTF8 to be the default encoding :) This
> is the 21st century :D
I concur.
... John
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
> > Not kill -9. Kill -9 is "safe" because it causes a complete
> restart of
> > the postmaster (it's the same as a backend crash, really).
> Kill -INT
> > is also safe, because it does a simlpe query cancel.
>
> I don't recall exactly; AFAIR this was discussed between Dave
> and Tom.
> Actu
On 2005-05-12, Andreas Pflug <[EMAIL PROTECTED]> wrote:
>> These seem potentially very dangerous though, so we wouldn't want them
>> installed by default.
>
> Not more dangerous than "drop table pg_class".
Have you ever tried that?
test=# drop table pg_class;
ERROR: permission denied: "pg_class
Magnus Hagander wrote:
Not kill -9. Kill -9 is "safe" because it causes a complete restart of
the postmaster (it's the same as a backend crash, really). Kill -INT is
also safe, because it does a simlpe query cancel.
I don't recall exactly; AFAIR this was discussed between Dave and Tom.
Actually
> >>- There was a pg_kill_backend function in pre-8.0, but it
> was dropped
> >>because "it's too dangerous". Incidentially, I've been in
> the situation
> >>more than once where I needed to kill a backend process
> that was running
> >>wild; alternatively, I'd have to shutdown the whole server
Andrew - Supernews wrote:
dbsize looks at the actual size of files on disk; newsysviews does not,
it shows estimated sizes as taken from relpages.
Which shows *net* size only, not actual size because non-vacuumed rows
are not covered. It is correct after a vacuum full only.
newsysviews doesn't
al
On Thu, 12 May 2005 02:44 pm, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Andrew Dunstan wrote:
> >> First, I *really* wish we'd call it something else. Contrib conveys
> >> "unsupported" to people.
>
[snip]
> Which is as it should be, I think. Contrib is essentially the
Josh Berkus wrote:
- dbsize has been in contrib for a long time, though it appears to me as
quite a basic functionality to find out about storage needs.
Although not needed so much if the new system views are approved; we have a
view that calculates database size.
First, as some other msg states
Tom Lane wrote:
Josh Berkus writes:
- The superuser only generic file functions in the admin package have
been posted for 8.0, but where (more or less ) silently dropped. These
functions allow pgadmin to display the server logs, as well as editing
pg_hba.conf and postgresql.conf without console ac
> > I have a problem with the users administration. When I
> want to erase
> > (drop) some databases there's an error: ** database
> "name_db" is being
> > accessed by other users.** I want to kill the user
> sessions conected
> > but i don't know how to do it (Kill the user sessions).
>
>
In 8.0, the de facto default encoding is no longer SQL_ASCII, so that problem
should go away over time. Certainly, making 7-bit ASCII the default encoding
is not an option.
You sure?
---(end of broadcast)---
TIP 7: don't forget to increase your fre
Am Donnerstag, 12. Mai 2005 04:42 schrieb Oliver Jowett:
> I suppose that we can't change the semantics of SQL_ASCII without
> backwards compatibility problems. I wonder if introducing a new encoding
> that only allows 7-bit ascii, and making that the default, is the way to
> go.
In 8.0, the de fa
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andrew Sullivan
> Sent: 11 May 2005 21:04
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Server instrumentation for 8.1
>
> On Wed, May 11, 2005 at 04:44:21PM +, Andreas Pflug wr
Greetings everyone,
Beginner in PostgreSQL internals, seeking the insight of more experienced.
" (At present, the extra field is unused and will always point to an empty
string.)" - http://www.postgresql.org/docs/8.0/static/libpq-notify.html
regarding PGnotify returned by PQnotifies
I would lik
74 matches
Mail list logo
