The warn 'em in several places seems like a very good approach.
regards
Mark
Matthew T. O'Connor wrote:
There will always be people who won't read the notes, or ignore the
notes, as there will always be people doing all sorts of stupid things
that we can't protect them from. There is only so much
Just my two pence contribution:
* Allow GRANT/REVOKE permissions to be given to all schema
objects with one command
GRANT SELECT ON TABLE myschema.* TO foo
As for the style of the syntax, maybe one could consider to reuse
already available sql regexpr rather than import
Does anybody know answer for these questions?
1) Does Slony-I supports replicating large objects?
2) Is Slony-I a sync or async replication system? Since Slony-I bases
on trigger I suspect it's kind of async replication system.
--
Tatsuo Ishii
---(end of
Hi guys,
A guy on the IRC channel managed to accidentally click the wrong thing
in phpPgAdmin and managed to remove superuser privileges from his only
superuser.
We thought and though but it seems that there is no way to recover from
this situation except a re-init and reload. And what user
Tatsuo Ishii wrote:
Does anybody know answer for these questions?
1) Does Slony-I supports replicating large objects?
Slony-I does no replicate large objects.
2) Is Slony-I a sync or async replication system? Since Slony-I bases
on trigger I suspect it's kind of async replication system.
Magnus Hagander wrote:
FWIW, I think reporting a differnt version is just a *terrible* idea.
Any client side program (say, pgadmin for example) that tries to
determine what version backend it's connected to in order to know if a
feature exists or not will be confused, in many cases to the point of
For what it's worth, I like the second form better.
Mike
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Christopher
Kings-Lynne
Sent: Sunday, May 23, 2004 6:08 AM
To: PostgreSQL-development
Subject: [HACKERS] Syntax question
Here are the two
Wonder how real this is?
http://www.amrresearch.com/search/view.asp?id=17298
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
On Mon, May 24, 2004 at 09:54:20PM +0800, Christopher Kings-Lynne wrote:
in phpPgAdmin and managed to remove superuser privileges from his only
superuser.
We thought and though but it seems that there is no way to recover from
this situation except a re-init and reload. And what user is
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
A guy on the IRC channel managed to accidentally click the wrong thing
in phpPgAdmin and managed to remove superuser privileges from his only
superuser.
No sweat; we've seen this one before.
Stop postmaster and start a standalone backend.
No sweat; we've seen this one before.
Should this situation be prevented though?
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
No sweat; we've seen this one before.
Should this situation be prevented though?
I think the cure would probably be worse than the disease. To make any
serious attempt at preventing remove-the-last-superuser, we'd have to
make operations on
, 24.05.2004, 16:12, Tom Lane :
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
A guy on the IRC channel managed to accidentally click the wrong thing
in phpPgAdmin and managed to remove superuser privileges from his only
superuser.
No sweat; we've seen this one before.
Stop
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Hmmm - I agree it's difficult, but somehow I think it's something we
should do. Just imagine if some major user of postgres did it - they'd
be screaming blue murder...
Shrug. Superusers can *always* shoot themselves in the foot in Postgres.
The mistake has only come up two or three times that I can remember,
which doesn't elevate it to the category of stuff that I want to install
a lot of mechanism to prevent. Especially not mechanism that would get
in the way of reasonable uses. I think it's sufficient to have a
recovery
On Mon, 24 May 2004, Tom Lane wrote:
I think the cure would probably be worse than the disease. To make any
serious attempt at preventing remove-the-last-superuser, we'd have to
make operations on pg_shadow grab exclusive lock. For instance, you
couldn't allow two backends to DROP USER in
Isn't it just enough to prevent the user with userid 1 from losing the
superuser status. If one want to allow it one could prevent it just when
doing the ALTER USER stuff and allow it when editing pg_shadow directly.
Or maybe have some guc variable that write locks the user with id 1.
That gets
[resending...]
On Sun, 23 May 2004 11:38:51 +0800, Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
I get this since Tom's commit.
--- ./results/horology.out Sun May 23 11:39:49 2004
***
*** 1787,1796
! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years|
[resending...]
On Sat, 22 May 2004 20:28:43 -0400, Neil Conway [EMAIL PROTECTED]
wrote:
-- Why is there a blank line before the -- that indicates the
-- end of the result set?
-- separates the header line from the *start* of the result set. The
empty line is the header line, containing zero
Hi
everybody,1 EXPLAIN SELECT COUNT(*) AS c FROM articletbl
WHERE ((mydate BETWEEN '2004-04-24' AND
'2004-05-24' ))2 EXPLAIN SELECT COUNT(*) AS c FROM articletbl
WHERE ((mydate = '2004-04-24'))(I
ran VACUUM ANALYZE before running those)mydate is an indexed date
column.The
Ismail Kizir wrote:
Hi everybody,
1 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE
((mydate BETWEEN '2004-04-24' AND '2004-05-24' )
)
2 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE
((mydate = '2004-04-24')
)
(I ran VACUUM ANALYZE before running those)
mydate is an
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Hmmm - I agree it's difficult, but somehow I think it's something we
should do. Just imagine if some major user of postgres did it - they'd
be screaming blue murder...
Shrug. Superusers can *always* shoot themselves in the foot
Thanks Hans,
The optimizer does an indexed scan up to 20 days, and then, it decides to
make a sequential scan.
But i am still not sure about the efficiency of this decision.
Here is a list of number of items on a daily basis:
2002-10-20;151
2002-10-19;163
2002-10-18;175
2002-10-17;183
Ismail Kizir [EMAIL PROTECTED] writes:
Thanks Hans,
The optimizer does an indexed scan up to 20 days, and then, it decides to
make a sequential scan.
What are the results of explain analyze query for the various queries?
--
greg
---(end of
On Mon, May 24, 2004 at 11:23:09AM -0700, Joe Conway wrote:
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Hmmm - I agree it's difficult, but somehow I think it's something we
should do. Just imagine if some major user of postgres did it - they'd
be screaming blue
On Mon, May 24, 2004 at 08:27:01PM +0300, Ismail Kizir wrote:
The optimizer does an indexed scan up to 20 days, and then, it decides to
make a sequential scan.
But i am still not sure about the efficiency of this decision.
Huh, so what was the EXPLAIN ANALYZE of the query with BETWEEN?
--
I get this since Tom's commit.
--- ./results/horology.out Sun May 23 11:39:49 2004
***
*** 1787,1796
! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years
| Fri Sep 22 18:19:20 1967 PDT
[...]
--- 1787,1796
! | Sat Sep 22 18:19:20 2001 PDT | @ 34
Alvaro,
For the query :
EXPLAIN SELECT count(tarih) AS c FROM articletbl WHERE sitekodu = 12 AND
((tarih='2004-04-24' AND tarih'2004-05-24' ))
QUERY PLAN is
Aggregate (cost=41619.34..41619.34 rows=1 width=4)
- Seq Scan on articletbl (cost=0.00..41618.46 rows=353 width=4)
Ismail Kizir wrote:
Hi everybody,
1 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE
((mydate BETWEEN '2004-04-24' AND '2004-05-24' )
)
2 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE
((mydate = '2004-04-24')
)
(I ran VACUUM ANALYZE before running those)
mydate is an
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Hmmm - I agree it's difficult, but somehow I think it's something we
should do. Just imagine if some major user of postgres did it - they'd
be screaming blue murder...
Shrug. Superusers can *always* shoot themselves in the foot
Hi all,
give us the result of these queries:
SELECT COUNT(*) FROM articletbl;
268726 records, it takes 34169 ms. to compute this
SELECT COUNT(*) AS c FROM articletbl WHERE
mydate BETWEEN '2004-04-24' AND '2004-05-24';
18982 records, it takes 34249 ms. to compute this.
SELECT COUNT(*) AS
On Mon, 24 May 2004, Ismail Kizir wrote:
Hi all,
give us the result of these queries:
SELECT COUNT(*) FROM articletbl;
268726 records, it takes 34169 ms. to compute this
SELECT COUNT(*) AS c FROM articletbl WHERE
mydate BETWEEN '2004-04-24' AND '2004-05-24';
18982 records, it
Ismail Kizir wrote:
Hi all,
give us the result of these queries:
SELECT COUNT(*) FROM articletbl;
268726 records, it takes 34169 ms. to compute this
SELECT COUNT(*) AS c FROM articletbl WHERE
mydate BETWEEN '2004-04-24' AND '2004-05-24';
18982 records, it takes 34249 ms. to compute this.
Christopher Kings-Lynne wrote:
The mistake has only come up two or three times that I can remember,
which doesn't elevate it to the category of stuff that I want to install
a lot of mechanism to prevent. Especially not mechanism that would get
in the way of reasonable uses. I think it's
Magnus Hagander [EMAIL PROTECTED] writes:
I just got the failure again with make check after having configured
with a new install directory. My guess is that horology needs some
datafile from the install location.
Not only a file, but the entire directory pginstall/share/timezone,
with
IMHO we (that is Christopher, me and others maintaining easy to (mis)use
tools) should warn the users about what they're going to do.
Yes, I'm going to have to modify phpPgAdmin methinks.
Chris
---(end of broadcast)---
TIP 9: the planner will ignore
I notice that when using the extended query protocol, statement logging
appears to happen only when a Parse message is received. This is less
than ideal:
- statements can be logged that are not actually executed (i.e. a
Parse/Bind with no corresponding Execute).
- if statements are re-executed
[ BCC to hackers and advocacy.]
Ingres is to be released as open source:
http://developers.slashdot.org/article.pl?sid=04/05/25/0043219mode=nestedtid=126tid=137tid=163tid=185tid=198
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
Magnus Hagander [EMAIL PROTECTED] writes:
I get this since Tom's commit.
Ah-hah. It fails if you do make check and have not got any
installation at the configured place, *and* the configured place
isn't under someplace like /home/postgres. The reason is that
relative_path doesn't work. On my
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I get this since Tom's commit.
Ah-hah. It fails if you do make check and have not got any
installation at the configured place, *and* the configured place
isn't under someplace like /home/postgres. The reason is that
Bruce Momjian wrote:
Well, at execute time, we don't have easy access to the original prepare
statement, especially at that stage in the code. Do you see anyway to
improve that?
We have portal-sourceText which looks like it should contain the
original query.
(note that I'm talking about the V3
Oliver Jowett wrote:
I notice that when using the extended query protocol, statement logging
appears to happen only when a Parse message is received. This is less
than ideal:
- statements can be logged that are not actually executed (i.e. a
Parse/Bind with no corresponding Execute).
-
I said:
The reason this only affects timezone is that there isn't anything
else in /share that the backend needs to access. However I'm not quite
sure why get_pkglib_path seems not to be having the same confusion...
Actually, get_pkglib_path is wrong too. But the regression tests do not
Ingres is to be released as open source:
http://developers.slashdot.org/article.pl?sid=04/05/25/0043219mode=nestedtid=126tid=137tid=163tid=185tid=198
Like the article says, I wonder if these is any synergy between the
products. ie. Can we grab features from their codebase?
Chris
Bruce Momjian [EMAIL PROTECTED] writes:
Well, in the case you have an install prefix of /usr, we wouldn't want
relative installs because you would have /usr/bin and
/usr/lib/postgresql and that wouldn't be relocatable.
Why not?
ISTM that the algorithm should go something like this:
1. Take
Oliver Jowett [EMAIL PROTECTED] writes:
I notice that when using the extended query protocol, statement logging
appears to happen only when a Parse message is received. This is less
than ideal:
I agree, but I didn't have time at the end of the 7.4 development cycle
to work out what should
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
First I initdb'd without TZ set. So every time I start the server I get
LOG: could not recognize system timezone, defaulting to Etc/GMT-4
HINT: You can specify the correct timezone in postgresql.conf.
I've fixed the minor issue here,
Hi,
There are several objects in PostgreSQL that you can only create if you
are a superuser, eg. procedural languages.
If you do this, you break the dump:
1. create a superuser
2. install a language as that superuser
3. drop the superuser privs from that superuser
4. dump the database
5. attempt
Oliver Jowett [EMAIL PROTECTED] writes:
Also, unless I'm missing something, shouldn't Chile (Alvaro's timezone?)
be behind GMT (GMT-something) not ahead of it (GMT+something)?
Part of the confusion here is that the zone names in the zic database
follow POSIX rules: plus is west of Greenwich.
OK, I will work on that. With everything now centralized it should be
easier.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, in the case you have an install prefix of /usr, we wouldn't want
relative
I am almost finished Andrew's version of pg_ctl.c. Here is the current
version I am using.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Also, unless I'm missing something, shouldn't Chile (Alvaro's timezone?)
be behind GMT (GMT-something) not ahead of it (GMT+something)?
Part of the confusion here is that the zone names in the zic database
follow POSIX rules: plus is west
Oliver Jowett [EMAIL PROTECTED] writes:
What confused me is that the times in the log don't follow the
SQL-and-everything-else convention:
LOG: database system was shut down at 2004-05-25 15:15:44 GMT-12
For comparison, 7.4.1 on the same system says:
LOG: database system was shut
53 matches
Mail list logo
