alidate a config file without having to copy
it into place first.
postgres --check-config=myFilenameGoesHere -D $PGDATA
-- Korry
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
your extensions
and then look through the valgrind output file for that process.
-- Korry
--
Korry Douglas <[EMAIL PROTECTED]>
EnterpriseDBhttp://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
stderr.
The client application can't intercept those messages. And those
messages will often get lost - many client applications don't have
useful stderr streams (think GUI application on Win32).
-- Korry
--
Korry Douglas <[EMAIL PROTECTED]>
EnterpriseDBhttp://w
d that the "ROW
OF foo" was somehow related to the function arguments.
-- Korry
--
Korry Douglas <[EMAIL PROTECTED]>
EnterpriseDBhttp://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
t a breakpoint in your new
code; finally, go back to your psql session and execute a command that
exercises your code.
-- Korry
--
Korry Douglas <[EMAIL PROTECTED]>
EnterpriseDBhttp://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hacker
In the docs it is mentioned for datistemplate that
"If true then this database can be used in the "TEMPLATE" clause of
CREATE DATABASE to create the new database as a clone of this one."
However, one can create a database using as template another DB that has
datistemplate set to false.
In thi
There has been some previous discussion of changing the FE/BE protocol
in 7.4, in order to fix several problems. I think this is worth doing:
if we can resolve all these issues in a single release, it will lessen
the upgrade difficulties for users.
Here are a couple of other changes you might c
> b) Send a decoded version of atttypmod - specifically, decode the
> precision and scale for numeric types.
>
I want decode type,length,precision and scale
Type is returned by PQftype(), length is returned by PQfsize(). Precision
and scale are encoded in the return value from PQfmod() and y
/pgSQL and ecpg chapters - it's been difficult to find
good information on either of those (until now).
I hope you enjoy the rest of the book.
-- Korry
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
SQL debugger and I haven't gotten around to posting a patch yet, sorry.
-- Korry ([EMAIL PROTECTED])
ve
a plugin loaded).
Any other comments? Obviously, you'll have a chance to critique the
patch when I get it sent in.
Thanks for your help.
-- Korry
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
ot sure I see a need for this.
That makes a lot more sense - I don't like the idea of each plugin
managing its own version information. We can always add more function
pointers to the end of the plugin structure - if the pointers are
non-NULL, you gain more functionality.
4) Do we need to support multiple active plugins?
Probably, but let's fix the API to hide this, so we don't have to commit
now.
Cool.
-- Korry
Time units is easy:
1h = 60min = 3600s = 360ms
We don't need anything larger than seconds at the moment.
Except for log_rotation_age perhaps?
-- Korry
take with TRACE. PG_TRACE is good,
and so is pg_trace.h. (But invoking it as utils/trace.h would be ok.)
How about the obvious DTRACE( .... ) or some similar variant?
-- Korry
Sorry to poke - but I'd like to get a patch submitted next week. Any
more comments? Thanks.
-- Korry
Thanks
for the quick feedback.
1) I think the most straightforward way to load an instrumentation
plugin is to define a new custom GUC variable (usin
);
and so on. There are a few functions that you can call to attach your
debugger client to a target server and to set global breakpoints.
I'll be posting more information as we get closer to releasing this stuff.
-- Korry
---(end of
ecify
libraryName, we could look for a hard-coded default.
(Oh, and any more comments on security? Is it enough to require that
all plugins live in $libdir?)
-- Korry
u've thrown a printf() into the code, you can't use a "%s" format specifier, you'll have to look at the bytes one at a time using something like "%02X".
-- Korry
> I asked this question about a half year ago or so, and got:
>
> http://archives.postgresql.org/pgsql-hackers/2005-05/msg00331.php
Thanks James, that's just what I was looking for.
-- Korry
---(end of broadcast)-
rformance hit you would suffer, but you wouldn't have to
change your application at all that way. Perhaps a private mount so that
only the postgresql process tree could see the decrypted bits?
-- Korry
---(end of broadcast)-
pg_hba.conf could be stored in the same encrypting
filesystem.
-- Korry
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
in that takes care of the database would
obviously have the decrypt password for the encrypting filesystem. That
admin (but not other admins) can change the pg_hba.conf file.
-- Korry
---(end of broadcast)---
TIP 1: if posting/r
otherwise is
> just folly.
Agreed - that would be a much better (easier and more secure) solution where
practical.
-- Korry
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
to indicate that the postmaster is still running? At first blush, that seems more reliable than checking for a (possibly recycled) process ID.
-- Korry
On Wednesday 24 May 2006 21:03, korry wrote:
> > I'm sure there's a good reason for having it the way it is, having so
> > many smart knowledgeable people working on this project. Could someone
> > please explain the rationale of the current solution to m
-file is portable to all Unix/Linux systems that I've seen (that way, you can lock a region of a file before you grow the file).
-- Korry
On Wed, 2006-05-24 at 16:34 -0400, Alvaro Herrera wrote:
korry wrote:
> > The Win32 API for locking seems mighty strange to me.
>
> Linux/Unix byte locking is advisory (meaning that one lock can block
> another lock, but it can't block a read).
No -- it is advisory me
ly have in place is not bulletproof. I think holding a byte-range lock in addition to the "is there some process with the right pid?" check might be a little more bullet resistant :-)
-- Korry
supports SEM_UNDO.
(Sorry if this has been suggested before)
-- Korry
that, and I agree that if NFS is important and locking is brain-dead on NFS, then relying solely on a lock is unacceptable.
-- Korry
We already have two platforms that don't use the SysV semaphore
interface, and even on ones that have it, I wouldn't want to assume they
all support SEM_UNDO.
Which platforms, just out of curiousity? I assume that Win32 is one of them.
But aside from any portability issues, ISTM this w
if there is a backend
running that was started by a no-longer-running postmaster.
Oh... didn't know that. How is that accomplished now? There must be some code beside the pid file check.
-- Korry
sers not to use NFS), but now that I think about it, SMB locking is very unreliable so Win32 would be an issue too.
-- Korry
y stack dump). The numbers aren't always exactly the same, but in most cases they are.
Obviously you're now writing 12 extra bytes of overhead to each AllocChunkData (__FILE__, __LINE__, and callCount) and 4 bytes to each AllocSetContext (callCount).
-- Korry
if this has been covered before - if you can point me to a document
that covers the information I'm looking for, that would be very helpful).
-- Korry
---(end of broadcast)---
TIP 4: Have you searched our list
ARNING category, or any of the conditions listed in the NO DATA category. (At least through 8.0 rc1 - I haven't checked in later versions).
-- Korry
On Sat, 2005-01-01 at 14:10 -0500, Tom Lane wrote:
Korry <[EMAIL PROTECTED]> writes:
> It seems you can’t trap every condition listed in errocodes-
> appendix.html; in particular, you can’t trap SUCCESSFUL_COMPLETION, any
> of the conditions listed in the WARNING category
ortstr, portnum, conn->pgunixsocket); in the header
comment at the top of fe-connect.c).
-- Korry
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-mode connect
functions, not by async state machine. But I decided to publish patch
without these improvements to get feedback from community.
A bit of testing on this turns up a problem.
Consider a connection string that specifies two hosts and a read/write
connection:
postgresql://korry@127.
-mode connect
functions, not by async state machine. But I decided to publish patch
without these improvements to get feedback from community.
A bit of testing on this turns up a problem.
Consider a connection string that specifies two hosts and a read/write
connection:
postgresql://korry@127.
s translated to ltrim(4+2, 'foo').
It seems to me that trim_list should defined as:
trim_list:a_expr FROM a_expr { $$ = list_make2($3, $1); }
| FROM a_expr { $$ = list_make1($2); }
o omit FROM if
you've written a . Should we tighten our
syntax to reject that?
That depends on how much code you want to break. Doesn't really
matter to me.
-- Korry
---
Korry Douglas
Senior Database D
to add any special flags to the Makefile.
-- Korry
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d all case variants) refer to some number of bytes.
If a user wants to specify a variable in terms of bits, he would have
to spell out the units completely, as in "4 gigabits", "20 kilobits",
or "16 megabits".
-- Korry
--
Sent vi
of (at least
AIX 5.3).
aix.c was required long ago because AIX did not offer the popular
dlopen(), dlsym(), dlclose(), and dlerror() functions - you had to
write them yourself.
-- Korry
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
45 matches
Mail list logo
