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 3
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.
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 attri
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 abo
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 '[' 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 norm
"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 b
"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 re
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 so
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 li
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 '[' 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
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 bac
"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
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 configu
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 u
"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
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
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 exp
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 def
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 l
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.
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 colle
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
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 t
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
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
"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
>> try
On Tue, 2007-08-14 at 12:29 -0400, Tom Lane wrote:
> "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 probab
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_
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 w
>>> 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
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.
> > >>>
Bruce Momjian wrote:
TODO item?
Probably. See SQL2003 UNNEST:
::=
UNNEST
[ WITH ORDINALITY ]
::=
|
Joe
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
> 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 ge
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
> > >> do
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 wi
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 y
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 st
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 libra
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.
>>
>> star
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 rather
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 control
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
"autovacuu
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.)
>
> Th
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_logg
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 supplie
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
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 w
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" (o
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 wa
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,
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
> doe
"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_collect
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 y
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
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
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. Lo
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: explai
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 c
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
t
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 that
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 respectiv
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
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
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
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
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:
http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/btr
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 a
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 langua
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_ST
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
no
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, an
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
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 broadcast)-
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 r
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 funct
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 b
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 pgsql-co
"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
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 fo
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 Hei
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. Someon
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 g
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 wal
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 o
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
-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_STABL
1 - 100 of 119 matches
Mail list logo
