> But did you clear your cache? :P
Freud might say it takes a lifetime to clear one's cache
Luckily, in therapy you don't have to wait for those darn Postgres
developers ;)
>
> Joshua D. Drake
>
>
> >
> > ---(end of broadcast)---
> > TIP 1: if
Mark Mielke wrote:
Nobody is ignoring users or needs or wants. It is a question of
priority. My priorities may not match yours may not match Tom's or one
of the other core contributors. Valuable features are being added to
FYI, the terminology core contributors is confusing. There is not rea
Andrew Chernow wrote:
I think, though, that telling them that they must work on a certain
feature, because that's what the users are asking for, is the wrong
approach. Not to say that is exactly what you are requesting, but I
suggest that is where you are leading.
The more communication between
Webb Sprague wrote:
I realize that some very important navel-gazing (^H^H^H "group
process") is happening, but let us remember where bona-fide feature
requests should go:
http://www.postgresql.org/docs/faqs.TODO.html
So far, I don't see any mention of materialized views on this page,
and I did
I realize that some very important navel-gazing (^H^H^H "group
process") is happening, but let us remember where bona-fide feature
requests should go:
http://www.postgresql.org/docs/faqs.TODO.html
So far, I don't see any mention of materialized views on this page,
and I did refresh ... :)
--
On 1/8/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> The other issue that ought to be on the TODO radar is that we've only
> plugged the hole for the very limited case of maintenance operations that
> are likely to be executed by superusers. If user A modifies user B's
> table (via INSERT/UPDATE/DELE
I think, though, that telling them that they must work on a
certain feature, because that's what the users are asking for, is the
wrong approach. Not to say that is exactly what you are requesting, but
I suggest that is where you are leading.
Cheers,
mark
The more communication between user
Sean Utt wrote:
My point is simply this: The lack of a clear formal process for
feature requests leads to this degradation in the conversation.
Without a formalized structure, the conversation devolves rapidly into
an argument over semantics and word choice. It is not my contention
that the "c
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Whether the string is "AUTO " or "autovacuum: " seems rather the same
> > thing to me :-) I agree with the general idea. I think "autovacuum: "
> > makes it clearer that it's not part of the actual command syntax, so
> > maybe I'
"Sean Utt" <[EMAIL PROTECTED]> writes:
> My point is simply this: The lack of a clear formal process for feature
> requests leads to this degradation in the conversation.
Two comments:
1) The existing informal process has served us very well for more than
ten years now. I'm disinclined to consi
Sean Utt wrote:
My point is simply this: The lack of a clear formal process for
feature requests leads to this degradation in the conversation.
Without a formalized structure, the conversation devolves rapidly into
an argument over semantics and word choice. It is not my contention
that the
I wrote:
> I think it's okay for CREATE INDEX CONCURRENTLY to use bulk-read access
> strategy (that is, seqscan using a limited number of buffers), but it
> has to be able to force the scan to start at page zero.
I've committed a patch to do that. Please test CVS HEAD and see if you
still see pro
My point is simply this: The lack of a clear formal process for feature
requests leads to this degradation in the conversation. Without a formalized
structure, the conversation devolves rapidly into an argument over semantics
and word choice. It is not my contention that the "core" developers ne
Joshua D. Drake wrote:
Andrew Dunstan wrote:
I'm not going to bother trying, because you just moved the goalposts
(managing in a production environment vs using). And why should the
number of DBAs matter one whit? Why should they matter more than, say
application developers, when it come
Andrew Dunstan wrote:
I'm not going to bother trying, because you just moved the goalposts
(managing in a production environment vs using). And why should the
number of DBAs matter one whit? Why should they matter more than, say
application developers, when it comes to language level feat
Joshua D. Drake wrote:
Andrew Dunstan wrote:
Sean Utt wrote:
As Joshua Drake has pointed out before, most of the core people
working on PostgreSQL don't actually use it for anything themselves.
I will expand a little on that and say that this means that while
they are extremely good at
Andrew Dunstan wrote:
Sean Utt wrote:
As Joshua Drake has pointed out before, most of the core people
working on PostgreSQL don't actually use it for anything themselves. I
will expand a little on that and say that this means that while they
are extremely good at what they do, they really
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Whether the string is "AUTO " or "autovacuum: " seems rather the same
> thing to me :-) I agree with the general idea. I think "autovacuum: "
> makes it clearer that it's not part of the actual command syntax, so
> maybe I'll put half a vote for that o
On Jan 14, 2008 1:31 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Whether the string is "AUTO " or "autovacuum: " seems rather the same
> thing to me :-) I agree with the general idea.
Yeah, forgot to mention I find it a very good idea.
--
Guillaume
---(end of broadca
I wrote;
> Hannes Dorbath <[EMAIL PROTECTED]> writes:
>> I have the bad feeling that I need to correct this into "It happens when
>> autovacuum is active on the table".
> Ah-hah, I realize how to explain that too, now.
Hmm, no, scratch that: neither VACUUM nor ANALYZE use a standard
heapscan, so
Guillaume Smet escribió:
> On Jan 13, 2008 10:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I think this would be a helpful change, but some might find it
> > confusing. Thoughts?
>
> If possible, something like:
> autovacuum: VACUUM ANALYZE foo.bar
> could be less confusing.
> It's weird to jus
Sean Utt wrote:
As Joshua Drake has pointed out before, most of the core people
working on PostgreSQL don't actually use it for anything themselves. I
will expand a little on that and say that this means that while they
are extremely good at what they do, they really don't have a clue what
Hannes Dorbath <[EMAIL PROTECTED]> writes:
> I have the bad feeling that I need to correct this into "It happens when
> autovacuum is active on the table".
Ah-hah, I realize how to explain that too, now. If you start the CREATE
INDEX CONCURRENTLY while an autovacuum is in progress on that table,
"Webb Sprague" <[EMAIL PROTECTED]> writes:
> May I propose the following: (1) can we put materialized views on the
> TODO, perhaps as a library or as core, still subject to a lot of
> design work and with no particular deadline?
Actually, I had thought they *were* on the TODO list, because certai
Oooh ... I can't be sure that this is what's biting you, but I
definitely see a bug that seems to match the symptoms. As the comments
in index.c point out, CREATE INDEX CONCURRENTLY works like this:
* validate_index() works by first gathering all the TIDs currently in the
* index, using a bulkd
Guillaume Smet wrote:
On Jan 13, 2008 11:27 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
AUTOVACUUM ANALYZE foo.bar more clear.
Doesn't autovacuum also trigger ANALYZE only?
That's why I proposed an 'autovacuum:' prefix.
Oh so:
autovacuum: vacuum
autovacuum: analyze
autovacuum: vacuum an
On Jan 13, 2008 11:27 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> AUTOVACUUM ANALYZE foo.bar more clear.
Doesn't autovacuum also trigger ANALYZE only?
That's why I proposed an 'autovacuum:' prefix.
--
Guillaume
---(end of broadcast)---
TIP 5:
Tom Lane wrote:
I was just noticing that $SUBJECT is hard --- the entry in current_query
looks exactly like a manual vacuum command, and there's not anything in
the other fields that looks different either.
Since autovacuum.c is making up its pgstat_report_activity string
anyway, it would be eas
Hannes Dorbath wrote:
Currently all I can say is: It happens the first time after I bulk load data
into that table.
I have the bad feeling that I need to correct this into "It happens when
autovacuum is active on the table".
Is it by any chance possible that CREATE INDEX CONCURRENTLY might
On Jan 13, 2008 10:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I think this would be a helpful change, but some might find it
> confusing. Thoughts?
If possible, something like:
autovacuum: VACUUM ANALYZE foo.bar
could be less confusing.
It's weird to just add AUTO in front of the query.
--
Gui
I was just noticing that $SUBJECT is hard --- the entry in current_query
looks exactly like a manual vacuum command, and there's not anything in
the other fields that looks different either.
Since autovacuum.c is making up its pgstat_report_activity string
anyway, it would be easy to make the stri
Tom Lane wrote:
Hannes Dorbath <[EMAIL PROTECTED]> writes:
This is a general thing I'd like to ask. If the creation of an index
fails, why is it nevertheless there?
It's a rather ugly consequence of the fact that CREATE INDEX
CONCURRENTLY requires more than one transaction. If the later ones
Just my two cents on this (rapidly degenerating) thread.
On 1/13/08, Sean Utt <[EMAIL PROTECTED]> wrote:
> Good to see things haven't changed, and requests for
> features and improvements on the pgsql-hackers list can still degenerate
> rapidly into a discussion about how to request features and i
Hannes Dorbath <[EMAIL PROTECTED]> writes:
> This is a general thing I'd like to ask. If the creation of an index
> fails, why is it nevertheless there?
It's a rather ugly consequence of the fact that CREATE INDEX
CONCURRENTLY requires more than one transaction. If the later ones
fail, the inval
Sean Utt wrote:
Good to see things haven't changed, and requests for
features and improvements on the pgsql-hackers list can still degenerate
rapidly into a discussion about how to request features and improvements.
As Joshua Drake has pointed out before, most of the core people working
on Po
Good to see things haven't changed, and requests for
features and improvements on the pgsql-hackers list can still degenerate
rapidly into a discussion about how to request features and improvements.
As Joshua Drake has pointed out before, most of the core people working on
PostgreSQL don't ac
Hannes Dorbath wrote:
ERROR: relation "ts_test_tsv" already exists
test=# drop INDEX ts_test_tsv ;
DROP INDEX
This is a general thing I'd like to ask. If the creation of an index
fails, why is it nevertheless there? No matter if deadlock or my GIN
error, why isn't the whole operation "rolled
Guillaume Smet wrote:
On Jan 13, 2008 7:50 PM, Hannes Dorbath <[EMAIL PROTECTED]> wrote:
I started from scratch to put up a test case. I cannot trigger "ERROR:
item pointer (0,1) already exists" again as the deadlock issue reported
by Gregory Stark hit me every time. Is this fixed in RC1? Can I
Hannes Dorbath wrote:
Guillaume Smet wrote:
On Jan 13, 2008 7:50 PM, Hannes Dorbath <[EMAIL PROTECTED]>
wrote:
I started from scratch to put up a test case. I cannot trigger "ERROR:
item pointer (0,1) already exists" again as the deadlock issue reported
by Gregory Stark hit me every time. Is th
On Jan 13, 2008 7:50 PM, Hannes Dorbath <[EMAIL PROTECTED]> wrote:
> I started from scratch to put up a test case. I cannot trigger "ERROR:
> item pointer (0,1) already exists" again as the deadlock issue reported
> by Gregory Stark hit me every time. Is this fixed in RC1? Can I retry
> with that?
Gregory Stark wrote:
"Gregory Stark" <[EMAIL PROTECTED]> writes:
On the other hand we can't just ignore all vacuums because someone could issue
a manual vacuum inside a transaction (I think?).
Doh, ignore this. sigh.
I started from scratch to put up a test case. I cannot trigger "ERROR:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
We don't dump non-default comments on other system objects either,
so I don't think it's out of line to suppress the one on schema public.
The distinction then is if "public" is actually a system object.
Yeah, it's
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We don't dump non-default comments on other system objects either,
>> so I don't think it's out of line to suppress the one on schema public.
> The distinction then is if "public" is actually a system object.
Yeah, it's a borderline
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Could we dump it when it's non-default only? That way the people that
*have* set a custom comment on it will still get it restored, just a
failure in this case. The majority of people who *haven't* set a comment
will not have the prob
"Warren Turkal" <[EMAIL PROTECTED]> writes:
> I have a question. Are the low level representations of Timestamp and
> TimestampTZ the same?
They're the same but the interpretations are different, which is why
I think it's useful to have two typedefs as a way of documenting what
any given value is
Kris Jurka <[EMAIL PROTECTED]> writes:
> The easiest thing to do would be to drop the default comment. Then only
> custom comments would be dumped at all (at least for 8.3+ dbs). It's not
> like "Standard public schema" is particularly enlightening.
Hmm, that's an interesting idea; although I
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Could we dump it when it's non-default only? That way the people that
> *have* set a custom comment on it will still get it restored, just a
> failure in this case. The majority of people who *haven't* set a comment
> will not have the problem at all
On Jan 12, 2008 4:19 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-01-12 at 13:27 +0100, Jean-Michel Pouré wrote:
>
> > Please pick-up this important issue for developpers. There is no need to
> > concentrate on complex issues, when handling materialized views could
> > boost somme web
On Sun, 13 Jan 2008, Magnus Hagander wrote:
Could we dump it when it's non-default only? That way the people that *have*
set a custom comment on it will still get it restored, just a failure in this
case. The majority of people who *haven't* set a comment will not have the
problem at all.
James Mansion wrote:
> If your view of the community is that it should be insular and closed to
> those who can't or won't be developers, then fine. But taking that
> attitude will pretty much guarantee that your system will never amount to
> more than a hill of beans.
Keep in mind that Mark
FYI: I don't like being attacked for stating the truth, nor distracting
the mailing list with these emotional discussions. However, there are
things that need to be clarified. Feel free to kill the thread in your
mail browser.
James Mansion wrote:
Mark Mielke wrote:
Joshua D. Drake wrote:
U
Mark Mielke wrote:
Joshua D. Drake wrote:
Unless you are going to *pay* for it - you do realize that the best
way to get it implemented, would be to open up the source code, and
give it a try yourself?
Because users possibly want to do that - use it? Some of us have better
things to do
Tom Lane wrote:
There was some discussion today about restoring pg_dump output as a
non-superuser:
http://archives.postgresql.org/pgsql-admin/2008-01/msg00128.php
In 8.3 we have eliminated one of the major roadblocks to doing that,
which is that we now allow non-superuser database owners to crea
On Fri, Jan 11, 2008 at 10:41:17AM -0500, Tom Lane wrote:
> Perhaps there's some discrepancy between the ecpg and backend lexers
> as to where these are called?
You're right. There is no way to (un)select standard conforming strings
which makes up for the difference. Thanks for pointing me into th
> In fairness to Jean-Michel, he has spent hundreds of hours in the past
> doing just that and far more for the pgAdmin users in the community -
> I'm sure we can excuse him for asking for what many do think would be
> a useful feature in the hopes that someone listening might just decide
> to pick
-my gmail account
On Jan 13, 2008 12:13 AM, Warren Turkal <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 5:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Hmm, PackedTime seems like a fairly random name for the type --- there's
> > not anything particularly "packed" about it IMO.
> >
> > I'm a bit in
On Jan 12, 2008 5:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Hmm, PackedTime seems like a fairly random name for the type --- there's
> not anything particularly "packed" about it IMO.
>
> I'm a bit inclined to suggest just using the Timestamp typedef.
> I guess though that there's some risk of c
57 matches
Mail list logo
