On Wed, 15 Aug 2007, Magnus Hagander wrote:
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, the
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I'd like someone to double-check that though. Also maybe we should back
>>> up the repository first?
>
>> Just for your info: all VMs on tribble, which includes cvs, are backed
>> up at 02:30 every day, CEST
>
>
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'd like someone to double-check that though. Also maybe we should back
>> up the repository first?
> Just for your info: all VMs on tribble, which includes cvs, are backed
> up at 02:30 every day, CEST
Good, but the salient follow
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 m
Tom Lane wrote:
> 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, an
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. Also maybe we should back
> up the repository first?
Just for your info: all VMs on tribble, which includes cvs, are backed
up at 02:30 every day, CEST (that's 00:30 UT
Hello
I write sample about triggers and i have question. is my solution
correct and exists better solution?
Regards
Pavel Stehule
DROP SCHEMA safecache CASCADE;
CREATE SCHEMA safecache;
CREATE TABLE safecache.source_tbl(category int, int_value int);
CREATE TABLE safecache.cache(category int,
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 ar
Jeff Davis wrote:
> 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
> tha
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> One better (and done now):
> find . -nouser -exec chown scrappy {} \;
[ eyeballs repository ... ] Check, that looks great from here.
regards, tom lane
---(end of broadcast)--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
One better (and done now):
find . -nouser -exec chown scrappy {} \;
so, all files that had valid users owning them stay with those ...
- --On Wednesday, August 15, 2007 00:08:07 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
> "Marc G. Fournier" <[EMA
2007/8/15, Merlin Moncure <[EMAIL PROTECTED]>:
> 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) real
2007/8/14, Decibel! <[EMAIL PROTECTED]>:
> 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 o
On Tue, 14 Aug 2007, Alvaro Herrera 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 column/index thatn to th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
'k, let me play with it ...
- --On Wednesday, August 15, 2007 00:13:11 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> It should be done ... if you try and create a tag, it should generate
>> an error m
On Tue, Aug 14, 2007 at 04:08:27PM -0500, Decibel! wrote:
> 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. +
> > >
> > >
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> It should be done ... if you try and create a tag, it should generate
> an error message ...
Uh, nope:
$ cvs tag fooey README
T README
$ cvs log README | more
RCS file: /cvsroot/pgsql/src/backend/optimizer/README,v
Working file: README
head: 1.39
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> That was a good thing, but for security's sake these files ought to be
>> chown'd to some existing committer's account.
> I can do a quick chown -R scrappy on the whole repository ... ok?
Seems close enough, but please keep that tarball around for
-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
-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
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
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
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
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
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
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:
> * 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
"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
-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
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
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
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
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:
> >
> >
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
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)-
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
>
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
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
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
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
"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
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 ...
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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:
> 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
"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
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
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,
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
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
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:
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 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
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
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
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
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
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
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 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
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 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
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
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
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
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
> 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
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
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.
> > >>>
>>> 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
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
"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_
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
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
"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
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
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
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
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
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
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.
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
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
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
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 @
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 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
1 - 100 of 119 matches
Mail list logo
