From the Javadoc of java.sql.Blob byte[] getBytes(long pos, int length)
throws SQLException;
* @param pos the ordinal position of the first byte in the
*codeBLOB/code value to be extracted; the first byte is at
*position 1
pqsql driver assumes the position starts from 0
The attached patch implements new semaphore and shared memory
mechanisms for POSIX systems.
Semaphores are implemented using unnamed pipes. A semaphore is
incremented by writing a single character to the pipe, and decremented
by reading a single character. The only semaphore operation we can't
[EMAIL PROTECTED] (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) writes:
The attached patch implements new semaphore and shared memory
mechanisms for POSIX systems.
I'm afraid we'll have to reject this out of hand:
+bool
+PGSharedMemoryIsInUse(unsigned long id1, unsigned long id2)
+{
+/*
+
PostgreSQL 8.0.3, to be released in a few days, will have a bcc32.mak
that will compile using Borland, and a DLL fix for WSACleanup(). Would
you please test that version?
Thanks.
---
Gabor Berenyi wrote:
Hello Bruce and
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bruce Momjian pgman@candle.pha.pa.us writes:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Neil applied all those some time
On Fri, May 06, 2005 at 11:49:43AM -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
Marko Kreen wrote:
On Fri, May 06, 2005 at 11:49:43AM -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the
Already applied.
---
Marko Kreen wrote:
Here are various updates for pgcrypto that
I've been sitting on for some time now.
They should be applied in order, but otherwise
they stand alone - code should in working state
Tom Lane [EMAIL PROTECTED] writes:
This is not acceptable in the slightest, because it offers no protection
against the situation where the old postmaster has crashed but there are
still live backends. If a new postmaster and new backends are allowed
to start in that situation, using a new
[EMAIL PROTECTED] (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) writes:
You can use file-backed shared memory instead. You need a directory
which you know is writeable and unique to this instance, on a file
system with enough free space to accomodate the full size of the
shared memory segment.
Tom Lane [EMAIL PROTECTED] writes:
The check we need is are there any other processes (still) attached to
this shmem and AFAIK that is not available in the mmap API. Do you
know how to get it?
You can hack something up with fcntl() locks. If a process has a
shared lock on the shm file,
[EMAIL PROTECTED] (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) writes:
Tom Lane [EMAIL PROTECTED] writes:
The check we need is are there any other processes (still) attached to
this shmem and AFAIK that is not available in the mmap API. Do you
know how to get it?
You can hack something up with
On Thu, 5 May 2005, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Applied.
Now that I've had a chance to look at it, this patch is thoroughly
broken. Problems observed in a quick review:
1. It doesn't work at all for non-default tablespaces: it will
claim that every file in such a
Satoshi Nagayasu wrote:
Tom Lane wrote:
I'd view this as a postmaster state that propagates to backends.
Probably you'd enable it by means of a postmaster option, and the
only way to get out of it is to shut down and restart the postmaster
without the option.
I've created a patch to
Bruce Momjian pgman@candle.pha.pa.us writes:
It seems server_read_only is the same as default_transaction_read_only
except it can't be changed.
I thought the TODO item was for a low-level read-only option, suitable
for trying to look at a corrupted database or run off a read-only volume.
This
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
It seems server_read_only is the same as default_transaction_read_only
except it can't be changed.
I thought the TODO item was for a low-level read-only option, suitable
for trying to look at a corrupted database or run off a
Applied.
---
pgman wrote:
Here is an updated version of this patch, with documentation changes.
I have already updated the gram.y comment you suggested.
Hi,
I am accelerating the transfer of resultset
from backend to client using the zlib library.
While coding, I was surprised that
magic number 8192 (which is defined as PQ_BUFFER_SIZE in
backend/libpq/pqcomm.c) are written into the code
in interfaces/libpq/fe-misc.
I thought the magic number
Hideyuki Kawashima [EMAIL PROTECTED] writes:
While coding, I was surprised that
magic number 8192 (which is defined as PQ_BUFFER_SIZE in
backend/libpq/pqcomm.c) are written into the code
in interfaces/libpq/fe-misc.
AFAICS the uses of 8192 in fe-misc.c have no relationship to
Thanks for teaching me about 8192 in fe-misc.c.
I recognized the 8192 in fe-misc.c does not relate to PQ_BUFFER_SIZE
in pqcomm.c, but I am pleased if someone revises the magic number.
And I am sorry for my incorrect format patch.
From next time, I will submit my proposition as diff -c patches.
--
21 matches
Mail list logo
