> On Mar 7, 2017, at 12:24 PM, Mark Dilger wrote:
>
> Hello,
>
> I am attempting to get the tap tests working under windows so as to
> help review patches for the 10.0 development cycle. I can compile
> the sources on windows 2008 using the MS Visual C and run the
>
workspace/unicorns/postgresql/src/test/perl/PostgresNode.pm
line 1321.
# ''
# doesn't match '(?^:statement: CREATE EXTENSION "plpgsql")'
# Looks like you failed 1 test of 14.
Thanks in advance for any clarification regarding what I might be doing wrong.
Mark Dilger
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
runtime
from 4 minutes down to less than a second.
I have a fairly clean patch in the works that
I will submit after I have verified it on
Windows 2003, Windows 2008 and Linux.
From: Magnus Hagander
To: Mark Dilger
Cc: Tom Lane ; deepak ; Alban Hertroys
were modified to
pass a filter, this code might perform better
on Windows. I'll look into this.
From: Tom Lane
To: Mark Dilger
Cc: deepak ; Alban Hertroys ;
"pgsql-general@postgresql.org"
Sent: Wednesday, May 23, 2012 4:25 PM
Subject: Re: [
/desktop/aa365740%28v=vs.85%29.aspx
From: Tom Lane
To: Mark Dilger
Cc: deepak ; Alban Hertroys ;
"pgsql-general@postgresql.org"
Sent: Wednesday, May 23, 2012 1:54 PM
Subject: Re: [GENERAL] FATAL: lock file "postmaster.pid" already exists
.
From: Tom Lane
To: Mark Dilger
Cc: deepak ; Alban Hertroys ;
"pgsql-general@postgresql.org"
Sent: Wednesday, May 23, 2012 12:23 PM
Subject: Re: [GENERAL] FATAL: lock file "postmaster.pid" already exists
Mark Dilger writes:
> We do not use tablespac
cutting off their feet.
The server is a virtual machine, and at this point
I will ask the sys admins to get a non-virtual
server running to reconfirm the problem.
Thanks
From: Tom Lane
To: Mark Dilger
Cc: deepak ; Alban Hertroys ;
"pgsql-ge
We tried setting the timezone, as:
timezone = 'US/Eastern'
in postgresql.conf, but it did not help.
From: Tom Lane
To: Mark Dilger
Cc: deepak ; Alban Hertroys ;
"pgsql-general@postgresql.org"
Sent: Wednesday, May 23, 2012
recurse further.
After making this change, we have not been able to
reproduce the slowness.
We do not consider this a fix to the problem. It is just
a tool for verifying where the slowness comes from.
From: Tom Lane
To: Mark Dilger
Cc: deepak ; Alban Hertroys
I tried moving the call to RemovePgTempFiles until
after the PID file is fully written, but it did not help.
pg_ctl attempts to connect to the database, and does
not report the database as running until that connection
succeeds. I am not comfortable moving the call to
RemovePgTempFiles after the p
Michael Glaesemann wrote:
Hello, all!
Recently there was quite a bit of discussion regarding surrogate keys
and natural keys. I'm not interested in discussing the pros and cons of
surrogate keys. What I'd like to find out are the different methods
people actually use to uniquely identify c
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
On Tue, Jun 28, 2005 at 07:38:43PM -0700, Mark Dilger wrote:
If, for a given row, the value of c is, say, approximately 2^30 bytes
large, then I would expect it to be divided up into 8K chunks in an
external table, and I sho
bitrarily deep children in a btree type
stored in column "c". It doesn't make sense to have a really wide table to
represent the tree for multiple reasons, mostly involving data duplication in
the leftward columns but also because you can't know ahead of time how wide to
ma
13 matches
Mail list logo
