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 confusion
-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 inclined to
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 it
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 the
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
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
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:
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
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.
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 apps. by
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.
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 fear
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
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
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 case,
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 a
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:
item
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?
No,
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 this
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:
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
sarcasmGood to see/sarcasm 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
Sean Utt wrote:
sarcasmGood to see/sarcasm 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
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 invalid
Just my two cents on this (rapidly degenerating) thread.
On 1/13/08, Sean Utt [EMAIL PROTECTED] wrote:
sarcasmGood to see/sarcasm 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
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
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
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.
--
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
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
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:
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
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
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 certainly
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, the
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
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 just add AUTO
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 they
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
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 option.
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
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:
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
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
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
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
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
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 consider
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'll put half a
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 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
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/DELETE),
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 ... :)
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
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
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
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
57 matches
Mail list logo
