Joachim Wieland wrote:
I'm working again on the patch for making guc variables fall back to their
default value if they get removed (or commented) in the configuration file.
There is still an issue with custom variables that needs discussion.
Remember that for regular variables we have the
Dateci un occhio
http://www.petitiononline.com/RESETINC/petition.html
Enrico
--
If Bill Gates had a penny for everytime Windows crashed,he'd be a
multi-billionaire by now ...oh look, he already is
[EMAIL PROTECTED] - Skype:sscotty71
http://www.linuxtime.it/enricopirozzi
Hi,
I was about to resubmit the phantom command ids patch for review, as I
noticed a little problem.
In fmgr.c in record_C_func, we cache the xmin and cmin, and later in
lookup_C_func we check that they match to determine if the cached
information is still valid. With phantom command ids,
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Having fixed that everything works fine with SET and WITH being reserved
keywords. You didn't mean to say I should be able to leave WITH unreserved
did
you?
I think we'd decided that was a lost cause, unless you
Heikki Linnakangas [EMAIL PROTECTED] writes:
I was about to resubmit the phantom command ids patch for review, as I
noticed a little problem.
In fmgr.c in record_C_func, we cache the xmin and cmin, and later in
lookup_C_func we check that they match to determine if the cached
information
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I was about to resubmit the phantom command ids patch for review, as I
noticed a little problem.
In fmgr.c in record_C_func, we cache the xmin and cmin, and later in
lookup_C_func we check that they match to determine if the cached
(working on the PL debugger...)
It appears that the libraries listed in shared_preload_libraries will
*not* be inherited by spawned backends on Win32 platforms.
Do we have to do something special to make that work?
Using ProcessExplorer (from sysinternals.com), I can see that my plugins
are
[EMAIL PROTECTED] writes:
It appears that the libraries listed in shared_preload_libraries will
*not* be inherited by spawned backends on Win32 platforms.
Well, yeah, because it's a fork/exec on that platform.
Should we just call process_shared_preload_libraries() after calling
Tom Lane wrote:
[EMAIL PROTECTED] writes:
It appears that the libraries listed in shared_preload_libraries will
*not* be inherited by spawned backends on Win32 platforms.
Well, yeah, because it's a fork/exec on that platform.
Should we just call
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't entirely see the point. The value of shared_preload_libraries
is to avoid paying per-process overhead to load the libraries, and that
benefit is already lost in a fork/exec world. Might as well just let
the libraries be loaded
On Wed, 24 Jan 2007, John Bartlett wrote:
[regarding optional DBA/SysAdmin logging of Updateable Cursors]
I can see where you are coming from but I am not sure if a new log entry
would be such a good idea. The result of creating such a low level log could
be to increase the amount of logging
Harald Armin Massa wrote:
PostgreSQL 8.1.5 and 8.2.1
both on W2K3, installed from the standard win32 msi installer.
Problem:
in postgresql.conf
ssl=on
but the files server.key etc. are NOT present.
Result: PostgreSQL service does not start. And no error message in any
log I
Henry B. Hotz wrote:
Henry B. Hotz: GSSAPI authentication method for C (FE/BE) and Java (FE).
Magnus Haglander: SSPI (GSSAPI compatible) authentication method for C
(FE) on Windows.
(That fair Magnus? Or you want to volunteer for BE support as well?)
Seems fair and about what we
Joshua D. Drake wrote:
On Fri, 2006-12-29 at 20:59 -0500, Bruce Momjian wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Richard Troy [EMAIL PROTECTED] writes:
... it occurs to me that perhaps Josh can implement
a command line switch to turn on command line numbering.
That
Actually ... I take that back. I was thinking of the original purpose
of preload_libraries, which was strictly performance optimization.
But in the new world of plugins there may be functional reasons for
wanting libraries to be loaded into backends --- and
shared_preload_libraries is not
Tom Lane wrote:
I wrote:
One possibility for fixing it is that maybe we should be making an
effort to execute Tcl_Finalize() before exiting the backend. If so,
having pltcl set up an on_proc_exit callback to do it would be the
appropriate thing. This is all speculation though.
Just for
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
this patch definitly changes behaviour but not actually for the better :-(
Oh well, it was worth a try. At this point I think we have to suppose
this is a Tcl bug and not our fault. Can you reproduce the problem in
bare tclsh? Try
$
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
backtrace for 7235:
(gdb) bt
Please do this in GDB:
thread apply all bt
(or maybe it is
threads apply all bt)
This'll give you backtraces for all threads in the process.
sorry forgot to mention that - the backtrace for the other
Now that the xml type as per SQL:2003 is pretty much finished, one
starts to wonder about what useful things one might do with it. What
we have so far contains only functions to construct XML values from SQL
data, but there is nothing that you can do with the type at the moment
except look at
[EMAIL PROTECTED] writes:
But in the new world of plugins there may be functional reasons for
wanting libraries to be loaded into backends --- and
shared_preload_libraries is not isomorphic to local_preload_libraries.
The permissions situation is different.
And, shared_preload_libraries is
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
this patch definitly changes behaviour but not actually for the better :-(
Oh well, it was worth a try. At this point I think we have to suppose
this is a Tcl bug and not our fault. Can you reproduce the problem in
bare tclsh?
Alvaro Herrera wrote:
I'd suggest sticking to something closer to the current two-phase design
where you make some preliminary decision which database to send a worker
to, and then the worker determines exactly what to do once it can look
around inside the DB. Possibly we need some
And, shared_preload_libraries is processed (in the postmaster) before
the shared-memory segment is created, so a shared_preload_library can
call RequestAddinShmemSpace() and RequestAddinLWLocks(), but a
local_preload_library cannot.
That doesn't seem like an issue though, since the copy
Markus Schiltknecht wrote:
Alvaro Herrera wrote:
I'd suggest sticking to something closer to the current two-phase design
where you make some preliminary decision which database to send a worker
to, and then the worker determines exactly what to do once it can look
around inside the DB.
[EMAIL PROTECTED] wrote:
And, shared_preload_libraries is processed (in the postmaster) before
the shared-memory segment is created, so a shared_preload_library can
call RequestAddinShmemSpace() and RequestAddinLWLocks(), but a
local_preload_library cannot.
That doesn't seem like
On Jan 29, 2007, at 9:49 AM, Magnus Hagander wrote:
Henry B. Hotz wrote:
Henry B. Hotz: GSSAPI authentication method for C (FE/BE) and
Java (FE).
Magnus Haglander: SSPI (GSSAPI compatible) authentication method
for C
(FE) on Windows.
(That fair Magnus? Or you want to volunteer for BE
Alvaro Herrera [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
You're right - we need the copy in the postmaster (to setup shared
memory and LW locks), and we need them in the backends too.
Just make sure you don't load the libraries in bgwriter et al ...
I see that Korry's patch doesn't
David Fetter wrote:
On Sun, Jan 28, 2007 at 02:14:36PM -0800, Joshua D. Drake wrote:
I don't think all or nothing is a good way to do this. 500
functions in a schema called extensions isn't much more helpful
than 500 in public. There's a reason namespaces were invented
long ago, and
Bruce Momjian wrote:
David Fetter wrote:
It's 982 functions as of this writing in CVS TIP's contrib. Do you
not get how wacky it is to have that many functions, none of which
have any collision-prevention built into their install scripts, in a
flat namespace?
We currently have 1695
Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.
---
Andrew Dunstan wrote:
Bruce Momjian wrote:
David Fetter wrote:
It's 982 functions as of this writing
Bruce Momjian [EMAIL PROTECTED] writes:
Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.
(A) I'm not sure we would have heard about it, and (B) any one user is
probably only using a subset of what has been proposed to be loaded by
Bruce Momjian wrote:
Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.
That is beside the point. Of course there haven't been conflicts -
precisely because a single group controls the whole lot. What I said was
that we should
Andrew Dunstan wrote:
Bruce Momjian wrote:
Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.
That is beside the point. Of course there haven't been conflicts -
precisely because a single group controls the whole lot. What I
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.
That is beside the point. Of course there haven't been conflicts -
precisely because a single group
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.
That is beside the point. Of course there haven't been conflicts -
On Mon, Jan 29, 2007 at 04:44:44PM -0500, Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.
That is beside the point. Of course
It is actually still in my mailbox to be added to TODO when I get up to it.
---
Alvaro Herrera wrote:
Joshua D. Drake wrote:
On Fri, 2006-12-29 at 20:59 -0500, Bruce Momjian wrote:
Alvaro Herrera wrote:
Tom Lane
Alvaro Herrera wrote:
I will claim this for now. I will let it go if I can't get at least
something productive done on it by end of January.
Now that the embargo period seems to be over, I think it would be a good
time to add it to the TODO list. Also, I'd modify the idea slightly to
You're right - we need the copy in the postmaster (to setup shared
memory and LW locks), and we need them in the backends too.
Just make sure you don't load the libraries in bgwriter et al ...
I see that Korry's patch doesn't do that, but I'm wondering why exactly.
In a Unix
BTW,
Moreover, I would like xpath_string() which return
On 1/29/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
[...]
So, while I realize that I've been arguing for a lean core recently, I
want to propose that we add a small set of XPath support functions to
the core. This would come down to
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
So what are we thinking here? Along with my suggestion of extensions /
contrib that we modify initdb to load an extensions schema with all
extensions into template1?
No, I don't think so. If you do that it's
Richard Huxton dev@archonet.com writes:
1. Add a new column for all system objects, separate from schema:
package.
Wouldn't it be a whole lot easier just to drive it off schema, rather
than inventing duplicative parallel infrastructure? That is, say that a
package has one or more schemas and
Tom Lane wrote:
Richard Huxton dev@archonet.com writes:
1. Add a new column for all system objects, separate from schema:
package.
Wouldn't it be a whole lot easier just to drive it off schema, rather
than inventing duplicative parallel infrastructure? That is, say that a
package has one or
Richard Huxton dev@archonet.com writes:
Tom Lane wrote:
Wouldn't it be a whole lot easier just to drive it off schema, rather
than inventing duplicative parallel infrastructure?
Four differences:
1. You couldn't have a tsearch package with functions in public. At
least not without some
Hi,
I am looking for a way via configuration to make Postgres
not to use the openssl lib libeay32.dll as I need to delete that
library. I basically need to remove any encryption (hash is fine)
features from my Postgres (8.x) installation. This is quite urgent for
me. I would be
On 27 Gen, 06:31, [EMAIL PROTECTED] (Martijn van Oosterhout) wrote:
To repeat: If you think this may have happened DO NOT run vacuum
now.Actually, for XID wraparound a VACUUM may actually be the right thing.
I looked at this (with guidence from Tom) and we came to the conclusion
that XID
check out the pg_description system catalog:
http://www.postgresql.org/docs/8.2/static/catalog-pg-description.html
-
http://www.elsasoft.org
On Jan 29, 2:40 pm, Timasmith [EMAIL PROTECTED] wrote:
Hi,
What query can I run to get the
Rebuild from source and DO NOT specify --with-openssl
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Dong
Sent: Saturday, January 27, 2007 12:16 PM
To: pgsql-hackers@postgresql.org
Cc: Tom Dong
Subject: [HACKERS] How to configure Postgres to make it not to
[EMAIL PROTECTED] writes:
On Jan 29, 2:40 pm, Timasmith [EMAIL PROTECTED] wrote:
What query can I run to get the comments on my table columns using
SQL?
check out the pg_description system catalog:
http://www.postgresql.org/docs/8.2/static/catalog-pg-description.html
Also see
Tom Lane wrote:
I agree
with having an explicit representation of a package in some new system
catalog for that purpose. That does not translate to needing to add
package hooks to every other catalog. Indirect links through schemas
seem more than sufficient.
This
Magnus Hagander [EMAIL PROTECTED] writes:
I'm thinking we need a check in elog.c on the:
if ((!Redirect_stderr || am_syslogger) pgwin32_is_service())
write_eventlog(edata-elevel, buf.data);
line, that checks if the syslogger process has been started yet.
[
[EMAIL PROTECTED] writes:
I see that Korry's patch doesn't do that, but I'm wondering why exactly.
In a Unix environment such libraries *would* be propagated into bgwriter
and every other postmaster child; is there a reason for the setup on
Windows to be different? In particular, what about
This seems like a good first step in growing a packaging
infrastructure. I'd rather grow it organically than try to design it
all up front.
I am in Denver and have spotty inet access so forgive me. So where does
this above leave us? What are we doing?
Joshua D. Drake
cheers
andrew
On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
You got me. My description was too loose, but you also got the rough
picture. We'll save the detail for another day, but we all know its a
bridge we will have to cross one day, soon. I wasn't meaning to raise
* Add missing operators for geometric data types and operators
There are geometric data types that do not have the full suite
of geometric operators
defined; for example, box @ point does not exist.
On Jan 26, 2007, at 9:32 PM, Bruce Momjian wrote:
Can I get a TODO on this?
Joshua D. Drake wrote:
This seems like a good first step in growing a packaging
infrastructure. I'd rather grow it organically than try to design it
all up front.
I am in Denver and have spotty inet access so forgive me. So where does
this above leave us? What are we doing?
I was
What about plpgsql variables, ie:
DECLARE
v varchar(42);
BEGIN
...
On Jan 26, 2007, at 9:48 PM, Andrew Dunstan wrote:
Bruce Momjian wrote:
OK, what is the TODO wording?cheers
Something like:
Enforce typmod for function inputs, function results and parameters
for spi_prepare'd
On Jan 26, 2007, at 5:09 PM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
On 1/26/2007 4:40 PM, Jim Nasby wrote:
It would be nice if we had a separate role for replication services
so that we weren't exposing superuser so much.
So you think about another flag in pg_shadow? Would work
Jim Nasby [EMAIL PROTECTED] writes:
On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
I don't actually see that it buys you a darn thing ... you still won't
be able to delete dead updated tuples because of the possibility of
the LRT deciding to chase ctid chains up from the tuples it can see.
Hi all,
I think I've heard the answer to this in another list, but I just want
to get the widest audience and set of opinions, to be sure..
Apparently right now the V3 protocol doesn't return table-aliases for
columns, like:
select employee.firstName, boss.firstName from contacts as employee,
60 matches
Mail list logo
