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
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
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 ba
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
> > re
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
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
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,
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 shoul
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. Ta
Ingres is to be released as open source:
http://developers.slashdot.org/article.pl?sid=04/05/25/0043219&mode=nested&tid=126&tid=137&tid=163&tid=185&tid=198
Like the article says, I wonder if these is any synergy between the
products. ie. Can we grab features from their codebase?
Chris
-
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
ex
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).
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 p
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
"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.
[ BCC to hackers and advocacy.]
Ingres is to be released as open source:
http://developers.slashdot.org/article.pl?sid=04/05/25/0043219&mode=nested&tid=126&tid=137&tid=163&tid=185&tid=198
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
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
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
"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 "/share/timezone",
> with
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 sufficien
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.
SELEC
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 re
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(*)
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 foo
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 in
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)
Fil
>>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 2
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?
--
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 screamin
"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 " for the various queries?
--
greg
---(end of broadcast)-
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
2002-10-16;
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
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 in
ï
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.
[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 z
[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
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
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 i
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 procedure.
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 Postg
Ð ÐÐÐ, 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
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 o
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:
> 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
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
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
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
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
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.
Slony-I
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 is
> > > There will always be people who won't read the notes, or
> ignore the
> > > notes,
> >
> > Does anyone want to contemplate hacking things so that the Windows
> > port reports a different version number? "0.1" might give
> people the
> > right sort of impression about what we think of th
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 broadcast)
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 muc
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 impo
54 matches
Mail list logo
