"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 Microso
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
> comp
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.
[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.
> >>
> >>
Simon Riggs wrote:
> > > The way forward seems safest if this is a command, not an external
> > > executable. e.g. ALTER SYSTEM STOP BACKEND . That way we
> > have control
> > > over the implementation/porting, security, logging/audit.
> > Anybody that
> > > wants to can then wrap that in a script
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 convi
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 (mi
> -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, Apri
> -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
>
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 are
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 ./src/backend/port/pg
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
>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/
[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. S
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 transac
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 abstr
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 ./src/
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
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-abor
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.
> >
>
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
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 repo
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
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
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 convinc
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 repo
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 t
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
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-abor
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 norma
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 tr
> 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)---
TI
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 n
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 (y
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 ta
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
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,
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 co
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 i
[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 res
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 in
How can I execute a prepared query using the
libpq interface? The SQL Prepare documentation talks about select
statements, but where is the documentation on SQL OPEN or some functionally
equivalent libpq API? That is to say how is a cursor generated from a
plan?
Thanks
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 broadcast)
"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
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 query
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 particu
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
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:
> > >> 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 canc
On Apr 4, 2004, at 3:41 PM, Greg Sabino Mullane wrote:
I am trying to get version 7.4.2 installed on a Solaris box, but
initdb fails because of shmmax being set too low. It does this
even though initdb drops shared buffers as low as it can go (50).
Is there any other way of getting around this li
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 wante
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
"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
functio
> > 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
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
"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 qu
> >>> 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 inp
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 concatenat
>
> 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 tes
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 conta
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
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 vers
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 libr
> > - 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 c
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.
>
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;
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. How
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 notific
68 matches
Mail list logo
