So what options does that leave all of us who need to compile and run
our custom C functions in Windows?
On Sun, May 4, 2008 at 4:47 PM, Craig Ringer
<[EMAIL PROTECTED]> wrote:
> Magnus Hagander wrote:
>
>
> > Dan "Heron" Myers wrote:
> >
>
>
> >
> > > I read somewhere on Postgres' website that th
Scott Ribe <[EMAIL PROTECTED]> writes:
>> Possibly you got bit by the recently-fixed LISTEN/NOTIFY race condition?
>> http://archives.postgresql.org/pgsql-bugs/2008-03/msg00094.php
>> IIRC this could only be a problem if your listener had only just started
>> listening, though.
> - Geez, I realize
> Possibly you got bit by the recently-fixed LISTEN/NOTIFY race condition?
> http://archives.postgresql.org/pgsql-bugs/2008-03/msg00094.php
> IIRC this could only be a problem if your listener had only just started
> listening, though.
- Geez, I realize I forget to state the version I'm using: 3.1
On Sun, May 4, 2008 at 5:11 PM, Hans Zaunere <[EMAIL PROTECTED]> wrote:
> Hello,
>
> We're using a statement like this to dump between 500K and >5 million rows.
>
> COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn > '0')
> TO '/dev/shm/SomeFile.csv'
>
> Upon first run, this operation can tak
Scott Ribe <[EMAIL PROTECTED]> writes:
> Uhm, yeah? 2 changes committed, 1 notice sent, 1 change visible on receipt
> of notice.
Possibly you got bit by the recently-fixed LISTEN/NOTIFY race condition?
http://archives.postgresql.org/pgsql-bugs/2008-03/msg00094.php
IIRC this could only be a problem
Table foo has a trigger that on insert raises a notice.
Process A listens for that notice, and blocks on the socket (using kqueue).
Process B commits an insert of a row into that table, then commits an insert
of another row immediately.
Process A wakes up and reads the notice, queries table foo
"Hans Zaunere" <[EMAIL PROTECTED]> writes:
> We're using a statement like this to dump between 500K and >5 million rows.
> COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn > '0')
> TO '/dev/shm/SomeFile.csv'
> Upon first run, this operation can take several minutes. Upon second run,
> it wil
Hello,
We're using a statement like this to dump between 500K and >5 million rows.
COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn > '0')
TO '/dev/shm/SomeFile.csv'
Upon first run, this operation can take several minutes. Upon second run,
it will be complete in generally well under a minut
On Sat, 3 May 2008, Bruno Wolff III wrote:
The suggestion is that fsync isn't really safe on Linux as it is currently
implented.
The issue of needing to turn off underlying disk write caches under Linux
is documented:
http://www.postgresql.org/docs/8.3/interactive/wal-reliability.html
As f
Magnus Hagander wrote:
Dan "Heron" Myers wrote:
I read somewhere on Postgres' website that the win32 binaries were
built with MinGW - and in fact they must be, since MSVC++ does not
have some of the unix headers needed to build Postgres.
No, as of 8.3 they are build with MSVC.
In case it's
Dan "Heron" Myers wrote:
Craig Ringer wrote:
> Can you send me a complete, compileable example that illustrates the
> problem, along with instructions on how to reproduce it? If possible,
> send a compiled binary and any dependencies too. I'm curious to see if
> this is in fact shared library
Dan "Heron" Myers wrote:
> Craig Ringer wrote:
> > Can you send me a complete, compileable example that illustrates
> > the problem, along with instructions on how to reproduce it? If
> > possible, send a compiled binary and any dependencies too. I'm
> > curious to see if this is in fact shared
On May 3, 2008, at 9:29 PM, Patrick TJ McPhee wrote:
How about something along the lines of
BEGIN;
ALTER TABLE log RENAME to log_old;
CREATE TABLE log(...);
COMMIT;
BEGIN;
LOCK table log_old;
COPY log_old TO 'filename-path';
DROP TABLE log_old;
COMMIT;
I believe this will keep the writers writ
Craig Ringer wrote:
> Can you send me a complete, compileable example that illustrates the
> problem, along with instructions on how to reproduce it? If possible,
> send a compiled binary and any dependencies too. I'm curious to see if
> this is in fact shared library issues.
I'll send you a .zip
Nathan Thatcher wrote:
First off, I am developing custom c functions for PostgreSQL 8.3 in
Windows (sorry... not my choice). It appears that there is some
underlying problem in the server that is causing a runtime error to
crash the server when I use palloc. For example... I run the
following:
Nathan Thatcher wrote:
First off, I am developing custom c functions for PostgreSQL 8.3 in
Windows (sorry... not my choice). It appears that there is some
underlying problem in the server that is causing a runtime error to
crash the server when I use palloc.
[Assuming you're using the stock 8.3
Roberts, Jon wrote:
Greenplum has it. Maybe they are planning on adding it to Bizgres or
PostgreSQL.
Sadly Bizgres seems kinda stalled. Latest news is from 2006.06.09. I
doubt GP is still maintaining it at all..
--
Best regards,
Hannes Dorbath
--
Sent via pgsql-general mailing list (pgsql
Patrick TJ McPhee wrote:
How about something along the lines of
BEGIN;
ALTER TABLE log RENAME to log_old;
CREATE TABLE log(...);
COMMIT;
BEGIN;
LOCK table log_old;
COPY log_old TO 'filename-path';
DROP TABLE log_old;
COMMIT;
I believe this will keep the writers writing while keeping the effic
Greenplum has it. Maybe they are planning on adding it to Bizgres or
PostgreSQL.
Jon
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-general-
> [EMAIL PROTECTED] On Behalf Of Hannes Dorbath
> Sent: Sunday, May 04, 2008 8:02 AM
> To: pgsql-general@postgresql.org
> Subject: [
What is the state of SQL window functions in PostgreSQL? rank(),
dense_rank() over() etc?
Is there work done or planed to add those to PostgreSQL? Is there
experimental code?
--
Best regards,
Hannes Dorbath
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
On Fri, May 02, 2008 at 09:34:31AM -0600, Nathan Thatcher wrote:
> Other people have said that pg_detoast_datum is a backend function and
> shouldn't be referenced at all, but it is right there in fmgr.h which
> is obviously required for creating functions under the V1 calling
> convention.
You us
On Fri, May 02, 2008 at 11:06:15PM +0200, Andreas 'ads' Scherbaum wrote:
> > (I confess I am a little astonished that the most recent stable
> > release ended up with 7.4. I thought that at _least_ 8.0 was out
> > prior to freeze. What happened?)
>
> It was, i think ... but after feature freeze
First off, I am developing custom c functions for PostgreSQL 8.3 in
Windows (sorry... not my choice). It appears that there is some
underlying problem in the server that is causing a runtime error to
crash the server when I use palloc. For example... I run the
following:
PG_FUNCTION_INFO_V1(add_on
In article <[EMAIL PROTECTED]>, Tom Lane <[EMAIL PROTECTED]> wrote:
% If you can't tolerate locking out writers for that long, you won't
% be able to use TRUNCATE. The operation I think you were imagining is
%
% BEGIN;
% SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
% COPY log TO 'filename-path'
24 matches
Mail list logo
