On Fri, 2004-04-02 at 16:52, Magnus Hagander wrote:
Hi!
When debugging on win32, I've created myself a little function that I
feel should be added to the backend proper. While it adds a lot of
vlaue on win32, I think it adds quite a bit of value on non-win32
platforms as well...
The
Oops! [EMAIL PROTECTED] (J. Andrew Rogers) was seen spray-painting on a wall:
I may be completely missing the point here, but it looks to me as
though the PITR archival mechanism is also most of a native
replication facility. Is there anyone reason this couldn't be
extended to replication,
Paul Tillotson wrote:
Hans et al:
People asked me to put a simple extension for PostgreSQL Open Source.
The attached package contains a simple functions whichs tells a remote
TCP socket that somebody is about to modify a certain table.
I would very much appreciate being able to receive
Dear hackers,
I'm still developing some advisor views to give advices about tables,
database settings and so in postgresql.
I'm thinking of allowing advices about incoherent or dangerous host base
authentification configurations. I would like to access pg_hba.conf
from within the database.
I'm surprise with query plan that PostgreSQL planner prepare for
selects with ORDER BY if all data are from sub-select that is already
sorted.
# explain select data from
(select distinct data from addr)
as x order by x.data;
On Tuesday 06 April 2004 12:10, Fabien COELHO wrote:
I'm thinking of allowing advices about incoherent or dangerous host base
authentification configurations. I would like to access pg_hba.conf
from within the database. However, I could not find any pg_catalog that
would fit my needs.
- am
- is it a design principle that this information is not available,
or just a lack of time and/or need up to know?
would it make sense to add such a view?
I believe the thinking is that you want to check whether someone is
allowed to connect to the database without having to connect
Hi!
1) Is this depending on the server, or the fact that there is a
different libpq.dll in the path? Does a non-win32 client work against
the win32 server, and vice versa?
2) Are you using the import library from mingw, or the one from the old
visual C++ compile? If you are using the import
Anyone see a benefit of adding command line flags to initdb to force
lower shared memory use without require a recompile?
Robert Treat
On Mon, 2004-04-05 at 08:53, Andrew Dunstan wrote:
Greg Sabino Mullane said:
Having to recompile initdb.c is probably not an option.
Which version of
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Seems like useful functionality. Right now, how does an administrator
kill another backend from psql? They can't.
The question to ask is should they be able to?
I think any such facility is inherently a security
I have been doing some experimentation for a series of articles I am
writing, and want to create a user with as little privilege as possible
who can still do the things I explicitly want him/her to be able to do.
In particular, I wanted to be able to deny any useful access to the
metadata
Anyone see a benefit of adding command line flags to initdb to force
lower shared memory use without require a recompile?
[snip]
When I built and installed pgsql at work, on a production server,
I ran into the shared memory problem. I wanted to fire pgsql up
*right* *away*, to begin
Karel Zak [EMAIL PROTECTED] writes:
I'm surprise with query plan that PostgreSQL planner prepare for
selects with ORDER BY if all data are from sub-select that is already
sorted.
This isn't simply a matter of omitting the sort. Even if the inputs
are sorted, their concatenation
In this case, SIGINT (query cancel) will not help, because
all locks held by the transaction will still be held.
Wrong.
Really?
[ experiments... ] My apologies --- you are correct about
the present behavior. If a SIGINT arrives while waiting for
client input, it's just
Magnus Hagander [EMAIL PROTECTED] writes:
if (query_running)
cancel_query
abort transaction
else if (idle in transaction)
abort transaction
else if (idle not in transaction)
graceful shutdown
or if that is too confusing?
Too hazardous. Say you meant to kill a slow query, only
Robert Treat [EMAIL PROTECTED] writes:
Anyone see a benefit of adding command line flags to initdb to force
lower shared memory use without require a recompile?
Lower than what? The bottom values it checks are already ridiculously
small. If you can't get it to initdb you really need to fix
if (query_running)
cancel_query
abort transaction
else if (idle in transaction)
abort transaction
else if (idle not in transaction)
graceful shutdown
or if that is too confusing?
Too hazardous. Say you meant to kill a slow query, only it
finishes just before you
Magnus Hagander [EMAIL PROTECTED] writes:
If we are going to allow session kill then of course we need
PID for that.
I still say we need this.
Well, that seems to be the consensus, so I won't stand in the way.
If you like the cancel-by-XID idea then I'd suggest providing two
functions:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If we are going to allow session kill then of course we need
PID for that.
I still say we need this.
Well, that seems to be the consensus, so I won't stand in the way.
If you like the cancel-by-XID idea then I'd suggest
On Tue, 2004-04-06 at 10:23, Andrew Dunstan wrote:
I have been doing some experimentation for a series of articles I am
writing, and want to create a user with as little privilege as possible
who can still do the things I explicitly want him/her to be able to do.
In particular, I wanted to
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If we are going to allow session kill then of course we need
PID for that.
I still say we need this.
Well, that seems to be the consensus, so I won't stand in the way.
If you like the cancel-by-XID idea then I'd
I came across an interesting feature regarding namespace name changes. To illustrate
suppose you have two
connections open whose commands occur in the following sequence:
Time | Session A| Session B
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
But are you saying it *is* safe with SIGTERM to a backend?
I'm saying I'm not happy about promoting that to the status of a
supported feature. Up to now it's always been if it breaks you
get to keep both pieces, but if there's a
Rod Taylor wrote:
On Tue, 2004-04-06 at 10:23, Andrew Dunstan wrote:
I have been doing some experimentation for a series of articles I am
writing, and want to create a user with as little privilege as possible
who can still do the things I explicitly want him/her to be able to do.
In
Bruce Momjian [EMAIL PROTECTED] writes:
I assume admins are already doing this (via kill), so whether it is
supported or not, we should give folks a safe way to do this.
I don't think it's an open-and-shut decision as to whether people
actually *need* to do session kills (as opposed to
Magnus Hagander [EMAIL PROTECTED] writes:
But are you saying it *is* safe with SIGTERM to a backend?
I'm saying I'm not happy about promoting that to the status of a
supported feature. Up to now it's always been if it breaks you
get to keep both pieces, but if there's a built-in function to do
In information i have:
1. when creating view : PostgreSQL parse the query and stock the tree query.
2. when using : PostgreSQL use this tree like a subselect.
my question : Do PostgreSQL makes an analyse of the resulted tree ?
---(end of
How can I execute a prepared queryusing the
libpq interface? The SQL Prepare documentation talks aboutselect
statements, but where is thedocumentation on SQL OPEN or some functionally
equivalent libpq API?That is to say howis a cursor generated from a
plan?
Thanks
Hi
I am newbe so this problem may be too simple to be asked.please help me if
any new thing to be added in following:
I created data type IndChar The c functions are:
typedef struct IndChar
{
int32 len;
char c_in_str[1];
}IndChar;
then i defined input output functions.
Input: Datum
[EMAIL PROTECTED] (elrik) wrote in message news:[EMAIL PROTECTED]...
In information i have:
1. when creating view : PostgreSQL parse the query and stock the tree query.
2. when using : PostgreSQL use this tree like a subselect.
my question : Do PostgreSQL makes an analyse of the resulted
Joe Conway [EMAIL PROTECTED] writes:
I'd think given the preceding, it would make more sense to throw an error
whenever trying to access an element greater than the length.
For an analogous situation in SQL I would propose
select (select foo from bar where xyz);
if there are no records in
Josh Berkus wrote:
Tom,
I don't think it's an open-and-shut decision as to whether people
actually *need* to do session kills (as opposed to query/transaction
kills). The arguments presented so far are not convincing to my mind,
certainly not convincing enough to buy into a commitment
On Tue, 2004-04-06 at 08:23, Richard Huxton wrote:
On Tuesday 06 April 2004 12:10, Fabien COELHO wrote:
I'm thinking of allowing advices about incoherent or dangerous host base
authentification configurations. I would like to access pg_hba.conf
from within the database. However, I could
Bruce,
Someone already posted some pseudocode where they wanted to kill idle
backends, perhaps as part of connection pooling.
I'm not talking about code. I'm talking about a *reason*.
i.e.: I'm administrator of the blah-blah project. We had a lot of trouble
managing idle connections to
Tom,
I don't think it's an open-and-shut decision as to whether people
actually *need* to do session kills (as opposed to query/transaction
kills). The arguments presented so far are not convincing to my mind,
certainly not convincing enough to buy into a commitment to do whatever
it takes
Bruce,
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not being run from the same machine as the
server (you
Josh Berkus [EMAIL PROTECTED] writes:
So I would vote for Yes on SIGINT by XID, but No on SIGTERM by PID, if Tom
thinks there will be any significant support troubleshooting involved for
the latter.
Quite honestly, I don't know. We know that some people have done manual
SIGTERMs and not
In fact the probleme is when i have more than 11 tables in the query...
Please post the EXPLAIN ANALYZE results of the problematic query, as
well as the definition of any views it uses.
Also, SHOW from_collapse_limit;
---(end of broadcast)---
Josh Berkus wrote:
Bruce,
Someone already posted some pseudocode where they wanted to kill idle
backends, perhaps as part of connection pooling.
I'm not talking about code. I'm talking about a *reason*.
i.e.: I'm administrator of the blah-blah project. We had a lot of trouble
Bruce Momjian [EMAIL PROTECTED] writes:
If there is a problem, maybe we can fix it, or perhap have the kill
function use SIGINT, then wait for the query to cancel, then SIGTERM.
Well, if someone could prove that the SIGTERM path is equivalent to
a transaction-aborting error followed by normal
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If there is a problem, maybe we can fix it, or perhap have the kill
function use SIGINT, then wait for the query to cancel, then SIGTERM.
Well, if someone could prove that the SIGTERM path is equivalent to
a transaction-aborting
Josh Berkus wrote:
Bruce,
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not being run from the same
Bruce Momjian [EMAIL PROTECTED] writes:
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not being run from the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not
pgman wrote:
Josh Berkus wrote:
Tom,
I don't think it's an open-and-shut decision as to whether people
actually *need* to do session kills (as opposed to query/transaction
kills). The arguments presented so far are not convincing to my mind,
certainly not convincing enough to
Bruce Momjian [EMAIL PROTECTED] writes:
Not having a way to kill backends is like having no way to kill a
process except rebooting the server.
Some people think that making a database hard to kill is a good thing.
regards, tom lane
---(end of
[EMAIL PROTECTED] (Marc G. Fournier) writes:
On Thu, 1 Apr 2004, Christopher Kings-Lynne wrote:
Is your timeline based on the assumption of doing all the work
yourself? If so, how about farming out some of it? I'd be
willing to contribute some effort to PITR. (It's been made clear
to
On Tue, 2004-04-06 at 15:23, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
So I would vote for Yes on SIGINT by XID, but No on SIGTERM by PID, if Tom
thinks there will be any significant support troubleshooting involved for
the latter.
So like I say, I'm hesitant to buy into
On Tue, 2004-04-06 at 15:10, Josh Berkus wrote:
Bruce,
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Not having a way to kill backends is like having no way to kill a
process except rebooting the server.
Some people think that making a database hard to kill is a good thing.
I can't argue with that. :-)
I am researching the SIGTERM
Rod Taylor wrote:
On Tue, 2004-04-06 at 15:23, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
So I would vote for Yes on SIGINT by XID, but No on SIGTERM by PID, if Tom
thinks there will be any significant support troubleshooting involved for
the latter.
So like I say,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If there is a problem, maybe we can fix it, or perhap have the kill
function use SIGINT, then wait for the query to cancel, then SIGTERM.
Well, if someone could prove that the SIGTERM path is equivalent to
a transaction-aborting
The function to kill backend seems no longer in doubt, but the
*reason* is still blurred, other than we don't want to bring down the
postmaster to do this.
So far, reasons given have been:
1. to kill idlers
2. to kill runaway queries/statements, which has transaction
implications
I'd like to be
I would like to suggest changing the symlinks to copy commands:
cp ./src/backend/port/tas/dummy.s ./src/backend/port/tas.s
cp ./src/backend/port/dynloader/win32.c ./src/backend/port/dynloader.c
cp ./src/backend/port/sysv_sema.c ./src/backend/port/pg_sema.c
cp ./src/backend/port/sysv_shmem.c
Mitani-san, how is pgcluster progressing? Have you considered hosting
it on gborg.postgresql.org, or at least creating a project there that
points to your web site?
---
mitani wrote:
Dear Bruce:
Included is the
Simon Riggs wrote:
The function to kill backend seems no longer in doubt, but the
*reason* is still blurred, other than we don't want to bring down the
postmaster to do this.
So far, reasons given have been:
1. to kill idlers
2. to kill runaway queries/statements, which has transaction
[moved to hackers]
Bruce Momjian wrote:
Andrew Dunstan wrote:
Why do we have log_min_error_statement default to PANIC level? Wouldn't
ERROR be a better default?
Panic basically means off, meaning we don't print queries that generate
errors. Should we print them by default?
I would.
Bruce Momjian
Simon Riggs wrote:
The function to kill backend seems no longer in doubt, but the
*reason* is still blurred, other than we don't want to
bring down the
postmaster to do this.
So far, reasons given have been:
1. to kill idlers
2. to kill runaway queries/statements,
On 31 Mar 2004, elrik wrote:
[EMAIL PROTECTED] (elrik) wrote in message news:[EMAIL PROTECTED]...
In information i have:
1. when creating view : PostgreSQL parse the query and stock the tree query.
2. when using : PostgreSQL use this tree like a subselect.
my question : Do
On Tue, 6 Apr 2004, Dann Corbit wrote:
I would like to suggest changing the symlinks to copy commands:
cp ./src/backend/port/tas/dummy.s ./src/backend/port/tas.s
cp ./src/backend/port/dynloader/win32.c ./src/backend/port/dynloader.c
cp ./src/backend/port/sysv_sema.c
Hi Dann,
whilst I have, on rare occasions, observed the symlink failure under MingW,
I've never come across the other issues you've mentioned (I build from cvs,
instead of snapshots, but I can't imagine that causes these problems).
Is it possible your MingW install is a broken? Which version
-Original Message-
From: Claudio Natoli [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 06, 2004 5:42 PM
To: Dann Corbit; '[EMAIL PROTECTED] '
Subject: RE: [HACKERS] Small suggestion on build script
Hi Dann,
whilst I have, on rare occasions, observed the symlink
failure
-Original Message-
From: Dann Corbit
Sent: Tuesday, April 06, 2004 5:47 PM
To: Claudio Natoli; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Small suggestion on build script
-Original Message-
From: Claudio Natoli [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 06, 2004
Hi Dann,
Which version
are you using?
Msys version is 1.0.
Ok, probably the same I'm using (MSYS-1.0.10 and MSYS-1.0.9)
[EMAIL PROTECTED] /u/postgresql-snapshot
$ gcc --version
gcc.exe (GCC) 3.3.3 (mingw special)
I'm using MinGW-3.1.0-1, which has:
gcc.exe (GCC) 3.2.3 (mingw
Bruce Momjian wrote:
pgman wrote:
Josh Berkus wrote:
Tom,
I don't think it's an open-and-shut decision as to whether people
actually *need* to do session kills (as opposed to query/transaction
kills). The arguments presented so far are not convincing to my mind,
certainly not
Simon Riggs wrote:
The way forward seems safest if this is a command, not an external
executable. e.g. ALTER SYSTEM STOP BACKEND x. That way we
have control
over the implementation/porting, security, logging/audit.
Anybody that
wants to can then wrap that in a script if they
Dann Corbit [EMAIL PROTECTED] writes:
I would like to suggest changing the symlinks to copy commands:
That would cause make to fail to handle update dependencies on the
linked files.
The reason is that under Mingw, I get random failures with the symlinks
This is the worst sort of Microsoft
[EMAIL PROTECTED] wrote:
On 4/5/04 8:31 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
OK, new patch applied that causes all threads to wait until the parent
checks their thread-specific pointers. I ran 1000 tests and all passed.
Hopefully it will good for you too.
I'll try to give it a
Bruce Momjian [EMAIL PROTECTED] writes:
My plan is to have 'configure' run this program as part of its
operation,
Peter's not going to be happy with you ;-) Runtime configure tests are
not part of the Grand Plan --- ideally configure should only have to do
compile and link tests.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
My plan is to have 'configure' run this program as part of its
operation,
Peter's not going to be happy with you ;-) Runtime configure tests are
not part of the Grand Plan --- ideally configure should only have to do
compile and
70 matches
Mail list logo
