> > => select now()>coalesce('Jul 14 2006 9:16:47AM');
> The only bug I see here is that implicit coercions to text
> are a bad idea :-( --- IMHO it would be better if your first
> query failed instead of giving you unexpected behavior.
:-) We know that you think that Tom, but a lot of us do n
> I've seen a few EAV designs in practice. They've all been
> problematic. I'd like to have a better way of dealing with
> them. Which is why I'm tentatively suggesting support for
> inheritance and constraints in views. If there's some other
> way to achieve constraint based exclusion across
> > I've seen a few EAV designs in practice. They've all been
problematic.
> > I'd like to have a better way of dealing with them. Which is why I'm
> > tentatively suggesting support for inheritance and constraints in
> > views. If there's some other way to achieve constraint based
exclusion
>
> > > Will this patch make it into 8.2?
> > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php
> > >
> > > It's a really nice feature, would be extremly useful with tools
like pgpool.
> >
> > No, it will not because RESET CONNECTION can mess up interface code
> > that doesn't w
I've tracked down my problem with pgxs to Makefile.global in lib/pgxs/src.
These lines seem to be the culprits:
bindir := $(shell pg_config --bindir)
datadir := $(shell pg_config --sharedir)
sysconfdir := $(shell pg_config --sysconfdir)
libdir := $(shell pg_config --libdir)
pkglibdir := $(shell p
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I'm not quite sure what you're suggesting; presumably you'd need to open
> > another client connection to send the "status report" message to a
> > backend (since a backend will not be polling its input socket durin
Ühel kenal päeval, K, 2006-07-19 kell 05:18, kirjutas Greg Stark:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > I'm not quite sure what you're suggesting; presumably you'd need to open
> > > another client connection to send the "status report" message
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Greg Stark
> Sent: 19 July 2006 10:19
> To: Tom Lane
> Cc: Neil Conway; Gregory Stark; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Progress bar updates
>
> It would be the most practical w
On Wed, Jul 19, 2006 at 05:06:48AM -0400, Gregory Stark wrote:
>
> I've tracked down my problem with pgxs to Makefile.global in lib/pgxs/src.
> These lines seem to be the culprits:
> I think it should be running $(pkglibdir)/bin/pg_config
Seems reasonable to me. This code definitly seems to be
"Tom Lane <[EMAIL PROTECTED]>" wrote:
> Katsuhiko Okano <[EMAIL PROTECTED]> writes:
> > It does not solve, even if it increases the number of NUM_SUBTRANS_BUFFERS.
> > The problem was only postponed.
>
> Can you provide a reproducible test case for this?
Seven machines are required in order to pe
Katsuhiko Okano wrote:
> "Tom Lane <[EMAIL PROTECTED]>" wrote:
>> Katsuhiko Okano <[EMAIL PROTECTED]> writes:
>>> It does not solve, even if it increases the number of NUM_SUBTRANS_BUFFERS.
>>> The problem was only postponed.
>> Can you provide a reproducible test case for this?
>
> Seven machines
The psql manual says this:
AUTOCOMMIT
... The autocommit-off mode works by issuing an implicit BEGIN for you,
just before any command that is not already in a transaction block and
is not itself a BEGIN or other transaction-control command, nor a
command that cannot be exe
Hi folks,
From: Stefan Kaltenbrunner <[EMAIL PROTECTED]>
Subject: Re: CSStorm occurred again by postgreSQL8.2. (Re: [HACKERS] poor
Date: Wed, 19 Jul 2006 12:53:53 +0200
> Katsuhiko Okano wrote:
> > "Tom Lane <[EMAIL PROTECTED]>" wrote:
> >> Katsuhiko Okano <[EMAIL PROTECTED]> writes:
> >>> It do
pg_regress now seems to break on Msys virtual locations:
Example from the buildfarm:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snake&dt=2006-07-19%2009:00:00
== pgsql.4660/src/test/regress/log/initdb.log
===
The filename, directory name, or volume label
Josh Berkus wrote:
Andreas,
Some weeks ago I proposed a PROGRESS parameter for COPY, to enable
progress feedback via notices. tgl thinks nobody needs that...
Well, *Tom* doesn't need it. What mechanism did you propose to make this
work?
Extended the parser to accept that keyword,
On Thu, Jul 13, 2006 at 07:17:31PM -0400, Tom Lane wrote:
> Phil Frost <[EMAIL PROTECTED]> writes:
> > I've recently migrated one of my databases to using veil. This involved
> > creating a 'private' schema and moving all tables to it.
> > ...
> > In doing so, I found to my extreme displeasure that
Andrew Dunstan wrote:
It strikes me that this is actually a bad thing for pgadmin3 to be
doing. It should use its own file, not the deafult location, at least
if the libpq version is >= 8.1. We provided the PGPASSFILE environment
setting just so programs like this could use alternative loca
Hiroshi Saito wrote:
From: "Andrew Dunstan"
Thomas Bley wrote:
+ The .pgpass file will be automatically created if you're using
pgAdmin III with "store password" being enabled in the connection
settings.
It strikes me that this is actually a bad thing for pgadmin3 to be
doing. It
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andrew Dunstan
> Sent: 19 July 2006 13:55
> To: Hiroshi Saito
> Cc: Thomas Bley; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] password is no required,
> authentication is overridden
>
>
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> elein wrote:
> >>pg_dump -t will work.
> >
> >Oh, you got me all worked up. I was reading this as a way to
> >dump the CONTENTS of a view not the DEFINITION of a view.
> >I thought someone sneaked in pg_dump of a query in there.
> >
> >
>
> How wou
On Wed, Jul 12, 2006 at 06:09:31PM -0400, Bruce Momjian wrote:
> Phil Frost wrote:
> > On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote:
> > >
> > > Updated text:
> > >
> > >For schemas, allows access to objects contained in the specified
> > >schema (assuming that th
Martijn van Oosterhout writes:
> On Tue, Jul 18, 2006 at 10:46:04PM -0400, Tom Lane wrote:
>> ... One reason I didn't try to do this is I'm a bit hesitant to
>> write a signal handler that does anything as interesting as a system()
>> call, which would seem to be necessary to duplicate what the s
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Dunstan
Sent: 19 July 2006 13:55
To: Hiroshi Saito
Cc: Thomas Bley; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] password is no required,
authentication is overridde
Is there any way to refer to standard functions when defining new functions? I
tried " AS '-','int4eq' " but it just said "ERROR: could not access file "-":
No such file or directory".
It seems like a lot of data types would find it convenient if they have a
representation that is similar to one
Gregory Stark <[EMAIL PROTECTED]> writes:
> I've tracked down my problem with pgxs to Makefile.global in lib/pgxs/src.
> These lines seem to be the culprits:
> bindir := $(shell pg_config --bindir)
> datadir := $(shell pg_config --sharedir)
> sysconfdir := $(shell pg_config --sysconfdir)
> libdir
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> In practice, if a query is taking long enough for this feature to be
>> interesting, making another connection and looking to see what's happening
>> is not a problem, and it's likely to be the most practical way anywa
Gregory Stark <[EMAIL PROTECTED]> writes:
> One possible criticism is that a user that manually does BEGIN; CLUSTER
> DATABASE; ROLLBACK; won't be warned that the cluster will not be undoable.
s/possible criticism/deal-breaker/ ... you can't possibly think that the
above would be acceptable. It'd
Just a general question - I submitted a patch for contrib/cube (adding a
new function & converting everything from V0 to V1), what is the process
from here onwards? Do we have an active maintainer of this code? How is
it reviewed?
I would like to continue working on the cube stuff, as our comp
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> pg_regress now seems to break on Msys virtual locations:
> Example from the buildfarm:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snake&dt=2006-07-19%2009:00:00
> == pgsql.4660/src/test/regress/log/initdb.log
> ==
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: 19 July 2006 15:20
> To: Dave Page
> Cc: Hiroshi Saito; Thomas Bley; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] password is no required,
> authentication is overridden
>
> >From: http://www.pgadmi
Something that would be extremely useful to add to the first pass of
this would be to have a work_mem limiter. This would allow users to set
work_mem much more aggressively without worrying about pushing the
machine to swapping. That capability alone would make this valuable to a
very large number
Marc G. Fournier wrote:
> >> Why can't we just write a script that creates new numbers as needed,
> >> such as msg00163.1.php and msg00163.2.php? As far as I can tell, there
> >> is nothing magical about the naming schema itself that would cause
> >> such URLs to break anything.
> >
> > Agreed. It
Gregory Stark <[EMAIL PROTECTED]> writes:
> Is there any way to refer to standard functions when defining new functions?
Sure, but they're language INTERNAL, not C.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you
On 7/19/06, Joshua Reich <[EMAIL PROTECTED]> wrote:
Just a general question - I submitted a patch for contrib/cube (adding a
new function & converting everything from V0 to V1), what is the process
from here onwards? Do we have an active maintainer of this code? How is
it reviewed?
You should p
Joshua Reich <[EMAIL PROTECTED]> writes:
> Just a general question - I submitted a patch for contrib/cube (adding a
> new function & converting everything from V0 to V1), what is the process
> from here onwards? Do we have an active maintainer of this code?
It sounds like you've just acquired th
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Marko Kreen
> Sent: 19 July 2006 16:13
> To: Joshua Reich
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Patch process?
>
> On 7/19/06, Joshua Reich <[EMAIL PROTECTED]> wrote:
> > Just
On 7/19/06, Dave Page wrote:
> You should post into -patches@ list, then some core member will
> review and apply it.
Not core, a committer. Although some people are both, not all are. If
that makes sense!
Indeed.
Obviously, non-committers can (and do) review patches. Just you need
to get t
On Fri, Jul 14, 2006 at 02:58:36PM +0900, Katsuhiko Okano wrote:
> NOT occurrence of CSStorm. The value of WIPS was about 400.
> (but the value of WIPS fell about to 320 at intervals of 4 to 6 minutes.)
If you haven't changed checkpoint timeout, this drop-off every 4-6
minutes indicates that you n
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Mario Weilguni wrote:
> > > Will this patch make it into 8.2?
> > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php
> > >
> > > It's a really nice feature, would be extremly useful with tools like
> > > pgpool.
> >
> > No, it wil
Tatsuo Ishii wrote:
> I'm disappointed.
>
> Can you point out past discussion for this?
Yes:
http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php
---
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
>
> > M
Tom Lane wrote:
Joshua Reich <[EMAIL PROTECTED]> writes:
Do we have an active maintainer of this code?
It sounds like you've just acquired that position ;-)
More than happy to take the role.
How is it reviewed?
Same as everything else, pretty much: patches go to pgsql-patches and
are (
Dave Page wrote:
You should post into -patches@ list, then some core member will
review and apply it.
Not core, a committer. Although some people are both, not all are. If
that makes sense!
I have raised this issue before: I don't believe committers are
identified as such on th
On Wednesday 19 July 2006 07:33, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> In practice, if a query is taking long enough for this feature to be
> >> interesting, making another connection and looking to see what's
> >> happening is not a
I'm working on a patch that implements the PL/pgSQL instrumentation
stuff (i.e. the PL/pgSQL debugger) that I discussed at the Anniversary
Summit and I need some opinions (this seems like a good place to look
for opinions :-)
A quick review: the PL/pgSQL debugger is designed as an optional
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
pg_regress now seems to break on Msys virtual locations:
Example from the buildfarm:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snake&dt=2006-07-19%2009:00:00
== pgsql.4660/src/test/regress/log/ini
On Mon, Jul 17, 2006 at 09:25:49AM -0700, Josh Berkus wrote:
> Dragan,
>
> >What are the possibilities (if any) for continuous dataflow streaming with
> >PostgreSQL v.8.1 ? Something like TelegraphCQ project,but it was for
> >v.7.3.Is there any alternatives for the latest version of PostgreSQL ?
>
Hi,
I just finished setting up a new buildfarm member (Bandicoot) running
Windows 2000 Pro. Aside from the fact that it now fails with the same
cyptic pg_regress error as seen on Snake, it also became apparent that
CVS HEAD won't run properly on an unpatched Windows 2000 (initdb - and
probably pg_
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This error message seems pretty thoroughly unhelpful though. Any ideas
>> what it's unhappy about?
> I think we need to change the pg_regress error messages so that it
> includes the command string that failed, at least for now.
Do
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Is there any way to refer to standard functions when defining new functions?
>
> Sure, but they're language INTERNAL, not C.
ah, thanks
--
greg
---(end of broadcast)--
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > One possible criticism is that a user that manually does BEGIN; CLUSTER
> > DATABASE; ROLLBACK; won't be warned that the cluster will not be undoable.
>
> s/possible criticism/deal-breaker/ ... you can't possibly
Tom Lane wrote:
> In src/include/port.h we have
>
> /*
> *Win32 needs double quotes at the beginning and end of system()
> *strings. If not, it gets confused with multiple quoted strings.
> *It also requires double-quotes around the executable name and
> *any files used for re
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> s/possible criticism/deal-breaker/ ... you can't possibly think that the
>> above would be acceptable. It'd be worse than "won't be undoable"; it'd
>> probably corrupt your database.
> I'm not sure I understand why.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> * From http://www.computerhope.com/cmd.htm:
> *
> * 1. If all of the following conditions are met, then quote characters
> * on the command line are preserved:
> *
> * - no /S switch
> * - exactly two quote characters
> * - no special cha
Neil Conway wrote:
> > I would suggest starting with utility functions like index builds or COPY
> > which would have to be specially handled anyways. Handling all optimizable
> > queries in a single generic implementation seems like something to tackle
> > only
> > once the basic infrastructure i
korry <[EMAIL PROTECTED]> writes:
> I'm working on a patch that implements the PL/pgSQL instrumentation
> stuff (i.e. the PL/pgSQL debugger) that I discussed at the Anniversary
> Summit and I need some opinions (this seems like a good place to look
> for opinions :-)
Opinions R US ;-)
> 1) I
Marc G. Fournier wrote:
> > src/pl/plphp/README.TXT
> > src/pl/pljava/README.TXT
> > src/pl/plj/README.TXT
> >
> > and anybody looking for pl-s would find the info in a logical place
>
> *That* idea I like ...
Why don't we just reorganize our tree like that:
everything/databases/postgresql/src/..
Hannu Krosing wrote:
> So we would have
>
> src/pl/plphp/README.TXT
> src/pl/pljava/README.TXT
> src/pl/plj/README.TXT
>
> and anybody looking for pl-s would find the info in a logical place
Right. When was the last time any user looked under src/pl in the first
place? Or even under src? If yo
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > * From http://www.computerhope.com/cmd.htm:
> > *
> > * 1. If all of the following conditions are met, then quote characters
> > * on the command line are preserved:
> > *
> > * - no /S switch
> > * - exactly two quote ch
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> And if that didn't convince you, I still got PL/sh in the wait ...
It seems like there may be enough interest in PL/Ruby to justify
including it in our distro, but after taking a look at the package
I can see a couple of pretty serious objections:
1.
You are correct, Andreas.
=> select now()>'Jul 14 2006 9:16:47AM';
?column?
--
t
(1 row)
=> select now() > CASE WHEN 'Jul 14 2006 9:16:47AM' IS NOT NULL THEN
'Jul 14 2006 9:16:47AM' END;
?column?
--
f
(1 row)
I've also found that there must be more than one typecasting functi
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Hmm, that suggests that our code works *only* if there's white space in
>> all the paths !? Seems unlikely that this description is fully correct,
>> or we'd have had problems before.
> It is saying _all_ these have to be true, and we already quote
> e
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This error message seems pretty thoroughly unhelpful though. Any ideas
what it's unhappy about?
I think we need to change the pg_regress error messages so that it
includes the command string that f
After looking at the presumably-working uses of system() in initdb and
pg_ctl, I have a theory about the pg_regress problem --- could it be
that Windows system() requires a space between I/O redirection symbols
and pathnames? I see that the pre-existing code consistently puts one,
except in cases
Phil Frost wrote:
> On Wed, Jul 12, 2006 at 06:09:31PM -0400, Bruce Momjian wrote:
> > Phil Frost wrote:
> > > On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote:
> > > >
> > > > Updated text:
> > > >
> > > >For schemas, allows access to objects contained in the specified
> > >
Thanks for the quick feedback.
1) I think the most straightforward way to load an instrumentation
plugin is to define a new custom GUC variable (using the
custom_variable_classes mechanism).
This seems a bit messy and special-purpose.
Agreed, I'm not crazy about using a
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Hmm, that suggests that our code works *only* if there's white space in
> >> all the paths !? Seems unlikely that this description is fully correct,
> >> or we'd have had problems before.
>
> > It is saying _all_ these have to be tr
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Command was:
> ""C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/inst/bin/initdb"
> -D
> "C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_che
> >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
>
> Well, we have a result, courtesy of a special run from Stefan:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=seahorse&dt=
> 2006-07-19%2017:52:41
> has:
>
> Command was:
> ""C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/te
Peter Eisentraut wrote:
Hannu Krosing wrote:
So we would have
src/pl/pljava/README.TXT
and anybody looking for pl-s would find the info in a logical place
Right. When was the last time any user looked under src/pl in the first
place? Or even under src? If you're looking for pljava, it's t
I wrote:
> Ah-hah, so apparently "make install DESTDIR=foo" somehow inserts DESTDIR
> after that instead of before it? What we need is a way to determine the
> paths that make install used ...
AFAICS, the makefiles are just blindly concatenating DESTDIR with bindir
etc, for instance this is how i
For the record, here are the results of our (ongoing) inevstigation into
the index/heap corruption problems I reported a couple of weeks ago.
We were able to trigger the problem with kernels 2.6.16, 2.6.17 and
2.6.18.rc1, with 2.6.16 seeming to be the most flaky.
By replacing the NFS-mounted neta
Ron Mayer <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Right. When was the last time any user looked under src/pl in the first
>> place? Or even under src? If you're looking for pljava, it's the
>> first hit in Google.
> The difference is that I will have reasonable confidence tha
Tom Lane wrote:
I wrote:
Ah-hah, so apparently "make install DESTDIR=foo" somehow inserts DESTDIR
after that instead of before it? What we need is a way to determine the
paths that make install used ...
AFAICS, the makefiles are just blindly concatenating DESTDIR with bindir
etc, for
On Wed, Jul 19, 2006 at 02:42:49PM -0400, Bruce Momjian wrote:
> Updated text:
>
>For schemas, allows access to objects contained in the specified
>schema (assuming that the objects' own privilege requirements are
>also met). Essentially this allows the grantee to look up
I posted about this a couple of days ago, but the post was not
complete. Trying again:
-- suppose the following table exists
CREATE TABLE many_tables (
table_id text, -- defines which virtual table encoded
att0 text,
att1 text,
att2 text,
att3 text
);
-- with some example data
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think we'll need to have the makefile tell us what it thinks the cwd
> is, so if it's a virtual path we'll be able to use that.
I don't see where cwd enters into it. The thing I don't understand is
that the value of the make variable $(bindir) is ap
On Tue, 18 Jul 2006, Nicolai Petri wrote:
If looking at http://www.sai.msu.su/~megera/oddmuse/index.cgi?Hstore the
following is displayed :
-
License
Stable version, included into PostgreSQL distribution, released under BSD
license. Development version,
Joe Conway wrote:
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
Strange. Last time I checked I thought MySQL dump used 'multivalue
lists in inserts' for dumps, for the same reason that we use COPY
I think Andrew identified the critical point upthread: they don't try
t
I wrote:
> I don't see where cwd enters into it. The thing I don't understand is
> that the value of the make variable $(bindir) is apparently changing.
> How can it, when it's been hard-wired into Makefile.global by configure?
After some googling I gather that msys' make has been hacked to
trans
Gregory Stark wrote:
> I've tracked down my problem with pgxs to Makefile.global in
> lib/pgxs/src. These lines seem to be the culprits:
>
> bindir := $(shell pg_config --bindir)
Yes, that's pretty small-minded. It should be something like
PG_CONFIG = pg_config
bindir := $(shell $(PG_CONFIG) --
On Wed, Jul 19, 2006 at 10:29:14AM -0400, Tom Lane wrote:
> The documented behavior is that pgxs invokes whatever pg_config is in
> your PATH.
How do people with multiple PostgreSQL installations keep track of
which installation they're using? I use shell scripts that set
PATH and a few other env
Client has a table with 9 indexes; one is on just ident_id and takes up
75181 pages, the other is on ident_id and another field and uses 117461
pages.
"bdata__ident_filed_departure" btree (ident_id, filed_departuretime),
tablespace "array4"
"bdata_ident" btree (ident_id), tablespace "array4"
Michael Fuhr wrote:
On Wed, Jul 19, 2006 at 10:29:14AM -0400, Tom Lane wrote:
The documented behavior is that pgxs invokes whatever pg_config is in
your PATH.
How do people with multiple PostgreSQL installations keep track of
which installation they're using? I use shell scripts that set
PAT
Michael Fuhr <[EMAIL PROTECTED]> writes:
> How do people with multiple PostgreSQL installations keep track of
> which installation they're using? I use shell scripts that set
> PATH and a few other environment variables and then exec the command
> I want to run (shell aliases would also work).
Ye
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Yes, that's pretty small-minded. It should be something like
> PG_CONFIG = pg_config
> bindir := $(shell $(PG_CONFIG) --bindir)
> That way you can override it.
No objection here, although I'm not entirely convinced why anyone would
prefer doing that
On Tue, Jul 11, 2006 at 10:02:49AM -0400, Tom Lane wrote:
> Currently, we restrict btree index tuples to a size that ensures three of
> them will fit on a page. The motivation for this is the following two
> considerations:
>
> 1. In a non-rightmost page, we need to include a "high key", or page
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, Jul 11, 2006 at 10:02:49AM -0400, Tom Lane wrote:
>> 1. In a non-rightmost page, we need to include a "high key", or page
>> boundary key, that isn't one of the useful data keys.
> Why does a leaf page need a boundary key?
So you can tell whet
On 7/19/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
[snip]
\d does list bdata__ident_filed_departure before bdata_ident; I'm
wondering if the planner is finding the first index with ident_id in it
and stopping there?
From my own experience it was grabbing the first that has the
requested fiel
Tom Lane wrote:
The difference is that I will have reasonable confidence that
the README.TXT under "src/pl" will give instructions that match
the version of PostgreSQL that I have. I assume that README
will call out the version of PL/R or PL/Ruby that I want that
was tested with the release of
Ron Mayer wrote:
Tom Lane wrote:
The difference is that I will have reasonable confidence that
the README.TXT under "src/pl" will give instructions that match
the version of PostgreSQL that I have. I assume that README
will call out the version of PL/R or PL/Ruby that I want that
was tested wi
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Yes, that's pretty small-minded. It should be something like
> > PG_CONFIG = pg_config
> > bindir := $(shell $(PG_CONFIG) --bindir)
> > That way you can override it.
>
> No objection here, although I'm not entirely convinced why an
"Gregory Maxwell" <[EMAIL PROTECTED]> writes:
> On 7/19/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> [snip]
>> \d does list bdata__ident_filed_departure before bdata_ident; I'm
>> wondering if the planner is finding the first index with ident_id in it
>> and stopping there?
>> From my own experie
Currently, the loop in vacuumlazy.c that scans through the tuples on a
page checks each tuple to see if it needs to be frozen (is it's Xmin
older than half-way to wrap-around).
ISTM that as soon as vacuum dirties a page, it might as well update all
tuples it can (any where Xmin < GetOldestXmin()),
On Wed, Jul 19, 2006 at 06:23:44PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Tue, Jul 11, 2006 at 10:02:49AM -0400, Tom Lane wrote:
> >> 1. In a non-rightmost page, we need to include a "high key", or page
> >> boundary key, that isn't one of the useful data keys.
>
On Wed, Jul 19, 2006 at 07:00:40PM -0400, Tom Lane wrote:
> "Gregory Maxwell" <[EMAIL PROTECTED]> writes:
> > On 7/19/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> > [snip]
> >> \d does list bdata__ident_filed_departure before bdata_ident; I'm
> >> wondering if the planner is finding the first inde
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Could you not just scan right and see what the first key was? Thought
> granted, that means there's a chance of a wasted page scan, but I think
> that'd be somewhat of a corner case, so it might not be bad.
No, because (a) that confuses the first key th
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> ISTM that as soon as vacuum dirties a page, it might as well update all
> tuples it can (any where Xmin < GetOldestXmin()), since that won't take
> much time compared to the cost of writing the page out.
Perhaps not, but what it will do is destroy data
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Indeed, if I find a case where there's a large enough number of rows it
> will choose the smaller index. But I'm wondering if it would be better
> to always favor the smaller index, since it would (presumably) be easier
> to keep it in cache?
AFAICS, in
On Wed, Jul 12, 2006 at 03:59:01PM +0900, ITAGAKI Takahiro wrote:
> Hi Hackers,
>
> Can we resurrect the patch proposed by Junji TERAMOTO?
> It removes unnecessary items before btree pages split.
> http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
>
> There was a problem in the
On Sat, Jul 15, 2006 at 09:10:46PM -0400, Greg Stark wrote:
>
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>
> > Maybe we can show progress indicators in status line (either
> > pg_stat_activity.current_query or commandline shown in ps), like
> >
> > WAITING TO START PHASE 1 - WAITING FOR TRANSA
1 - 100 of 117 matches
Mail list logo
