Heikki Linnakangas [EMAIL PROTECTED] wrote:
I ran some CPU intensive pgbench tests on HOT. Results are not
surprising, HOT makes practically no difference on the total transaction
rate, but reduces the need to vacuum:
unpatched HOT
tps 3680 3790
Thanks for the testing,
ITAGAKI Takahiro wrote:
I gathered oprofile logs. There were 4 HOT-related functions, that didn't
appear in the unpatched test. But it is probably not so serious.
- heap_page_prune 1.84%
- PageRepairFragmentation 0.94%
- pg_qsort 0.44%
On 8/9/07, Tom Lane [EMAIL PROTECTED] wrote:
Yeah, we could simply insist on no change to any column that's used by
any of the expressions. That would be cheap to test.
I am trying to figure out the best way to extract this information. Is there
any
existing code to get all attributes
On 8/9/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2007-08-09 at 15:46 +0530, Pavan Deolasee wrote:
What if we just track the amount of potentially dead space in the
relation
(somebody had suggested that earlier in the thread) ? Every committed
UPDATE/DELETE and aborted
On Tue, 2007-08-14 at 13:24 +0530, Pavan Deolasee wrote:
On 8/9/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2007-08-09 at 15:46 +0530, Pavan Deolasee wrote:
What if we just track the amount of potentially dead space
in the
On Mon, 2007-08-13 at 16:27 -0400, Andrew Dunstan wrote:
Let's say that this file looks just like a postgresql.conf file, except
that any line beginning with '[identifier]' is a config set name for
the lines that follow. So we might have:
[asynch_commit]
synchronous_commit = off
Which brings us back to the original issue. If I decide to stick with
the current implementation and not improve our existing partitioning
mechanisms to scale to 100,000 partitions, I could do something like:
There is a point where you can leave the selection of the correct rows
to normal
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
I'd say that that point currently is well below 2000 partitions for all
common db systems.
I think it will depend heavily on the type of queries you're talking about.
Postgres's constraint_exclusion is a linear search and does quite a bit of
Tom Lane [EMAIL PROTECTED] writes:
But to get to the point: the urgency of testing the patch more
extensively has just moved up a full order of magnitude,
The problem testing this patch is that the window for a committed transaction
to not be synced is quite narrow, especially for the
On Mon, Aug 13, 2007 at 10:04:32AM -0400, Tom Lane wrote:
Well, we are in feature freeze, but as far as I'm concerned ecpg is its
own little fiefdom. If you have enough confidence in these changes to
apply them now, no one is going to question you.
Okay, done. Please test it!
There were some
I'm comparing now different version of page layer, and I have two questions:
1) We now store only low 16bits TLI, but name in structure stays same.
Maybe pg_tli_lo could be better.
2) HASOID has been moved in infomask and original place is unused. Is
there some reason for that? This change
Simon Riggs wrote:
On Mon, 2007-08-13 at 16:27 -0400, Andrew Dunstan wrote:
Let's say that this file looks just like a postgresql.conf file, except
that any line beginning with '[identifier]' is a config set name for
the lines that follow. So we might have:
[asynch_commit]
Oleg Bartunov wrote:
On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
Maybe I'm missing something, but it seems to me that the configuration
is more attached to a column/index thatn to the whole database. If
there's a default in an expression, I'd rather expect this default to be
drawn from the
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Sounds fine, though I'd prefer this in XML to allow further
extensibility in the future.
YAML?
That would seem to require making pg_regress depend on some XML library
or other, which is a dependency I'd rather not add.
Pavan Deolasee [EMAIL PROTECTED] writes:
I am trying to figure out the best way to extract this information. Is there
any
existing code to get all attributes used in the expressions ? Or do I need
to walk the tree and extract that information ?
There are a number of near matches in
Pavan Deolasee [EMAIL PROTECTED] writes:
What if we just track the amount of potentially dead space in the
relation
(somebody had suggested that earlier in the thread) ? Every committed
UPDATE/DELETE and aborted UPDATE/INSERT would increment
the dead space. Whenever page fragmentation is
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Sounds fine, though I'd prefer this in XML to allow further
extensibility in the future.
YAML?
That would seem to require making pg_regress depend on some XML library
or other, which is a
Alvaro Herrera [EMAIL PROTECTED] writes:
Oleg Bartunov wrote:
I'm tired to repeat - index itself doesn't know about configuration !
Is there a way to change that? For example store the configuration in a
metapage or something?
I think Heikki's suggestion of having each configuration
Zdenek Kotala [EMAIL PROTECTED] writes:
2) HASOID has been moved in infomask and original place is unused. Is
there some reason for that?
To keep it next to the other bits that are about tuple content rather
than transactional behavior.
This change little bit complicate tuple
header
Tom Lane [EMAIL PROTECTED] writes:
Pavan Deolasee [EMAIL PROTECTED] writes:
What if we just track the amount of potentially dead space in the
relation
(somebody had suggested that earlier in the thread) ? Every committed
UPDATE/DELETE and aborted UPDATE/INSERT would increment
the dead
On Tue, 2007-08-14 at 10:10 -0400, Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
What if we just track the amount of potentially dead space in the
relation
(somebody had suggested that earlier in the thread) ? Every committed
UPDATE/DELETE and aborted UPDATE/INSERT would
Tom,
We're getting some additional test infrastructre at Sun; I'll throw this on
the pile of stuff to test.
However, the current tests we're doing are regression tests and benchmark
runs. If there's some other kind of testing we need to do, I'll need
specifics.
--
Josh Berkus
PostgreSQL @
TODO item?
---
Michael Glaesemann wrote:
-- Start of PGP signed section.
On Aug 8, 2007, at 12:18 , Decibel! wrote:
On Wed, Aug 08, 2007 at 12:03:34PM -0500, Michael Glaesemann wrote:
Personally, I think
Decibel! wrote:
-- Start of PGP signed section.
On Thu, Aug 09, 2007 at 09:57:48AM +0900, ITAGAKI Takahiro wrote:
If HOT gets into 8.3, we might need a GUC to set database wide heap
fillfactor to an appropriate value.
I have no objection to do that, but we will need other default
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Before I wrap up the CSVlog stuff, we need to decide whether or not to
change the name of the redirect_stderr setting, and if so to what. The
reason is that with CSVlogs it will no longer apply just
2007/8/14, Bruce Momjian [EMAIL PROTECTED]:
TODO item?
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 6: explain analyze is your friend
I am against. It's too simple do it in SQL language.
Regards
Bruce Momjian wrote:
Andrew Dunstan wrote:
I suggest redirect_logs, although it's arguably too general as it
doesn't apply to syslog/eventlog.
Perhaps it should be named analogously to stats_start_collector,
ie think of the syslogger process as a log collector. I don't
much
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
I suggest redirect_logs, although it's arguably too general as it
doesn't apply to syslog/eventlog.
Perhaps it should be named analogously to stats_start_collector,
ie think of the syslogger process as a
Gregory Stark [EMAIL PROTECTED] writes:
The problem testing this patch is that the window for a committed transaction
to not be synced is quite narrow, especially for the regression tests. For
testing purposes I wonder if there are ways we can widen this window. Some
ideas, some wackier than
On Tue, 2007-08-14 at 12:09 -0400, Tom Lane wrote:
I think this is better done by code inspection, ie, look for places that
assume HEAP_XMIN/XMAX_COMMITTED is or can be set.
I made a pass over CVS HEAD and found some apparent trouble spots:
heapam.c lines 1843-1852 presume previous xmax can
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
I suggest redirect_logs, although it's arguably too general as it
doesn't apply to syslog/eventlog.
Perhaps it should be named analogously to stats_start_collector,
ie think
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2007-08-14 at 12:09 -0400, Tom Lane wrote:
heapam.c lines 1843-1852 presume previous xmax can be hinted
immediately, ditto lines 2167-2176, ditto lines 2716-2725.
I think probably we should just remove those lines --- they are only
trying to save
Alvaro Herrera wrote:
That sounds like you want to log when the collector starts, which is not
the case and is confusing -- what collector is it talking about? This
is about starting the log collector.
Yea, good point. I was just wondering because I don't see 'start' used
in anywhere
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Seems to me this proves nothing much, since it doesn't use the same SysV
semaphore API PG does.
I was trying to copy the semaphore API exactly assuming
USE_NAMED_POSIX_SEMAPHORES
Andrew Dunstan wrote:
Alvaro Herrera wrote:
That sounds like you want to log when the collector starts, which is not
the case and is confusing -- what collector is it talking about? This
is about starting the log collector.
Yea, good point. I was just wondering because I
On Tue, Aug 14, 2007 at 11:42 AM, in message [EMAIL PROTECTED],
Andrew Dunstan [EMAIL PROTECTED] wrote:
Alvaro Herrera wrote:
In other places we just name the feature that's to be
started, for example we don't use start_autovacuum.
How about just log_collector then?
+1
Unambiguous and
Bruce Momjian wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
That sounds like you want to log when the collector starts, which is not
the case and is confusing -- what collector is it talking about? This
is about starting the log collector.
Yea, good point. I
Bruce Momjian wrote:
TODO item?
Probably. See SQL2003 UNNEST:
collection derived table ::=
UNNEST left paren collection value expression right paren
[ WITH ORDINALITY ]
collection value expression ::=
array value expression
| multiset value expression
Joe
The problem here is that log seems to be a verb in log_collector
which is what makes it confusing. So we need another verb to make it
clear that log is not one. This is not a problem with autovacuum
because that one cannot be confused with a verb.
start_log_collector still gets my vote.
On 8/13/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Removing the default configuration setting altogether removes the 2nd
problem, but that's not good from a usability point of view. And it
doesn't solve the
Josh Berkus [EMAIL PROTECTED] writes:
The problem here is that log seems to be a verb in log_collector
which is what makes it confusing. So we need another verb to make it
clear that log is not one. This is not a problem with autovacuum
because that one cannot be confused with a verb.
Mike Rylander wrote:
This is just my $0.02 as a fairly heavy user of the current tsearch2
code, but I sincerely hope you do not cripple the system by removing
the ability to store tsvectors built using arbitrary configurations in
a single column. Yes, it can lead to unexpected results if you
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Removing the default configuration setting altogether removes the 2nd
problem, but that's not good from a usability point of view. And it
doesn't solve the general issue, you can still do things
On Mon, 2007-08-13 at 16:27 -0400, Andrew Dunstan wrote:
[asynch_commit]
synchronous_commit = off
[no_fsync]
fsync = off
This is the Windows INI file format. As such, it's easy to find code
samples in almost any language that parse this format for you. For
example, Python has a core
Josh Berkus wrote:
The problem here is that log seems to be a verb in log_collector
which is what makes it confusing. So we need another verb to make it
clear that log is not one. This is not a problem with autovacuum
because that one cannot be confused with a verb.
start_log_collector
On Tue, 14 Aug 2007, Alvaro Herrera wrote:
Oleg Bartunov wrote:
On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
Maybe I'm missing something, but it seems to me that the configuration
is more attached to a column/index thatn to the whole database. If
there's a default in an expression, I'd
A lot of work has been done to try to get /contrib/tsearch2 into the
core backend for 8.3, but we have hit a roadblock in how to handle
multiple text search configurations. (FYI, the documentation is at
http://momjian.us/expire/textsearch/HTML/textsearch.html.)
There are three options for
On Aug 14, 2007, at 12:40 , Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
The problem here is that log seems to be a verb in log_collector
which is what makes it confusing. So we need another verb to
make it
clear that log is not one. This is not a problem with
autovacuum
Bruce Momjian wrote:
A lot of work has been done to try to get /contrib/tsearch2 into the
core backend for 8.3, but we have hit a roadblock in how to handle
multiple text search configurations. (FYI, the documentation is at
http://momjian.us/expire/textsearch/HTML/textsearch.html.)
There
Bruce Momjian wrote:
#3 requires more code and is probably not something we want to do at
this stage in 8.3 development. It requires passing typmod values
between functions and operators (not something we have done easily in
the past).
It does? I was thinking of implicitly creating a new
Michael Glaesemann [EMAIL PROTECTED] writes:
AIUI, if the-GUC-yet-to-be-named is not enabled, no logging is done
at all: messages are just sent to stderr. Why something simple like
enable_logging or start_logger?
Um, that's still logging by my definition. I could live with
start_logger,
Alvaro Herrera wrote:
What is the worst consequence of mismatching configuration? Does it
cause a system crash? A backend hang? A corrupted index? Lost data?
Or does it, as I assume, just fail to return the exact result set that
would be returned if the correct configuration was supplied?
On Tue, Aug 14, 2007 at 03:15:44PM -0400, Alvaro Herrera wrote:
Bruce Momjian wrote:
A lot of work has been done to try to get /contrib/tsearch2 into the
core backend for 8.3, but we have hit a roadblock in how to handle
multiple text search configurations. (FYI, the documentation is at
Heikki Linnakangas wrote:
Josh Berkus wrote:
The problem here is that log seems to be a verb in log_collector
which is what makes it confusing. So we need another verb to make it
clear that log is not one. This is not a problem with autovacuum
because that one cannot be confused with a
On 8/15/07, Tom Lane [EMAIL PROTECTED] wrote:
For example, log_line_prefix is misnamed under this rule, and ought to
be logging_line_prefix. Similarly, redirect_stderr would become
logging_something --- I'd prefer logging_start_collector but could
live with logging_collector (or maybe
Heikki Linnakangas wrote:
Bruce Momjian wrote:
#3 requires more code and is probably not something we want to do at
this stage in 8.3 development. It requires passing typmod values
between functions and operators (not something we have done easily in
the past).
It does? I was thinking
With so many people trying to paint this particular bikeshed, my
suggestion to Andrew is to commit the patch as is and leave the rename
for a later patch.
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
Jude: I wish humans laid eggs
Ringlord: Why would you want
On 8/14/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Mike Rylander wrote:
[snip]
Don't you need to use the right configuration to parse the query into a
tsquery as well?
Only if the user (or user agent) can supply enough information to move
away from the configured default of, say, en-US.
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Removing the default configuration setting altogether removes the 2nd
problem, but that's not good from a usability point of view. And it
doesn't solve the general
Brendan Jurd [EMAIL PROTECTED] writes:
On 8/15/07, Tom Lane [EMAIL PROTECTED] wrote:
For example, log_line_prefix is misnamed under this rule, and ought to
be logging_line_prefix. Similarly, redirect_stderr would become
logging_something --- I'd prefer logging_start_collector but could
live
Bruce Momjian wrote:
Basically, the default GUC doesn't work because of:
error prone
if super-user only, non-super-user doesn't work on restore
if non-super-user, can cause mismatch (perhaps this is the best
option), and restore still a problem (no storage of
Mike Rylander wrote:
This is just my $0.02 as a fairly heavy user of the current tsearch2
code, but I sincerely hope you do not cripple the system by removing
the ability to store tsvectors built using arbitrary configurations in
a single column. Yes, it can lead to unexpected results if you
Alvaro Herrera wrote:
Bruce Momjian wrote:
Basically, the default GUC doesn't work because of:
error prone
if super-user only, non-super-user doesn't work on restore
if non-super-user, can cause mismatch (perhaps this is the best
option), and restore still a
On 8/14/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Basically, the default GUC doesn't work because of:
error prone
if super-user only, non-super-user doesn't work on restore
if non-super-user, can cause mismatch (perhaps this is the best
On 8/15/07, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
The consistent prefix idea sounds good; does logging_enable jive
with your proposal?
I dislike it. I claim that logging to plain stderr (without the
syslogger process) is still logging. Logging to syslog
On Tue, Aug 14, 2007 at 05:38:33PM +0200, Pavel Stehule wrote:
2007/8/14, Bruce Momjian [EMAIL PROTECTED]:
TODO item?
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 6: explain analyze is
Bruce Momjian escribió:
Mike Rylander wrote:
This is just my $0.02 as a fairly heavy user of the current tsearch2
code, but I sincerely hope you do not cripple the system by removing
the ability to store tsvectors built using arbitrary configurations in
a single column. Yes, it can lead
Oleg Bartunov wrote:
On Tue, 14 Aug 2007, Alvaro Herrera wrote:
Oleg Bartunov wrote:
On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
Maybe I'm missing something, but it seems to me that the configuration
is more attached to a column/index thatn to the whole database. If
there's a default in
I recently had a chat with someone who was pretty intimate with Adabas
for a number of years who's in the process of figuring things out
about PostgreSQL. We poked at bits of the respective implementations,
seeing some similarities and differences. He pointed out one aspect
of index handling
Isn't this what Grouped Index Tuples is?
On Tue, Aug 14, 2007 at 05:21:16PM -0400, Chris Browne wrote:
I recently had a chat with someone who was pretty intimate with Adabas
for a number of years who's in the process of figuring things out
about PostgreSQL. We poked at bits of the respective
On 8/14/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Oleg Bartunov wrote:
On Tue, 14 Aug 2007, Alvaro Herrera wrote:
Oleg Bartunov wrote:
On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
Maybe I'm missing something, but it seems to me that the configuration
is more attached to a
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I haven't really seen anyone else arguing about this. I wonder whether
you are being overly zealous about it.
Uh, OK, but no one has told me how a database restore without a
configuration name would work, so I am all ears.
It's
Mike Rylander wrote:
On 8/14/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Basically, the default GUC doesn't work because of:
error prone
if super-user only, non-super-user doesn't work on restore
if non-super-user, can cause mismatch
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian escribió:
What has really hurt the default GUC idea is how to do restores from a
pg_dump.
I guess what should happen is that pg_dump should include a
SET default_text_search_config = 'foo'
just before the CREATE INDEX, like we do for
Looking into recent buildfarm failures on the 7.4 branch:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
It looks like parts of the CVS repository have been mistagged as belonging
to REL7_4_STABLE or have been corrupted somehow:
Bruce Momjian [EMAIL PROTECTED] writes:
The other point is that we should have a good idea of the API because
if it gets into 8.3 it will be harder to change.
Yeah, once it's in core we have a pretty strong backwards-compatibility
restriction to deal with. Someone upthread claimed we can
Kris Jurka [EMAIL PROTECTED] writes:
It looks like parts of the CVS repository have been mistagged as belonging
to REL7_4_STABLE or have been corrupted somehow:
http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/btree_gist/btree_bit.c?sortby=date;only_with_tag=REL7_4_STABLE
Hmm ...
Mike Rylander [EMAIL PROTECTED] writes:
My application (http://open-ils.org, which run 80% of the public
libraries in Georgia, USA, http://gapines.org and
http://georgialibraries.org/lib/pines.html) requires that I be able to
search a corpus of bibliographic records in a mix of languages, and
I wrote:
Kris Jurka [EMAIL PROTECTED] writes:
It looks like parts of the CVS repository have been mistagged as belonging
to REL7_4_STABLE or have been corrupted somehow:
http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/btree_gist/btree_bit.c?sortby=date;only_with_tag=REL7_4_STABLE
Tom Lane wrote:
In the meantime, though, it's not quite clear why this would lead to
a buildfarm failure --- it should just mean a lot of extraneous files
appearing in a fresh checkout. (Looks a bit harder ... Oh, it looks
like btree_gist has some files that used to be autogenerated and are
On Tue, 2007-08-14 at 16:27 -0500, Decibel! wrote:
Isn't this what Grouped Index Tuples is?
http://community.enterprisedb.com/git/git-readme.txt
It looks like GIT is a little different.
GIT actually stores a lower-bound key of a contiguous* range of keys
that all point to the same page, and
Andrew Dunstan [EMAIL PROTECTED] writes:
Looking at the Committers mail, it looks like there have only been two
very small commits since Michael's series of commits around 12 to 13.5
hours ago, and before that nothing since around 28 hours ago. Do we have
a backup snapshot of the repo taken
I wrote:
I did a fresh checkout of the 7.4 branch and diff'd against my local
copy, and it seems clear that every file that was not in 7.4 at all has
had its HEAD version tagged as REL7_4_STABLE. The files that did exist
then are all right. That's throughout the whole tree, not just in
Tom Lane wrote:
So I think that cvs rtag -d REL7_4_STABLE pgsql will fix it.
I'd like someone to double-check that though.
I will test on a copy of my mirror.
Also maybe we should back
up the repository first?
Amen.
cheers
andrew
---(end of
Andrew Dunstan wrote:
Tom Lane wrote:
So I think that cvs rtag -d REL7_4_STABLE pgsql will fix it.
I'd like someone to double-check that though.
I will test on a copy of my mirror.
I copied the mirror, did a checkout from it, ran the command above in
the checked out version, then
On 8/14/07, ITAGAKI Takahiro [EMAIL PROTECTED] wrote:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
I ran some CPU intensive pgbench tests on HOT. Results are not
surprising, HOT makes practically no difference on the total transaction
rate, but reduces the need to vacuum:
On 8/14/07, Bruce Momjian [EMAIL PROTECTED] wrote:
TODO item?
I would say yes...array_accum is virtually an essential function when
working with arrays and the suggested array_to_set (and it's built in
cousin, _pg_expand_array) really should not be built around
generate_series when a C function
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian escribi?:
What has really hurt the default GUC idea is how to do restores from a
pg_dump.
I guess what should happen is that pg_dump should include a
SET default_text_search_config = 'foo'
just before the CREATE
Andrew Dunstan [EMAIL PROTECTED] writes:
So I'd say your strategy looks good - backup and remove the phony tag.
I'd also say we should probably be logging tag commands in taginfo.
Presumably we mere mortal committers should not be doing any tagging
whatsoever, and tags should only be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, August 14, 2007 22:20:16 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
+1 ... we should at least log such commands, and maybe disallow to anyone
except Marc's pgsql account. Particularly since they don't get
reported in
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tuesday, August 14, 2007 22:20:16 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Meanwhile, is there anyone around who can either (1) tar up the
repository directory tree as root, or (2) confirm that a tarball
made by a non-root committer is sufficient?
Tom Lane wrote:
* For queries, there is not anything very wrong with having a default
configuration, but the trick is how to get the planner to match that up
with an index that's written with the two-parameter form of to_tsvector.
One hackish possibility is to define the single-parameter form
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Since I don't think that a datatype solution is the way to go,
I don't feel that we are as far away from an agreement as Bruce
is worried about.
Well, from where I sit, there is one person saying give me the foot gun,
and Heikki saying
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The other point is that we should have a good idea of the API because
if it gets into 8.3 it will be harder to change.
Yeah, once it's in core we have a pretty strong backwards-compatibility
restriction to deal with. Someone
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Since I don't think that a datatype solution is the way to go,
I don't feel that we are as far away from an agreement as Bruce
is worried about.
Well, from where I sit, there is one person saying give me the foot
I wrote:
Great --- launching cvs rtag command now.
Done, and I got a plausible-looking mix of messages like
cvs rtag: Not removing branch tag `REL7_4_STABLE' from
`/cvsroot/pgsql/src/tutorial/funcs_new.c,v'.
and a fresh checkout of REL7_4_STABLE now matches what I had locally.
So I think we
Bruce Momjian wrote:
The people who actually use tsearch2 seem to all have the same opinion ...
so I think we can't go too far in the bullet-proofing direction.
Yeah.
But I would like a design that is bulletproof in dump/reload scenarios,
and I think it's fair to question that aspect
On 8/14/07, Gregory Stark [EMAIL PROTECTED] wrote:
Mike Rylander [EMAIL PROTECTED] writes:
My application (http://open-ils.org, which run 80% of the public
libraries in Georgia, USA, http://gapines.org and
http://georgialibraries.org/lib/pines.html) requires that I be able to
search a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, August 14, 2007 23:26:03 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
I wrote:
Great --- launching cvs rtag command now.
Done, and I got a plausible-looking mix of messages like
cvs rtag: Not removing branch tag `REL7_4_STABLE' from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, August 14, 2007 23:26:03 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
* restrict, or at least log, cvs tag/rtag commands. Maybe report them
to pgsql-committers.
It should be done ... if you try and create a tag, it should generate an
1 - 100 of 110 matches
Mail list logo
