Hello all,
Below is an email thread regarding a possible bug in PostgreSQL on
Windows 2003. Any help or advice anyone can give on this would be much
appreciated.
All the best,
James Hughes
--- EMAIL THREAD FOLLOWS ---
[EMAIL PROTECTED] wrote:
Hi Bruce,
We are now seeing this issue on three
No-one has a comment on this?
Christopher Kings-Lynne wrote:
I just tried using ipcclean in 8.1.3. It doesn't work when I su to the
pgsql user. This part of the script:
if [ $USER = 'root' -o $LOGNAME = 'root' ]
Always fails because even tho $USER is set to 'pgsql' when su'ed,
$LOGNAME is
Am Dienstag, 28. Februar 2006 07:42 schrieb Christopher Kings-Lynne:
I just tried using ipcclean in 8.1.3. It doesn't work when I su to the
pgsql user. This part of the script:
if [ $USER = 'root' -o $LOGNAME = 'root' ]
Always fails because even tho $USER is set to 'pgsql' when su'ed,
# [EMAIL PROTECTED] / 2006-03-01 12:49:13 +0100:
Am Dienstag, 28. Februar 2006 07:42 schrieb Christopher Kings-Lynne:
I just tried using ipcclean in 8.1.3. It doesn't work when I su to the
pgsql user. This part of the script:
if [ $USER = 'root' -o $LOGNAME = 'root' ]
Always fails
1. please show the EXACT initdb command line used.
2. Which Windows user was actually running initdb?
cheers
andrew
Hello all,
Below is an email thread regarding a possible bug in PostgreSQL on
Windows 2003. Any help or advice anyone can give on this would be much
appreciated.
All the
[EMAIL PROTECTED] (Mark Kirkwood) wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
/usr/local/pg7.4.1 /vol03/pg74
Hi,
1. The command line passed is -D c:\data --user=McAfeePostgresUser
2. McAfeePostgresUser which is a local machine user with limited
privileges. Though this problem occurs with any user account you create
with non-administrator privileges.
Thanks
James
-Original Message-
From:
I wonder if there could be a potential problem with using this approach
-
checking on $USER == root.
Although it is a common practice, I think a superuser does not have to
be root.
If I'm right here, a better technique could be executing `id`.
Mike
-Original Message-
From: [EMAIL
[EMAIL PROTECTED] writes:
Below is an email thread regarding a possible bug in PostgreSQL on
Windows 2003. Any help or advice anyone can give on this would be much
appreciated.
Access is denied. is not a string that appears anywhere in the
Postgres source code. My bet is some overenthusiastic
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
No-one has a comment on this?
ipcclean has never been much more than beta-quality software; it doesn't
pretend to be very portable.
Having said that, I think the anti-root check is bogus. It was probably
added in a fit of let's make sure nobody
On Tue, 2006-02-21 at 11:45 +1300, Mark Kirkwood wrote:
Simon Riggs wrote:
A new parameter that allows the administrator to place sensible limits
on the size of queries executed.
This is useful for ad-hoc SQL access
- when a very large table cannot realistically be sorted etc, so
Am Montag, 27. Februar 2006 19:42 schrieb Tom Lane:
The free-space map is not the hard part of the problem. You still have
to VACUUM --- that is, wait until the dead tuple is not only committed
dead but is certainly dead to all onlooker transactions, and then remove
its index entries as well
(private email says leaving off --user=foo doesn't fix it ;-( )
Since you have apparently compiled your own, could you please try with
the latest stable initdb.c code for your release? That is version
1.99.2.2 for release 8.1 or 1.73.4.3 for release 8.0. They are
downloadable here:
Michael Fuhr [EMAIL PROTECTED] writes:
On Wed, Mar 01, 2006 at 11:03:12AM -0500, Tom Lane wrote:
Are you sure that's where it's failing? The fragment you showed looks
fine as far as it goes. The most likely bet is you forgot to wrap it in
a transaction (BEGIN/COMMIT commands), but that would
On Tue, Feb 28, 2006 at 3:02 pm, in message
[EMAIL PROTECTED], Jim C. Nasby
[EMAIL PROTECTED]
wrote:
Maybe it's just the way my twisted mind thinks, but I generally
prefer
using a JOIN when possible...
Definitely. But sometimes you don't want one row from a table for each
qualifying row
Peter Eisentraut [EMAIL PROTECTED] writes:
I'm not sure if I made myself clear. The idea is that you fill the
free-space
map early with opportunitistic entries in the hope that most updates and
deletes go through soon. That is, these entries will be invalid for a
short time but
On Tue, Feb 28, 2006 at 7:22 am, in message
[EMAIL PROTECTED], Simon Riggs
[EMAIL PROTECTED] wrote:
OTOH a few hackers discussed this recently and found that nobody
used
serializable transactions (ST) except during pg_dump.
I've not been able to keep up with all messages on these lists,
I'm trying to plan out a few postgresql related projects and could use some
intuition on when folks think the feature freeze for 8.2 is going to occur. I
thought it was going to be in Nov 06, but after talking to a couple of
people, I've also heard that Aug 06 and Feb 07 seem to be
On Monday 27 February 2006 19:59, Josh Berkus wrote:
My frustration level often kills any desire to contribute to open
source. Sometimes, I think that open source is doomed. The various
projects I track and use are very frustrating, they remind me of
dysfunctional engineering departments
On Monday 27 February 2006 21:09, Bruce Momjian wrote:
One question I have is how this feature would be an improvement over
just pointing pg_ctl at a postgresql.conf configuration file. That
config file has the ability to specify most if not all server
parameters.
The big problem is that
Simon Riggs [EMAIL PROTECTED] writes:
A new parameter that allows the administrator to place sensible limits
on the size of queries executed.
As I said when the idea was floated originally, I don't think this is a
very good idea at all. The planner's estimates are sufficiently often
wrong
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I'm not sure if I made myself clear. The idea is that you fill the
free-space
map early with opportunitistic entries in the hope that most updates and
deletes go through soon. That is, these entries will be invalid for a
On Wed, 2006-03-01 at 10:22 -0600, Kevin Grittner wrote:
On Tue, Feb 28, 2006 at 7:22 am, in message
[EMAIL PROTECTED], Simon Riggs
[EMAIL PROTECTED] wrote:
OTOH a few hackers discussed this recently and found that nobody
used
serializable transactions (ST) except during pg_dump.
Tom Lane wrote:
Milen A. Radev [EMAIL PROTECTED] writes:
Milorad Poluga напи�а:
SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15 days'::interval
?column?
---
3 mons -14 days
Why not '2 mons 16 days' ?
Please read the last paragraph in section
Lamar Owen wrote:
On Monday 27 February 2006 21:09, Bruce Momjian wrote:
One question I have is how this feature would be an improvement over
just pointing pg_ctl at a postgresql.conf configuration file. That
config file has the ability to specify most if not all server
parameters.
Tom Lane wrote:
How does an optimistic FSM entry avoid the need to run vacuum?
It ensures that all freed tuples are already in the FSM.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 3: Have you checked
On Wed, 2006-03-01 at 11:47 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
A new parameter that allows the administrator to place sensible limits
on the size of queries executed.
As I said when the idea was floated originally, I don't think this is a
very good idea at all.
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
How does an optimistic FSM entry avoid the need to run vacuum?
It ensures that all freed tuples are already in the FSM.
That has nothing to do with it, because the space isn't actually free
for re-use until vacuum deletes the tuple.
I can see this as useful for newbies who don't want to accidentally
overload the system.
---
Simon Riggs wrote:
On Wed, 2006-03-01 at 11:47 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
A new parameter
Robert Treat wrote:
I'm trying to plan out a few postgresql related projects and could use some
intuition on when folks think the feature freeze for 8.2 is going to occur. I
thought it was going to be in Nov 06, but after talking to a couple of
people, I've also heard that Aug 06 and Feb 07
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
How does an optimistic FSM entry avoid the need to run vacuum?
It ensures that all freed tuples are already in the FSM.
That has nothing to do with it, because the space isn't actually free
for re-use until
Mark Dilger wrote:
Tom Lane wrote:
Milen A. Radev [EMAIL PROTECTED] writes:
Milorad Poluga :
SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15
days'::interval
?column?
---
3 mons -14 days
Why not '2 mons 16 days' ?
Please
Mark Dilger wrote:
Tom Lane wrote:
Milen A. Radev [EMAIL PROTECTED] writes:
Milorad Poluga напи�а:
SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15
days'::interval
?column?--- 3 mons -14 days
Why not '2 mons 16 days' ?
Please read the last
On Wed, Mar 01, 2006 at 12:59:29PM -0500, Bruce Momjian wrote:
Good question. Should we restrict days to 0 - 30 or -30 - 30? The
current system does the later:
test= select justify_days('-45 days');
justify_days
--
-1 mons -15 days
(1
PostgreSQL Anniversary Summit
=
Call for Contributions
--
The PostgreSQL Anniversary Summit will take place on July 8 and 9, 2006, in
Toronto, Canada. We are planning for a gathering of about 50 hackers,
contributors, and other friends of the
Hello Jonah,
No we are not caching the sequence
In thetransactionfor the first time we
use next val then on we use curretn val.
Regards,
Suvarna
- Original Message -
From:
Jonah H.
Harris
To: Suvarna
Cc: pgsql-hackers@postgresql.org
Sent: Tuesday, February
Hello Tom,
thankyou for the reply but,
actually the number which are missing are in the range of 20-30 and at the
max only 3 transactions are going on at any given point in time.
So if 3 numbers are missing then it was understood the missing numbers are
very large.
Regards,
suvarna
-
Someone want to remove/suspend Antoine Bajolet [EMAIL PROTECTED] from the
lists? He's sending these emails to the author of every list email (not sure if
he's on more than just -perform).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Antoine
Bajolet
Bruce,
I haven't had much time to finish up on the WITH recursive/hierarchical
query stuff yet, but was wondering when you see it having to be
completed if freeze is in August? Would May 1st be too late?
On 3/1/06, Bruce Momjian pgman@candle.pha.pa.us wrote:
Robert Treat wrote: I'm trying to plan
Gone
On Wed, 1 Mar 2006, Jim Nasby wrote:
Someone want to remove/suspend Antoine Bajolet [EMAIL PROTECTED] from the
lists? He's sending these emails to the author of every list email (not sure if he's on more
than just -perform).
-Original Message-
From: [EMAIL PROTECTED]
Jonah H. Harris wrote:
Bruce,
I haven't had much time to finish up on the WITH
recursive/hierarchical query stuff yet, but was wondering when you see
it having to be completed if freeze is in August? Would May 1st be
too late?
Doesn't feature freeze mean that's when you have to have
Jonah H. Harris wrote:
Bruce,
I haven't had much time to finish up on the WITH recursive/hierarchical
query stuff yet, but was wondering when you see it having to be completed if
freeze is in August? Would May 1st be too late?
Let us know when you start working on it and we will see it
On Wed, Mar 01, 2006 at 10:17:04AM +0530, Suvarna wrote:
actually the number which are missing are in the range of 20-30 and at the
max only 3 transactions are going on at any given point in time.
So if 3 numbers are missing then it was understood the missing numbers are
very large.
The
Mark Dilger wrote:
select justify_hours('-73 hours'::interval);
justify_hours
---
-4 days +23:00:00
select justify_days('-62 days'::interval);
justify_days
--
-3 mons +28 days
I find the last two results somewhat
Stephan Szabo wrote:
justify_days doesn't currently do anything with this result --- it
thinks its charter is only to reduce day components that are = 30 days.
However, I think a good case could be made that it should normalize
negative days too; that is, the invariant on its result should
On Wed, 2006-03-01 at 14:18, Bruce Momjian wrote:
Stephan Szabo wrote:
justify_days doesn't currently do anything with this result --- it
thinks its charter is only to reduce day components that are = 30 days.
However, I think a good case could be made that it should normalize
Christopher Browne wrote:
[EMAIL PROTECTED] (Mark Kirkwood) wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
Scott Marlowe wrote:
On Wed, 2006-03-01 at 14:18, Bruce Momjian wrote:
Stephan Szabo wrote:
justify_days doesn't currently do anything with this result --- it
thinks its charter is only to reduce day components that are = 30 days.
However, I think a good case could be made that it
Bruce Momjian pgman@candle.pha.pa.us writes:
I don't think we can accept a change that takes a negative and turns it
into a positive and negative.
Yeah, I find the patch's changes to the regression results pretty
disturbing.
Perhaps the correct definition ought to be like if month part = 0
Ühel kenal päeval, K, 2006-03-01 kell 15:18, kirjutas Bruce Momjian:
Stephan Szabo wrote:
justify_days doesn't currently do anything with this result --- it
thinks its charter is only to reduce day components that are = 30 days.
However, I think a good case could be made that it should
On Wed, 1 Mar 2006, Hannu Krosing wrote:
Ühel kenal päeval, K, 2006-03-01 kell 15:18, kirjutas Bruce Momjian:
Stephan Szabo wrote:
justify_days doesn't currently do anything with this result --- it
thinks its charter is only to reduce day components that are = 30 days.
However, I
Hannu Krosing wrote:
?hel kenal p?eval, K, 2006-03-01 kell 15:18, kirjutas Bruce Momjian:
Stephan Szabo wrote:
justify_days doesn't currently do anything with this result --- it
thinks its charter is only to reduce day components that are = 30 days.
However, I think a good case
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I don't think we can accept a change that takes a negative and turns it
into a positive and negative.
Yeah, I find the patch's changes to the regression results pretty
disturbing.
Perhaps the correct definition ought to be
Hannu Krosing [EMAIL PROTECTED] writes:
But unfortunately '2 mons -1 days' '1 mons 29 days'
If I want something to happen 1 day less than two months from dome date,
then the only way to say that consistently *is* '2 mons -1 days'.
Sure, but if you want to represent that then you don't pass
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I don't think we can accept a change that takes a negative and turns it
into a positive and negative.
Yeah, I find the patch's changes to the regression results pretty
disturbing.
Perhaps the correct definition ought to be like
Hannu Krosing wrote:
But unfortunately '2 mons -1 days' '1 mons 29 days'
If I want something to happen 1 day less than two months from dome date,
then the only way to say that consistently *is* '2 mons -1 days'.
Correct me if I am wrong, but I thought that justify_days would only be called
Bruce Momjian wrote:
Lamar Owen wrote:
On Monday 27 February 2006 21:09, Bruce Momjian wrote:
One question I have is how this feature would be an improvement over
just pointing pg_ctl at a postgresql.conf configuration file. That
config file has the ability to specify most if not all server
Mark Dilger [EMAIL PROTECTED] writes:
Tom Lane wrote:
I guess I would expect a good result to satisfy one of these three
cases:
* month 0 and 0 = day 30
* month 0 and -30 day = 0
* month = 0 and -30 day 30
If you believe that then 1 month -95 days should justify to
-2
On Wed, 2006-03-01 at 14:27, Bruce Momjian wrote:
Scott Marlowe wrote:
On Wed, 2006-03-01 at 14:18, Bruce Momjian wrote:
Stephan Szabo wrote:
justify_days doesn't currently do anything with this result --- it
thinks its charter is only to reduce day components that are = 30
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
Tom Lane wrote:
I guess I would expect a good result to satisfy one of these three
cases:
* month 0 and 0 = day 30
* month 0 and -30 day = 0
* month = 0 and -30 day 30
If you believe that then 1 month -95
Mark Dilger [EMAIL PROTECTED] writes:
The current code (without the patch) behaves as follows:
select justify_days(justify_hours('1 month 95 days -36:00:00'::interval));
justify_days
-
4 mons 4 days -12:00:00
So? If we liked the current behavior
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
The current code (without the patch) behaves as follows:
select justify_days(justify_hours('1 month 95 days -36:00:00'::interval));
justify_days
-
4 mons 4 days -12:00:00
So? If we liked the
Mark Dilger wrote:
Your proposal is that justify_hours borrows 24 hours from the days column in
order to bring the -12 hours up to a positive 12 hours. Should it only do
that
if the days column is a positive number? What if it is negative?
I think we all agree on the following but
Bruce Momjian wrote:
Mark Dilger wrote:
Your proposal is that justify_hours borrows 24 hours from the days column in
order to bring the -12 hours up to a positive 12 hours. Should it only do that
if the days column is a positive number? What if it is negative?
I think we all agree on the
Hey guys,
What's the status of the current INSERT/UPDATE/DELETE RETURNING patch? Is it ready to go or does it need to be cleaned up?
-- Jonah H. Harris, Database Internals ArchitectEnterpriseDB Corporation732.331.1324
Jonah H. Harris wrote:
Hey guys,
What's the status of the current INSERT/UPDATE/DELETE RETURNING patch? Is
it ready to go or does it need to be cleaned up?
Uh, I don't remember seeing any patch like that. Where is it?
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc.
http://candle.pha.pa.us/mhonarc/patches_hold/msg00014.html
On 3/1/06, Bruce Momjian pgman@candle.pha.pa.us wrote:
Jonah H. Harris wrote: Hey guys, What's the status of the current INSERT/UPDATE/DELETE RETURNING patch?Is it ready to go or does it need to be cleaned up?Uh, I don't remember seeing
On Wed, 1 Mar 2006, Bruce Momjian wrote:
Jonah H. Harris wrote:
Hey guys,
What's the status of the current INSERT/UPDATE/DELETE RETURNING patch? Is
it ready to go or does it need to be cleaned up?
Uh, I don't remember seeing any patch like that. Where is it?
Omar Kilani sent in a
OK... I guess I'll go through the archives and see what Tom et al's
comments were and work from there. I tried to contact Omar a
couple times via email and got no response.
Thanks!On 3/1/06, Gavin Sherry [EMAIL PROTECTED] wrote:
On Wed, 1 Mar 2006, Bruce Momjian wrote: Jonah H. Harris wrote: Hey
Gavin Sherry wrote:
On Wed, 1 Mar 2006, Bruce Momjian wrote:
Jonah H. Harris wrote:
Hey guys,
What's the status of the current INSERT/UPDATE/DELETE RETURNING patch? Is
it ready to go or does it need to be cleaned up?
Uh, I don't remember seeing any patch like that. Where is
A new patch is attached. Please note the regression differences.
mark
Index: src/backend/utils/adt/timestamp.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v
retrieving revision 1.160
diff --context=5
Bruce Momjian wrote:
Mark Kirkwood wrote:
What if we add an option to initdb to allow the user to specify the name
and location of the postgresql.conf file?
That is certainly a way to approach it, I see the tough bit being the
parsing of postgresql.conf to figure out which parts of the
Bruce Momjian pgman@candle.pha.pa.us writes:
Imagine this:
'1 mons -2 days -12:00:00'
Which sign do we head to for this? For justify_hours, if we don't look
at the months it remains unchange, but calling justify_days we get:
'28 days -12:00:00'
which is wrong (negative and
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
Am I correct that the second case should still have negative hours?
Yes...
If so, then justify_hours(...) needs to examine the sign of the days
and months portion of the interval while performing its work.
No, it should ignore the
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Imagine this:
'1 mons -2 days -12:00:00'
Which sign do we head to for this? For justify_hours, if we don't look
at the months it remains unchange, but calling justify_days we get:
'28 days -12:00:00'
which
Bruce Momjian wrote:
If we do that, we should just call it justify_interval(). I am thinking
this is the direction to go, and for people who want more control they
use the justify_hours and justify_days, and those are left unchanged.
I agree. Let's leave the existing functions alone. I can
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Based on that, I guess I have to change my vote: justify_hours should
still not look at the month (because it shouldn't use the month=30days
assumption), but justify_days should be changed to be effectively a
combination of both
Tom Lane wrote:
Well, the question is whether justify_days has a sane definition that is
different from this. Based on your example, I'm not seeing one.
Backwards compatibility is probably more important than sanity. Let's just
deprecate the existing functions and recommend that people use
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Based on that, I guess I have to change my vote: justify_hours should
still not look at the month (because it shouldn't use the month=30days
assumption), but justify_days should be changed to be effectively a
Bruce Momjian pgman@candle.pha.pa.us writes:
Well, the question is whether justify_days has a sane definition that is
different from this. Based on your example, I'm not seeing one.
Uh, justify days only deals with days -- months conversions. There is
no processing for hours. I don't
Mark Dilger [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
If we do that, we should just call it justify_interval(). I am thinking
this is the direction to go, and for people who want more control they
use the justify_hours and justify_days, and those are left unchanged.
I agree. Let's
Mark Dilger [EMAIL PROTECTED] writes:
This overall design seems more flexible than Tom's recent post in which he
stated that justify_days should call justify_hours internally.
AFAIR I said the exact opposite.
regards, tom lane
---(end of
Mark Dilger wrote:
Tom Lane wrote:
Well, the question is whether justify_days has a sane definition that is
different from this. Based on your example, I'm not seeing one.
Backwards compatibility is probably more important than sanity. Let's just
deprecate the existing functions and
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
This overall design seems more flexible than Tom's recent post in which he
stated that justify_days should call justify_hours internally.
AFAIR I said the exact opposite.
regards, tom lane
Tom Lane also wrote:
Bruce Momjian wrote:
Even if we had people do:
justify_hours(justify_days(justify_hours()))
I don't think that would do what we want in all cases. Consider '1 mon
-1 hour'. That should be '29 days 23 hours' but neither existing
function, even if modified, will allow us to return
Mark Dilger [EMAIL PROTECTED] writes:
justify_days(justify_hours(...)) fixes *everything* in the most recently
submitted patch, regardless of the convoluted case you invent. There is no
data
for which it won't work.
If so, one function or the other is cheating. Per discussion,
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
justify_days(justify_hours(...)) fixes *everything* in the most recently
submitted patch, regardless of the convoluted case you invent. There is no data
for which it won't work.
If so, one function or the other is cheating. Per
Mark Dilger [EMAIL PROTECTED] writes:
Tom Lane wrote:
If so, one function or the other is cheating.
That depends what you mean by cheating. The justify_hours function
looks to see what answer justify_days would give, but does not
actually change the data. I described this all earlier and I
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
Tom Lane wrote:
If so, one function or the other is cheating.
That depends what you mean by cheating. The justify_hours function
looks to see what answer justify_days would give, but does not
actually change the data. I described
if [ $USER = 'root' -o $LOGNAME = 'root' ]
Always fails because even tho $USER is set to 'pgsql' when su'ed,
$LOGNAME is still root.
This is on FreeBSD 4.9
It seems to work on Linux; apparently there are different behaviors of su. Do
you have a suggestion for resolving this?
Well all I
I wonder if there could be a potential problem with using this approach
-
checking on $USER == root.
Although it is a common practice, I think a superuser does not have to
be root.
Yes, like the 'toor' account in FreeBSD... (disabled by default though)
Chris
---(end
Christopher Kings-Lynne wrote:
I wonder if there could be a potential problem with using this approach
-
checking on $USER == root.
Although it is a common practice, I think a superuser does not have to
be root.
Yes, like the 'toor' account in FreeBSD... (disabled by default though)
Might
I have a question about how to display query time of postgres. I found
this
postgres [ -A { 0 | 1 } ] [ -B buffers ] [ -c name=value ] [ -d
debug-level ]
[ -D datadir ] [ -e ] [ -E ] [ -f { s | i | n | m | h } ] [ -F ]
[ -i ] [ -L ] [ -N ] [ -o file-name ] [ -O ] [ -P ]
On Wed, Mar 01, 2006 at 10:13:02PM -0600, John wrote:
adding -s will print the statistis and time. But I have no idea how to call
this using postmaster -o option. Anyone give me a hint? Thanks.
postmaster -o -s [ other options ]
Or you could enable log_statement_stats in postgresql.conf.
--
Michael Fuhr [EMAIL PROTECTED] writes:
... I started to work on a patch but I wasn't sure how
to handle the chicken-and-egg situation of dropping a type and its
I/O functions. Is there any way to do that other than DROP TYPE
CASCADE? Should the uninstall scripts be doing that?
DROP TYPE
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
That has nothing to do with it, because the space isn't actually free
for re-use until vacuum deletes the tuple.
I think the idea is a different free space map of sorts, whereby a
transaction that obsoletes a tuple puts its block
Ühel kenal päeval, K, 2006-03-01 kell 14:36, kirjutas Scott Marlowe:
But it isn't '-2 months, -1 day'. I think what you are saying is what I
am saying, that we should make the signs consistent.
Pretty much. It just seems wrong to have different signs in what is
essentially a single
On Thu, Mar 02, 2006 at 01:01:21AM -0500, Tom Lane wrote:
Essentially, we would be folding the find
dead tuples and compress page logic, which is currently in vacuum, back
to insert. IMHO this is unacceptable from a performance PoV.
That's the other problem: it's not apparent why pushing
Hannu Krosing schrieb:
Ühel kenal päeval, K, 2006-03-01 kell 14:36, kirjutas Scott Marlowe:
...
But we do say both quarter past three (3 hours 15 min) and quarter to
four (4 hours -15 min) when talking about time.
but luckily we dont write it ;)
Some people say (like ) this: quarter past 3,
Thanks for the info, I shall indeed try this.
One thing to mention is that I don't think the error occurs within
initdb, it seams to be postgres.exe that dbinit starts.
Regards
James
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: 01 March 2006 16:26
To:
100 matches
Mail list logo
