Greetings,
I was trying to build source build postgres 8.1.x with MIT
Kerberos 5 1.4.x implementation.
The whole thing bombs out. After some digging, I had to hack
the autoconf script (configure.in) to properly account for
the way the libraries are built for 1.4.x. I don't know
whether
Dear all,
I am writing a C-language shared-object file which is dynamically linked with
postgres, and uses the various SPI functions for executing queries from
numerous trigger functions.
My question is thus: what is the best method for a dynamically linked object
to share memory with the
On Sun, Feb 05, 2006 at 02:03:59PM +, [EMAIL PROTECTED] wrote:
1. Change memory context to TopMemoryContext and palloc everything there.
(However, I believe this still isn't shared between processes?)
Not shared, correct.
2. Use the shmem functions in src/backend/storage/ipc/shmem.c to
You'll still need to run the postmaster frmo pg_ctl to
get the run
as admin part. The only part that could be moved is the
Job Object
for management. And you're normally not going to need
that one when
you're not running as a service. Maybe sometimes, but I
doubt it's
[EMAIL PROTECTED] writes:
1. Change memory context to TopMemoryContext and palloc everything there.
(However, I believe this still isn't shared between processes?)
Nope.
2. Use the shmem functions in src/backend/storage/ipc/shmem.c to create a
chunk of shared memory and use this (Although
On Sun February 5 2006 14:11, Martijn van Oosterhout wrote:
This is the generally accepted method. Please remember that when
sharing structures you have to worry about concurrency. So you need
locking.
Of course - I have already implemented locking with semaphores (I may simply
use one big
On Sun, Feb 05, 2006 at 02:31:23PM +, Richard Hills wrote:
I have a number of functions which modify tables based on complex rules
stored
in script-files. I wrote a parser for these files as a separate program first
before incorporating it as a shared object, subsequentially it loads
On Sun February 5 2006 14:43, Martijn van Oosterhout wrote:
So what you load are the already processed rules? In that case you
could probably use the buffer management system. Ask it to load the
blocks and they'll be in the buffer cache. As long as you have the
buffer pinned they'll stay
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
The *REALM* is not checked, however. This can cause problems if you have
a multi-realm system (where the realms already trust each other, because
the KDC has to give out the service ticket) where you have the same
username existing in multiple
The *REALM* is not checked, however. This can cause problems if you
have a multi-realm system (where the realms already trust
each other,
because the KDC has to give out the service ticket) where
you have the
same username existing in multiple realms representing
different users.
Martijn van Oosterhout kleptog@svana.org writes:
So what you load are the already processed rules? In that case you
could probably use the buffer management system. Ask it to load the
blocks and they'll be in the buffer cache. As long as you have the
buffer pinned they'll stay there.
...
bonjour je suis etudiant en informatique et mon theme de fin d'année se
porte sur les methodes d'indexation des données spatials.
et je compte implementer une methode dans postgresql et je vous serais
reconnaissant de bien vouloir m'attribuer de la doccumentation pour la facon
dont en integre
On Sun February 5 2006 16:16, Tom Lane wrote:
AFAICT the data structures you are worried about don't have any readily
predictable size, which means there is no good way to keep them in
shared memory --- we can't dynamically resize shared memory. So I think
storing the rules in a table and
Greetings,
* Stephen Frost ([EMAIL PROTECTED]) wrote:
I realize it's not entirely fair (given that it was years ago) to ask
this, but, anyone happen to know why the patch wasn't accepted? It
almost patched cleanly against current HEAD even. I went ahead and
made the few changes by
hassane ariouat wrote:
bonjour je suis etudiant en informatique et mon theme de fin d'année
se porte sur les methodes d'indexation des données spatials.
et je compte implementer une methode dans postgresql et je vous
serais reconnaissant de bien vouloir m'attribuer de la doccumentation
pour
Greetings,
* Stephen Frost ([EMAIL PROTECTED]) wrote:
I've now tested this patch at home w/ 8.2HEAD and it seems to fix the
bug. I plan on testing it under 8.1.2 at work tommorow with
mod_auth_krb5, etc, and expect it'll work there. Assuming all goes
well and unless someone objects
James,
I am seeking, as many others are or have, to improve the performance on bulk
loads to live systems where constraint violations may occur and filtering can
be done more efficiently within the backend.
Primarily, I'm concerned with UNIQUE violations. However, I think tackling the
general
Folks,
The subject of this letter is referring to giving INSERT and COPY FROM STDIN
the ability to alter the destination of rows that violate any constraints named
in a user specified set.
BTW, just in case anyone thinks that James is not addressing a real and
widespread problem, Joe Conway
Devrim GUNDUZ wrote:
Hi,
As you know, many databases that run on Linux / Unix systems have a GUI
installer which make installation easier and more attractive for some
people.
Our Windows Installer is very attractive, for example.
Now, I and Burcu Guzel, who is a Senior Programmer,
On Fri, 3 Feb 2006, James William Pye wrote:
Despite the fact that my experimental patch uses error trapping, that is *not*
what I have in mind for the implementation. I do not want to trap errors upon
insert or copy from. Rather, I wish to implement functionality that would
allow
On Sun, Feb 05, 2006 at 02:08:12PM -0800, Stephan Szabo wrote:
Have you considered how this might work with spec-compliant constraint
timing?
I haven't gone so far as to look into the spec, yet. [Noise of rustling papers]
However, constraints referenced in an UNLESS clause that are deferred,
On Sun, 2006-02-05 at 14:03 +, [EMAIL PROTECTED] wrote:
3. Somehow create shared memory using the shmem functions, and set a memory
context to live *inside* this shared memory, which my trigger functions can
then switch to. Then use palloc() and pfree() without worrying..
This has been
Hi!!
I was just browsing the message and saw yours. I have actually written a
shared memory system for PostgreSQL.
I've done some basic bench testing, and it seems to work, but I haven't
given it the big QA push yet.
My company, Mohawk Software, is going to release a bunch of PostgreSQL
On Sun, 5 Feb 2006, James William Pye wrote:
On Sun, Feb 05, 2006 at 02:08:12PM -0800, Stephan Szabo wrote:
Have you considered how this might work with spec-compliant constraint
timing?
I haven't gone so far as to look into the spec, yet. [Noise of rustling
papers]
However,
On Sun February 5 2006 16:16, Tom Lane wrote:
AFAICT the data structures you are worried about don't have any readily
predictable size, which means there is no good way to keep them in
shared memory --- we can't dynamically resize shared memory. So I think
storing the rules in a table and
25 matches
Mail list logo
