Suppose I have a database with a table in it. I try to dump that
database. The user I dump as is not the owner of that table nor does it
have the SELECT permission on that table.
Why can't I do a schema-only dump of that table? I find that I need
SELECT permission on the table, even though
Apologies if this is old news, but pg_autovacuum in 8.0.x has the bad habit
of SEGVing and exiting when a table gets dropped out from under it. This
creates problems if you rely on pg_autovacuum for the bulk of your vacuuming
as it forgets it's statistics when it is restarted and so will skip
On Tue, Oct 18, 2005 at 10:07:26PM -0500, Larry Rosenman wrote:
...or attach with a debugger like gdb.
d'oh. I go stupid occasionally :)
If someone wants me to, I can try that.
Yes, actually. See, its dying in the seg test already with:
-- Open intervals
SELECT '0..'::seg AS seg;
!
Hi All,
At system crash or poweroff the autovacuum statistics will be lost,
because this statistics only stored in RAM and saved/restored at
service shutdown/startup.
I think it should be saved periodically and not to be deleted after
crash.
On 2005-10-19, Kevin Brown [EMAIL PROTECTED] wrote:
Making assumptions about what the pager will do upon receipt of SIGINT
is folly as well.
Setting up SIGINT to be ignored may be the right answer (I don't
believe it is -- see below), but if so then it needs to be done
properly. If it gets
Martijn van Oosterhout wrote:
On Tue, Oct 18, 2005 at 10:07:26PM -0500, Larry Rosenman wrote:
...or attach with a debugger like gdb.
d'oh. I go stupid occasionally :)
If someone wants me to, I can try that.
Yes, actually. See, its dying in the seg test already with:
-- Open
daveg wrote:
Apologies if this is old news, but pg_autovacuum in 8.0.x has the bad habit
of SEGVing and exiting when a table gets dropped out from under it. This
creates problems if you rely on pg_autovacuum for the bulk of your vacuuming
as it forgets it's statistics when it is restarted and so
If we stored the actual queries and the EXPLAIN ANALYZE results (when
generated) in the database, what would be the purpose of the node_name,
db_object, and condition_detail columns? They don't seem like they
would be useful for statistical analysis, and it seems like the
information would be
Kevin,
If we stored the actual queries and the EXPLAIN ANALYZE results (when
generated) in the database, what would be the purpose of the node_name,
db_object, and condition_detail columns? They don't seem like they
would be useful for statistical analysis, and it seems like the
information
Hi,
On Tue, 18 Oct 2005, Tony Caduto wrote:
I installed 8.04 via RPM on Centos 4.2 which is the same as RedHat 4.2 and
while booting the init script reports that the daemon [FAILED], but after I
logon it shows the postmaster running and I am able to connect from any
client remotely.
I made
Summary of schema I'm considering. Comments welcome.
When it gets downt to the detail, it may make sense to combine
or split some of these. For example, runtime_options should
probably not have a column for each currently known option,
but a child table which maps to all non-default option
Kevin,
When it gets downt to the detail, it may make sense to combine
or split some of these. For example, runtime_options should
probably not have a column for each currently known option,
but a child table which maps to all non-default option values.
I'm a little cautious about storing
I'm not interested in storing less information. I'm trying to make sure
that all redundant information is justified. Since I plan to store the
actual query text and the full EXPLAIN ANALYZE output, every
column I pull out and put in another table is redundant data. The
questions are, why do we
On Tuesday 18 October 2005 18:05, Kevin Grittner wrote:
Regarding the idea of a site where results could be posted
and loaded into a database which would be available for
public access -- I agree that would be great; however, my
client is not willing to take that on. If anyone wants to
Maybe we could associate a set of defaults to runtime_environment,
and you would associate any overrides with the runtime_options.
Does this address both your concerns?
Josh Berkus josh@agliodbs.com
Kevin,
When it gets downt to the detail, it may make sense to combine
or split some of
Robert Treat wrote:
On Tuesday 18 October 2005 18:05, Kevin Grittner wrote:
Regarding the idea of a site where results could be posted
and loaded into a database which would be available for
public access -- I agree that would be great; however, my
client is not willing to take that on.
I'm CC'ng this over to -hackers ... Tom? Comments?
On Wed, 19 Oct 2005, Dann Corbit wrote:
Yes, clearly that is the wrong result according to the SQL standard.
Here is a SQL*Server query:
select 1 where 'a' = 'a ' AND 'a' = 'a ' AND 'a ' = 'a '
It returns (correctly): 1
On Wed, 19 Oct 2005, Dann Corbit wrote:
-Original Message-
From: Stephan Szabo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 19, 2005 12:39 PM
To: Dann Corbit
Cc: Marc G. Fournier; [EMAIL PROTECTED]; pgsql-
[EMAIL PROTECTED]
Subject: Re: [pgsql-advocacy] [GENERAL] Oracle buys
Given this part of that same rule applied to the strings:
b) If the length in characters of X is not equal to the length in
characters of Y, then the shorter string is effectively replaced, for
the purposes of comparison, with a copy of itself that has been extended
to the length of the longer
Kevin,
This would require capture of information beyond what I was thinking
about in terms of schema. Do you think we need to capture just index
type, or something more? Do you propose that we capture the pg_*
metadata related to every object referenced in the plan, every object
related to
Am Mittwoch, den 19.10.2005, 16:29 -0300 schrieb Marc G. Fournier:
I'm CC'ng this over to -hackers ... Tom? Comments?
On Wed, 19 Oct 2005, Dann Corbit wrote:
Yes, clearly that is the wrong result according to the SQL standard.
Here is a SQL*Server query:
select 1 where 'a' = 'a '
Try this query in Oracle, SQL*Server, DB/2, Informix, etc.:
connxdatasync=# select 1 where cast('a' as varchar(30)) = cast('a ' as
varchar(30));
?column?
--
(0 rows)
I see how you can interpret the SQL Standard to make the above response
a correct one. But is it the response that you
Guy Rouillier [EMAIL PROTECTED] writes:
Tino Wildenhain wrote:
experiment=# SELECT 'a '::char = 'a '::char;
?column?
--
t
This does't show anything useful, because the ::char casting simply
takes the first char of any string:
select 'abc'::char = 'axy'::char
-Original Message-
From: Terry Fielder [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 19, 2005 2:05 PM
To: Dann Corbit
Cc: Tino Wildenhain; Marc G. Fournier; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org; pgsql-general@postgresql.org
Subject: Re: 'a' == 'a ' (Was: RE:
On Wed, 19 Oct 2005, Dann Corbit wrote:
-Original Message-
From: Terry Fielder [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 19, 2005 2:05 PM
To: Dann Corbit
Cc: Tino Wildenhain; Marc G. Fournier; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org;
On Wed, Oct 19, 2005 at 02:05:20PM -0700, Dann Corbit wrote:
When the compared datatypes are VARCHAR: YES
What is the value of doing that?
I can see plenty of harm and absolutely no return. We are talking about
blank padding before comparison. Do you really want 'Danniel '
considered
-Original Message-
From: Stephan Szabo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 19, 2005 2:34 PM
To: Dann Corbit
Cc: Terry Fielder; Tino Wildenhain; Marc G. Fournier;
[EMAIL PROTECTED]; pgsql-hackers@postgresql.org; pgsql-
[EMAIL PROTECTED]
Subject: Re: [HACKERS] 'a' ==
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 19, 2005 2:46 PM
To: Dann Corbit
Cc: Terry Fielder; Tino Wildenhain; Marc G. Fournier;
[EMAIL PROTECTED]; pgsql-hackers@postgresql.org; pgsql-
[EMAIL PROTECTED]
Subject: Re: 'a' == 'a
Dann,
I think that whatever is done ought to be whatever the standard says.
If I misinterpret the standard and PostgreSQL is doing it right, then
that is fine. It is just that PostgreSQL is very counter-intuitive
compared to other database systems that I have used in this one
particular
If there is a significant performance benefit to not expanding text columns in
comparison operations, then it seems it should be OK.
I probably read the standard wrong, but it seems to me that varchar, char, and
bpchar columns should all behave the same (e.g. if you do not expand with
blank or
Hello,
Some of you may have noted the new project I am playing with the
PostgreSQL Source browser.
It is a Subversion-Trac interface to the PostgreSQL CVS repository. The
entire repository
is represented. It is currently updated daily but I am hoping to get
this down to hourly in
the near
Josh Berkus wrote:
Dann,
I think that whatever is done ought to be whatever the standard says.
If I misinterpret the standard and PostgreSQL is doing it right, then
that is fine. It is just that PostgreSQL is very counter-intuitive
compared to other database systems that I have used in
Lyubomir Rusanov wrote:
Hi,br
I am also interested in helping building Bulgarian translation for
PostgreSQL. br
I think that we will not have enough time for 8.1 but maybe for 8.2.br
The best you could do is submit your incremental improvements for 8.1,
so there is at least _some_
Chris Travers [EMAIL PROTECTED] writes:
If I understand the spec correctly, it seems to indicate that this is
specific to the locale/character set.
The spec associates padding behavior with collations, which per spec are
separate from the datatypes --- that is, you should be able to able to
34 matches
Mail list logo
