Robert Haas wrote:
On Thu, Feb 19, 2009 at 8:36 AM, Teodor Sigaev wrote:
handle it is not terribly efficient, oh well. The one thing that
concerns me is - what will happen in a hot standby environment, when
that patch is committed? In that situation, I believe that we can't
call modify any he
I wrote:
select foo from (
SELECT quote_ident($2[i]) as foo, i
FROM generate_series(1, array_upper($2, 1)) AS s(i)
EXCEPT
SELECT quote_ident(p.proname)
FROM pg_catalog.pg_proc p
JOIN pg_catalog.pg_namespace n
ON p.pronamespace = n.oid
On Thu, Feb 19, 2009 at 8:36 AM, Teodor Sigaev wrote:
>> and I still think that's bogus. It seems clear that this is going to
>> change much faster than plans are going to be invalidated, and if
>> autovacuum is doing its job, the pending list won't get long enough to
>> matter much anyway, right
Tom Lane wrote:
o...@pyrenet.fr writes:
pg_restore -C -m 4 -d template1 db.dmp
gives numerous errors, mostly no such relation at index creation time.
You sure you don't get exactly the same without -m?
Yeah, I have reproduced this. It's because we reconnect to the wrong db
in
David E. Wheeler wrote:
On Feb 19, 2009, at 5:45 PM, Andrew Dunstan wrote:
"A limitation of this feature is that an ORDER BY clause applying to
the result of a UNION, INTERSECT, or EXCEPT clause can only specify
an output column name or number, not an expression."
Why not just say "order b
On Feb 19, 2009, at 5:45 PM, Andrew Dunstan wrote:
"A limitation of this feature is that an ORDER BY clause applying to
the result of a UNION, INTERSECT, or EXCEPT clause can only specify
an output column name or number, not an expression."
Why not just say "order by 1" ?
Well, in this ca
David E. Wheeler wrote:
Howdy,
I was just updating a function in pgTAP that, given a schema name and
an array of function names, returns a set of those function names that
are not in the named schema. I got it working with a subquery, and
David Fetter suggested that I try an EXCEPT query in
On Thu, 2009-02-19 at 17:13 -0800, David E. Wheeler wrote:
> CREATE OR REPLACE FUNCTION mytest(NAME, NAME[]) RETURNS setof text AS
> $$
> SELECT quote_ident($2[i])
>FROM generate_series(1, array_upper($2, 1)) AS s(i)
> EXCEPT
> SELECT quote_ident(p.proname)
Howdy,
I was just updating a function in pgTAP that, given a schema name and
an array of function names, returns a set of those function names that
are not in the named schema. I got it working with a subquery, and
David Fetter suggested that I try an EXCEPT query instead. The only
proble
On Thu, Feb 19, 2009 at 01:50:55PM -0700, Josh Tolley wrote:
> (my new daughter will be 24 hours old in a little bit, though, so it
> might be a while!)
Pics!
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP:
Jaime Casanova writes:
> if it is a "can't happen" scenario then why not make it an assert?
Asserts on data-consistency checks aren't really a good idea.
(IOW this is "can't happen" only as long as your database isn't
corrupt...)
regards, tom lane
--
Sent via pgsql-hac
On 2/19/09, Heikki Linnakangas wrote:
> Tom Lane wrote:
>> (I'm unconvinced that it is dead code, but even if it is it'd be folly
>> to remove it.)
>
> Agreed, it's a useful safeguard, even it it's a "can't happen" scenario.
>
if it is a "can't happen" scenario then why not make it an assert?
--
On Thu, Feb 19, 2009 at 4:53 PM, Tom Lane wrote:
> Greg Stark writes:
>> It's tempting to have Hash cheat and just peek at the node beneath it
>> to see if it's a HashAggregate, in which case it could call a special
>> method to request the whole hash. But it would have to know that it's
>> just
Greg Stark writes:
> It's tempting to have Hash cheat and just peek at the node beneath it
> to see if it's a HashAggregate, in which case it could call a special
> method to request the whole hash. But it would have to know that it's
> just a plain uniquify and not implementing a GROUP BY.
More
On Thu, Feb 19, 2009 at 7:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 19, 2009 at 1:20 PM, Tom Lane wrote:
>>> [ back to planner stuff after a hiatus ]
>
>> Well, as I wrote upthread:
>
> What you're actually suggesting is modifying the executor to incorporate
> the unique-ficati
On 2/14/09, Jaime Casanova wrote:
> On Sat, Feb 14, 2009 at 12:46 AM, KaiGai Kohei wrote:
>>
>
>> If you set up a VM from scratch, Fedora enables to install
>> via remote repository using minimum bootable image.
>>
>> http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/i386/iso/
On Thu, Feb 19, 2009 at 3:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 19, 2009 at 1:38 PM, Tom Lane wrote:
>>> I'll change the comment. Does this help?
>
>> It's an improvement, but your example above is so helpful in
>> understanding what is going on here that it might be worth
On Wed, Feb 18, 2009 at 11:20:03PM -0500, Robert Haas wrote:
> On Wed, Jan 7, 2009 at 9:14 AM, Joshua Tolley wrote:
> > On Tue, Jan 06, 2009 at 11:49:57PM -0500, Robert Haas wrote:
> >> Josh / eggyknap -
> >>
> >> Can you rerun your performance tests with this version of the patch?
> >>
> >> ...Ro
Robert Haas writes:
> On Thu, Feb 19, 2009 at 1:38 PM, Tom Lane wrote:
>> I'll change the comment. Does this help?
> It's an improvement, but your example above is so helpful in
> understanding what is going on here that it might be worth explicitly
> mentioning it in the comment, maybe somethi
On Thursday 19 February 2009 22:17:54 Adriano Lange wrote:
> Tom Lane escreveu:
> > But really I think the problem with this approach is that the
> > information density is too low --- imagine what it would look like in a
> > six-or-more-way join. I don't think the graphical approach is helpful
>
Heikki Linnakangas writes:
> Tom Lane wrote:
>> The thing wrong with it is assuming that nothing interesting will happen
>> during proc_exit(). We hang enough stuff on on_proc_exit hooks that
>> that seems like a pretty shaky assumption.
> I can't get too worried, given that proc_exit() is a ver
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
Maybe the postmaster should wait for startup process exit before
deciding to open for business, instead of just a signal.
Not a bad idea. Although, there's nothing wrong with the current way
either. The startup process does a proc_e
Tom Lane escreveu:
But really I think the problem with this approach is that the
information density is too low --- imagine what it would look like in a
six-or-more-way join. I don't think the graphical approach is helpful
at all here.
I was thinking about the hard visualization and navigabili
On Thu, Feb 19, 2009 at 2:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 19, 2009 at 1:20 PM, Tom Lane wrote:
>>> [ back to planner stuff after a hiatus ]
>
>> Well, as I wrote upthread:
>
> What you're actually suggesting is modifying the executor to incorporate
> the unique-ficati
Robert Haas writes:
> On Thu, Feb 19, 2009 at 1:20 PM, Tom Lane wrote:
>> [ back to planner stuff after a hiatus ]
> Well, as I wrote upthread:
What you're actually suggesting is modifying the executor to incorporate
the unique-fication logic into hashjoin and/or mergejoin. Maybe, but
that cod
On Thu, Feb 19, 2009 at 02:02:06PM -0500, Tom Lane wrote:
> Sam Mason writes:
> > On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
> >> AFAIK, the Oracle behavior is just about entirely unrelated to the
> >> parser --- it's a matter of runtime comparison behavior. It is
> >> certainly *n
On Thu, Feb 19, 2009 at 1:20 PM, Tom Lane wrote:
> [ back to planner stuff after a hiatus ]
>
> Robert Haas writes:
>> Right, so maybe I wasn't as clear as I could have been in asking the
>> question. I do understand how it can be a win to unique B and use it
>> as the OUTER relation (jointype J
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> vacuum analyze doesn't unfreeze pg_class. It could create unfrozen
> > >> tuples in pg_statistic, perhaps, but we could easily fix that by
> > >> truncating pg_statistic afterwards (its not like there wi
Sam Mason writes:
> On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
>> AFAIK, the Oracle behavior is just about entirely unrelated to the
>> parser --- it's a matter of runtime comparison behavior. It is
>> certainly *not* restricted to literal NULL/'' constants, which is the
>> only ca
On Thu, Feb 19, 2009 at 1:38 PM, Tom Lane wrote:
> [ after re-reading the code a bit ]
>
> Robert Haas writes:
>> Cool. On the topic of documentation, I find the following comment in
>> joinrels.c rather impenetrable:
>
>> /*
>> * Do these steps o
On Thu, Feb 19, 2009 at 06:29:25PM +, Sam Mason wrote:
> On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > I'd be quite interested to support some kind of hook to deal with this
> > > Oracle null issue. It would be a great help for porting projects.
[ after re-reading the code a bit ]
Robert Haas writes:
> Cool. On the topic of documentation, I find the following comment in
> joinrels.c rather impenetrable:
> /*
> * Do these steps only if we actually have a
> regular semijoin,
>
On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > I'd be quite interested to support some kind of hook to deal with this
> > Oracle null issue. It would be a great help for porting projects.
>
> > However, doing this properly is probably more complex and n
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> vacuum analyze doesn't unfreeze pg_class. It could create unfrozen
> >> tuples in pg_statistic, perhaps, but we could easily fix that by
> >> truncating pg_statistic afterwards (its not like there will be useful
> >> data there...)
[ back to planner stuff after a hiatus ]
Robert Haas writes:
> Right, so maybe I wasn't as clear as I could have been in asking the
> question. I do understand how it can be a win to unique B and use it
> as the OUTER relation (jointype JOIN_UNIQUE_OUTER). What I don't
> understand is how it ca
Bruce Momjian writes:
> Tom Lane wrote:
>> vacuum analyze doesn't unfreeze pg_class. It could create unfrozen
>> tuples in pg_statistic, perhaps, but we could easily fix that by
>> truncating pg_statistic afterwards (its not like there will be useful
>> data there...)
> I have added --analyze to
Thought folks might get a kick out of this since he's referenced all
over our code: http://www.appelbaum.net/
--
Decibel!, aka Jim C. Nasby, Database Architect deci...@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
--
Sent via pgsql-hackers mailing list (pgsq
Tom Lane wrote:
> Zeugswetter Andreas OSB sIT writes:
> > I am still answering here because my question was related to upgrade.
> > I think you need to turn off autovacuum before freezing to avoid a later
> > analyze
> > that unfreezes pg_class (or the stats table).
>
> vacuum analyze doesn't un
Zeugswetter Andreas OSB sIT writes:
> I am still answering here because my question was related to upgrade.
> I think you need to turn off autovacuum before freezing to avoid a later
> analyze
> that unfreezes pg_class (or the stats table).
vacuum analyze doesn't unfreeze pg_class. It could cre
> > One more question I have though is:
> > How do you make sure noone (e.g. autovacuum analyze)
> > unfreezes tuples after the vacuum freeze ?
>
> I will start a new thread to answer this question, but the short answer
> is that the freeze only needs to happen in a fresh initdb database, and
>
From: pgsql-hackers-ow...@postgresql.org on behalf of Robert Haas
I think what we need here is some very simple testing to demonstrate
that this patch demonstrates a speed-up even when the inner side of
the join is a joinrel rather than a baserel. Can you suggest
Andrew Chernow wrote:
Andrew Chernow wrote:
> Maybe better, have it return a zero/nonzero error code; where one
of the
> possibilities for failure is "you passed a bit I didn't understand".
Why not just return those bit(s) instead of an arbitrary code? How
about:
-1 = error (if it ever
Euler Taveira de Oliveira writes:
> Robert Treat escreveu:
>> I think this build is a couple weeks old, but is the pg_autovacuum table
>> really gone in 8.4, or just deprecated?
>>
> It is gone.
http://archives.postgresql.org/pgsql-committers/2009-02/msg00077.php
regar
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Maybe the postmaster should wait for startup process exit before
>> deciding to open for business, instead of just a signal.
> Not a bad idea. Although, there's nothing wrong with the current way
> either. The startup process does a proc_exit(0) ri
Tom Lane wrote:
Heikki Linnakangas writes:
Simon Riggs wrote:
More likely to be an uncommon race condition, rather than a error
specific to dungbeetle. If startup process death is slow, this could
happen, though hasn't occurred in other tests.
True, the startup process can live for a short
Tom Lane wrote:
(I'm unconvinced that it is dead code, but even if it is it'd be folly
to remove it.)
Agreed, it's a useful safeguard, even it it's a "can't happen" scenario.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hac
Heikki Linnakangas writes:
> Now that think about this more, I don't see either how that check in
> EvalPlanQual could ever be true.
It's there primarily to make the tuple chain chasing code the same
as in other places. Whether it happens to be dead code today because of
arcane details of the u
On Thu, 19 Feb 2009, Tom Lane wrote:
Date: Thu, 19 Feb 2009 10:05:32 -0500
From: Tom Lane
To: o...@pyrenet.fr
Cc: pgsql-hackers list
Subject: Re: [HACKERS] pg_restore new option -m
o...@pyrenet.fr writes:
On Wed, 18 Feb 2009, Tom Lane wrote:
You sure you don't get exactly the same without
Robert Treat escreveu:
> I think this build is a couple weeks old, but is the pg_autovacuum table
> really gone in 8.4, or just deprecated?
>
It is gone. As stated in the docs [1], pg_autovacuum catalog was just a
workaround.
[1] http://www.postgresql.org/docs/8.3/static/routine-vacuuming.html
On Monday 16 February 2009 11:20:11 Alvaro Herrera wrote:
> Joshua D. Drake wrote:
> > Thanks for the work around, but that is ridiculous. I still say this is
> > a bug.
>
> Yes, which is why we fixed it on 8.4 by dropping pg_autovacuum. (As
> Jaime and Tom say, it's actually pilot error, but the
o...@pyrenet.fr wrote:
pg_restore -C -m 4 -d template1 db.dmp
gives numerous errors, mostly no such relation at index creation time.
You sure you don't get exactly the same without -m?
yes!
the pg.gz script shows the output of :
pg_restore -C -m
pg_restore -C
dropdb;createdb; pg_restor
o...@pyrenet.fr writes:
> On Wed, 18 Feb 2009, Tom Lane wrote:
>> You sure you don't get exactly the same without -m?
>>
> yes!
We're going to need to see the test case then.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Heikki Linnakangas writes:
> Simon Riggs wrote:
>> More likely to be an uncommon race condition, rather than a error
>> specific to dungbeetle. If startup process death is slow, this could
>> happen, though hasn't occurred in other tests.
> True, the startup process can live for a short while co
and I still think that's bogus. It seems clear that this is going to
change much faster than plans are going to be invalidated, and if
autovacuum is doing its job, the pending list won't get long enough to
matter much anyway, right? I don't think this patch should be
touching gincostestimate at
Zdenek Kotala wrote:
>
> Bruce Momjian p??e v ?t 19. 02. 2009 v 08:08 -0500:
> > > you should use vacuum_freeze_min_age instead. On other side it
> > breaks
> > > vacuumdb backward compatibility which we did not declare, but it
> > could
> > > be fine.
> >
> > How does adding a flag break backwar
Bruce Momjian píše v čt 19. 02. 2009 v 08:08 -0500:
> > you should use vacuum_freeze_min_age instead. On other side it
> breaks
> > vacuumdb backward compatibility which we did not declare, but it
> could
> > be fine.
>
> How does adding a flag break backward compatibiity?
>
I meant that vacuum
ITAGAKI Takahiro wrote:
Here is a patch to allow 'on' and 'off' as input texts for boolean.
Duplicated boolean parsers in parse_bool() and boolin() are merged
into a new parse_bool_with_len().
Regarding your FIXME comment, I think parse_bool* should be in bool.c
and declared in builtins.h, whi
Please review the instructions here: http://wiki.postgresql.org/wiki/NLS
If you already have a file, attach it to the patch tracker, as described
at the above wiki page.
Max wrote:
Max wrote:
Hi,
I would like to help with the translation from english to romanian.
I could not contact the pe
Zdenek Kotala wrote:
> The FREEZ option is deprecated. See
>
> http://www.postgresql.org/docs/8.3/interactive/sql-vacuum.html
I mentioned PGOPTIONS as a suggestion when I posted but on one said that
was a good idea; they just wanted to know why I needed this
functionality.
> you should use vacu
Gregory Stark wrote:
> > But having said that, there isn't any real harm in fixing the OID
> > counter to match what it was. You need to run pg_resetxlog to set the
> > WAL position and XID counter anyway, and it can set the OID counter too.
>
> Yeah, if it was massive amounts of code I could see
The FREEZ option is deprecated. See
http://www.postgresql.org/docs/8.3/interactive/sql-vacuum.html
you should use vacuum_freeze_min_age instead. On other side it breaks
vacuumdb backward compatibility which we did not declare, but it could
be fine.
Zdenek
Bruce Momjian píše v út 17. 0
Jacky Leng wrote:
Tuples with an aborted xmin can be vacuumed right away. When we're
following the update chain in EvalPlanQual, it's possible that the updater
has aborted, the updated dead tuple is vacuumed away, and the slot is
reused for another unrelated tuple.
But if the updater aborted,
Hi,
I would like to help with the translation from english to romanian.
I could not contact the people in charge for the Romanian translations.
I already completed the plpgsql-ro.po but I don't know how or where to
submit it.
Latter I found out that the module is under still under development a
Max wrote:
Hi,
I would like to help with the translation from english to romanian.
I could not contact the people in charge for the Romanian translations.
I already completed the plpgsql-ro.po but I don't know how or where to
submit it.
Latter I found out that the module is under still under d
> Tuples with an aborted xmin can be vacuumed right away. When we're
> following the update chain in EvalPlanQual, it's possible that the updater
> has aborted, the updated dead tuple is vacuumed away, and the slot is
> reused for another unrelated tuple.
But if the updater aborted, how can Eva
Jacky Leng wrote:
When I read function "EvalPlanQual", I found the following code:
if (heap_fetch(relation, &SnapshotDirty, &tuple, &buffer, true, NULL))
{
/*
* If xmin isn't what we're expecting, the slot must have been
* recycled and reused for an unrelated tuple. This implies t
Hi,
When I read function "EvalPlanQual", I found the following code:
if (heap_fetch(relation, &SnapshotDirty, &tuple, &buffer, true, NULL))
{
/*
* If xmin isn't what we're expecting, the slot must have been
* recycled and reused for an unrelated tuple. This implies that
* the l
67 matches
Mail list logo
