On 02/08/13 09:47, Mark Kirkwood wrote:
For the archives, looks like that was the issue, users need to be a
member of a certain group (gid 303) to use sockets (which is exactly
what Alvaro suspected).
Make that gid 3003, sorry.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.or
On 01/08/13 22:13, f...@libero.it wrote:
Da: mark.kirkw...@catalyst.net.nz
See http://android-dls.com/wiki/index.php?title=Debian_on_G1 near the
bottom they discuss this issue.
Cheers
Mark
Thanks very very much: problem solved, postgresql, apache2, php5 ported on a
50$
small android table w
On 01/08/13 09:13, f...@libero.it wrote:
problem:
LOG: could not create IPv6 socket: Permission denied
LOG: could not create IPv4 socket: Permission denied
WARNING: could not create listen socket for "localhost"
FATAL: could not create any TCP/IP sockets
See http://android-dls.com/
f...@libero.it wrote:
> problem:
> I have build from source posgresql (8.4) on a android table whith a minimal
> linux debian installed."configure" process and "make" (compiling source) and
> "make install": all are OK!!
> Also initdb works fine (/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/da
Dear Postgres Gurus
>
> Has there been any luck with this strange Postgres on OpenVZ edge case?
> We're also getting the 'could not read block' error.
>
> Warwick
>
On Monday, July 22, 2013, Warwick Chapman wrote:
>
>> Антон
>>
>> Did you manage to make any progress with OpenVZ and PostgreSQL on
On 5/16/2013 2:14 AM, weiwei wrote:
Postgresql 9.12 support cluster mode? Equivalent of main spare automatic switching
there's no such thing as PostgreSQL 9.12, there's 9.1 of which the
current build is 9.1.9, and there's 9.2 which is currently 9.2.4.
You can build a active/standby failover
On 12/4/2012 1:38 AM, Duggirala, Manikanth (TCS) wrote:
Can you please let us know if PostgreSQL v8.1.11 is compatible with OS
2008 R2 ?
8.1.anything shouldn't be installed today, its an obsolete deprecated
version.
that said, IIRC, there were major issues with versions prior to 8.3 on
This is not a bug report. Please post any future questions to a
more appropriate list:
http://www.postgresql.org/community/lists/
Duggirala, Manikanth (TCS) wrote:
> Can you please let us know if PostgreSQL v8.1.11 is compatible
> with OS 2008 R2 ?
No, it's not.
Problems with PostgreSQL versio
On 08/30/2012 12:08 AM, lacm...@sapo.pt wrote:
Does someone know what this could be?
Also, this is *clearly* not a PostgreSQL bug, just to make that
explicit. It's an issue in:
- most likely your code or build systems; or
- pgdac
- C++builder
- a compatibility issue between the two
- someth
On 08/30/2012 12:08 AM, lacm...@sapo.pt wrote:
Hi,
I am working with c++ Builder 2007, and try to work also with PostGreSQL.
Is that Borland/Embarcadero C++ builder?
If so, I have to ask: *why*?
I have downloaded the following exe,
http://www.devart.com/pgdac/pgdac11.exe
Which is http://w
On Thu, Aug 2, 2012 at 6:34 AM, raf wrote:
> Tom Lane wrote:
>
> > raf writes:
> > > i've just upgraded to 9.1.4 on macosx-10.6.8 and psql crashes
> > > whenever the -h option is used (either with "localhost" or any
> > > other hostname). i only have hostssl connections.
> >
> > > attached is a
Tom Lane wrote:
> raf writes:
> > i've just upgraded to 9.1.4 on macosx-10.6.8 and psql crashes
> > whenever the -h option is used (either with "localhost" or any
> > other hostname). i only have hostssl connections.
>
> > attached is a macosx crash report in case it helps.
>
> [ squint ... ]
raf writes:
> i've just upgraded to 9.1.4 on macosx-10.6.8 and psql crashes
> whenever the -h option is used (either with "localhost" or any
> other hostname). i only have hostssl connections.
> attached is a macosx crash report in case it helps.
[ squint ... ] There's something awfully fishy a
On Tue, Jun 12, 2012 at 05:10:19PM +1200, Edmund Horner wrote:
> On 26 May 2012 01:10, Bruce Momjian wrote:
> > Ah, turns out I only need one extra log file on Windows, not two,
> > because I can reuse the utility file for pg_ctl stop. The original
> > beta1 code usesd the utility file for pg_ctl
On 26 May 2012 01:10, Bruce Momjian wrote:
> Ah, turns out I only need one extra log file on Windows, not two,
> because I can reuse the utility file for pg_ctl stop. The original
> beta1 code usesd the utility file for pg_ctl stop and start, which is
> what caused the problem.
>
> Applied patch
On Thu, May 24, 2012 at 08:34:01PM -0400, Bruce Momjian wrote:
> On Fri, May 25, 2012 at 11:48:53AM +1200, Edmund Horner wrote:
> > It still fails (when run in verbose mode):
> >
> > Creating catalog dump
> > ""c:\ehorner\pgsql\bin/pg_dumpall" --port 50432 --username "ehorner"
> > --schema-onl
On Fri, May 25, 2012 at 11:48:53AM +1200, Edmund Horner wrote:
> It still fails (when run in verbose mode):
>
> Creating catalog dump
> ""c:\ehorner\pgsql\bin/pg_dumpall" --port 50432 --username "ehorner"
> --schema-only --binary-upgrade --verbose > "pg_upgrade_dump_all.sql"
> 2>> "pg_upgrade_
On 25 May 2012 11:48, Edmund Horner wrote:
> It still fails (when run in verbose mode):
Sorry, let me correct that to:
It still fails, regardless of verbose mode. And, in verbose mode, the
output is...
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your sub
On 25 May 2012 01:59, Bruce Momjian wrote:
> On Thu, May 24, 2012 at 03:42:25PM +0200, Magnus Hagander wrote:
>> I've built a new one off git master + Bruce's patch. You can get it
>> from http://www.hagander.net/tmp/pg_upgrade.zip - please see if that
>> one works for you.
>
> Thanks, but thinkin
On Thu, May 24, 2012 at 03:42:25PM +0200, Magnus Hagander wrote:
> On Thu, May 24, 2012 at 2:40 AM, Edmund Horner wrote:
> > On 24 May 2012 12:33, Bruce Momjian wrote:
> >> I have applied the attached patch which should fix the problem. How
> >> can we get Edmund a copy of a new binary for test
On Thu, May 24, 2012 at 2:40 AM, Edmund Horner wrote:
> On 24 May 2012 12:33, Bruce Momjian wrote:
>> I have applied the attached patch which should fix the problem. How
>> can we get Edmund a copy of a new binary for testing? Does he have to
>> wait for beta2?
>
> My uneducated guess is that
On 24 May 2012 12:33, Bruce Momjian wrote:
> I have applied the attached patch which should fix the problem. How
> can we get Edmund a copy of a new binary for testing? Does he have to
> wait for beta2?
My uneducated guess is that your patch will fix the problem.
But I don't think I'm up to c
On Wed, May 23, 2012 at 03:20:30PM +0200, Magnus Hagander wrote:
> On Wed, May 23, 2012 at 5:50 AM, Edmund Horner wrote:
> > On 22 May 2012 18:49, Craig Ringer wrote:
> >> When you shut down the 9.1.3 cluster did you make absolutely certain there
> >> were no postgres.exe processes lurking around
On Wed, May 23, 2012 at 5:50 AM, Edmund Horner wrote:
> On 22 May 2012 18:49, Craig Ringer wrote:
>> When you shut down the 9.1.3 cluster did you make absolutely certain there
>> were no postgres.exe processes lurking around when you tested? Given the
>> incredible thouroughness of your report I
On 22 May 2012 18:49, Craig Ringer wrote:
> When you shut down the 9.1.3 cluster did you make absolutely certain there
> were no postgres.exe processes lurking around when you tested? Given the
> incredible thouroughness of your report I imagine you did, but it's worth
> checking, as a lingering `
First: Best. Bug. Report. Ever.
Comments inline, though I don't know enough about the Windows side to
help much.
Checking for contrib/isn with bigint-passing mismatch ok
Creating catalog dump The
process cannot access the file because it i
On 05/22/2012 06:28 AM, Edmund Horner wrote:
Hum. My first email sent to this list a few days ago still has not
arrived, so these two are kind of orphaned. Should I resend it?
You mean:
"Just a note that pg_upgrade on Windows 7 64-bit did not have this
error. However, it was a different dat
Hum. My first email sent to this list a few days ago still has not
arrived, so these two are kind of orphaned. Should I resend it?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 18 May 2012 23:06, Edmund Horner wrote:
> I ran into a bit of trouble running pg_upgrade to upgrade from my
> 9.1.3 cluster. This is the first time I have run pg_upgrade. It is
> entirely possible I've done something wrong.
>
> As a control, I was able to successfully "upgrade" the Postgresq
Christopher Browne wrote:
> Nie, Guocong wrote:
>> Could you please let me know how can I replicate database from
>> Linux to Windows ?
>
> The built-in replication requires that you are using the same
> version of PostgreSQL on the same OS platform. That doesn't seem
> to be documented as cl
On Mon, Mar 12, 2012 at 5:31 AM, Nie, Guocong wrote:
> Hi Team,
>
> I am doing postgresql 9.1 replication , the Master database is on GNU/Linux
> operation system , the Slave database is on Windows 32 bit system. But
> when I copy the Master database from Linux to Windows , then I am unlucky to
Hi,
On Friday, December 16, 2011 01:50:03 PM Havasvölgyi Ottó wrote:
> A simple query "insert into mytable default values" on a single
> serial-column table also leaks. It can also produced by pgbench. On
> Windows and Linux too.
Youve mentioned that in several threads now. If you really think th
Hi,
A simple query "insert into mytable default values" on a single
serial-column table also leaks. It can also produced by pgbench. On
Windows and Linux too.
Best regards,
Otto
2011/12/12 Jochen Erwied
> Monday, December 12, 2011, 12:33:03 PM you wrote:
>
> > On 12.12.2011 13:16, Matteo Bec
Monday, December 12, 2011, 12:33:03 PM you wrote:
> On 12.12.2011 13:16, Matteo Beccati wrote:
>> Just to clarify, am I correct assuming that the issue does not affect
>> tables which have non-indexed inet fields?
> Hmm, I think it might also affect queries that do large merge joins on
> inet f
On 12.12.2011 13:16, Matteo Beccati wrote:
On 12/12/2011 09:29, Heikki Linnakangas wrote:
On 12.12.2011 08:26, Tom Lane wrote:
Andres Freund writes:
In 3b8161723c645853021b57330dd2ea0484ec6131 Heikki made DatumGetInetP
unpack
toasted values. Unfortunately the btree support functions for the
Hi Heikki,
On 12/12/2011 09:29, Heikki Linnakangas wrote:
> On 12.12.2011 08:26, Tom Lane wrote:
>> Andres Freund writes:
>>> In 3b8161723c645853021b57330dd2ea0484ec6131 Heikki made DatumGetInetP
>>> unpack
>>> toasted values. Unfortunately the btree support functions for the
>>> inet type
>>> di
On 12.12.2011 08:26, Tom Lane wrote:
Andres Freund writes:
In 3b8161723c645853021b57330dd2ea0484ec6131 Heikki made DatumGetInetP unpack
toasted values. Unfortunately the btree support functions for the inet type
didn't free memory which they have to do in contrast to about everything else.
I
Monday, December 12, 2011, 1:45:42 AM you wrote:
> Jochen, could you try the attached patch?
Patch is missing a variable define for 'r' in network_sup(). Fixed patch
attached.
Memory usage for insert ~1087MB - no change
Memory usage for index creation ~415MB - fixed.
Memory usage for select ~15
Andres Freund writes:
> In 3b8161723c645853021b57330dd2ea0484ec6131 Heikki made DatumGetInetP unpack
> toasted values. Unfortunately the btree support functions for the inet type
> didn't free memory which they have to do in contrast to about everything else.
> I fixed a few more functions than
Hi,
On Monday, December 12, 2011 12:45:23 AM Andres Freund wrote:
> On Sunday, December 11, 2011 10:15:29 PM Jochen Erwied wrote:
> > The following script can be used to show the behaviour:
> >
> > create database pgtest;
> > \c pgtest
> > create table test(var inet);
> > insert into test(var) '1
Hi,
On Sunday, December 11, 2011 10:15:29 PM Jochen Erwied wrote:
> The following script can be used to show the behaviour:
>
> create database pgtest;
> \c pgtest
> create table test(var inet);
> insert into test(var) '127.0.0.0'::inet+generate_series(0,256*256*256-1);
> create index test_ix on
On 30/08/2011 9:18 PM, Jan Snelders wrote:
The program now selects and prints the records from the SELECT
transaction. (0 records printed, we expected one record since we are
still within the SELECT transaction which started while this record was
still available)
This isn't a bug. You're using
Jan Snelders wrote:
> I wrote small java program which performs some selects in one
> transaction (and thread) and one delete in another transaction and
> thread on the same table holding one record initially.
> The DELETE transaction commits.
> The program now selects and
> prints the record
On 3/08/2011 12:11 AM, Kevin Grittner wrote:
Glonet NV / Mathieu Aras wrote:
Can we install PostgreSQL 8.4 on a server 2008? Is it X64 and X32
compatible?
This is not a bug. A more appropriate list for this question would
have been pgsql-general.
I'm not sure what "server 2008" is, but if
Glonet NV / Mathieu Aras wrote:
> Can we install PostgreSQL 8.4 on a server 2008? Is it X64 and X32
> compatible?
This is not a bug. A more appropriate list for this question would
have been pgsql-general.
I'm not sure what "server 2008" is, but if it's some form of
Windows, version 8.4 sh
On Thu, Jul 7, 2011 at 7:51 PM, kmx wrote:
> couple of weeks (maybe months) ago postgresql introduced support for
> mingw-w64 compiler on
> MS Windows platform; however the related patch was based on assumption that
> mingw-w64 project delivers just 64bit compiler (which is not true - they
> deli
Gary Wong writes:
> [Environment under in the postgres account]
> $ env
> LC_MONETARY=en_US.ISO8859-15
> LC_TIME=en_US.ISO8859-15
> LC_MESSAGES=C
> LC_CTYPE=en_US.ISO8859-1
> LC_COLLATE=en_US.ISO8859-15
> LC_NUMERIC=en_US.ISO8859-15
> [Message I get when I run initdb]
> $ initdb -D /usr/local/pgs
On Wed, May 25, 2011 at 9:06 AM, Merlin Moncure wrote:
> On Wed, May 25, 2011 at 7:37 AM, Craig Ringer
> wrote:
>> On 05/24/2011 07:05 PM, Paragon Corporation wrote:
>>>
>>> In regression testing PostGIS 2.0, our topology module regression tests
>>> are
>>> failing in PostgreSQL 9.1 beta.
>>>
>>>
On Wed, May 25, 2011 at 7:37 AM, Craig Ringer
wrote:
> On 05/24/2011 07:05 PM, Paragon Corporation wrote:
>>
>> In regression testing PostGIS 2.0, our topology module regression tests
>> are
>> failing in PostgreSQL 9.1 beta.
>>
>> We have a PostGIS ticket open for it here, but we suspect it's a
>
On 05/24/2011 07:05 PM, Paragon Corporation wrote:
In regression testing PostGIS 2.0, our topology module regression tests are
failing in PostgreSQL 9.1 beta.
We have a PostGIS ticket open for it here, but we suspect it's a PostgreSQL
9.1 bug and would like to close it out.
Do you think you mi
Arnd Hannemann writes:
> if pg_restore is used with -jN it fails if the dump has comments on indices.
Reproduced here, thanks for the report!
> The problem seems to be a false assumption in pg_backup_archiver.c:
> ...
> Comments are in SECTION_NONE so they get restored here regardless of
> depe
Hello Mohammed,
Mohammed Rashad [2010-11-29 20:50 +0530]:
> I reinstalled the postgresql and got this error
> * Starting PostgreSQL 8.4 database server
>* Insecure directory in $ENV{PATH} while running with -T switch at
> /usr/bin/pg_ctlcluster line 63.
This is not an upstream bug at all. Ca
I reinstalled the postgresql and got this error
* Starting PostgreSQL 8.4 database server
* Insecure directory in $ENV{PATH} while running with -T switch at
/usr/bin/pg_ctlcluster line 63.
On Mon, Nov 29, 2010 at 8:43 PM, Kevin Grittner wrote:
> Mohammed Rashad wrote:
>
> > I am getting th
Mohammed Rashad wrote:
> I am getting this error
>
> * Starting PostgreSQL 8.4 database server
> * Error: could not exec
> /usr/lib/postgresql/8.4/bin/pg_ctl
> /usr/lib/postgresql/8.4/bin/pg_ctl start -D
> /var/lib/postgresql/8.4/main -l
> /var/log/postg
Excerpts from TamilSelvam M's message of jue sep 23 02:08:05 -0400 2010:
> creating template1 database in /usr/local/data/base/1 ... FATAL: only sys
> attr supported in caches is OID
> PANIC: cannot abort transaction 1, it was already committed
> child process was terminated by signal 6: Aborte
TamilSelvam M writes:
> im trying to install postgresql8.4 in P2020 board .
> when i try to start postgresql im facing the follwing error.
> creating template1 database in /usr/local/data/base/1 ... FATAL: only sys
> attr supported in caches is OID
Offhand I'd guess you have a compiler bug to
On 4/07/2010 3:00 PM, pritesh modi wrote:
*
Unpacking postgresql-common (from .../postgresql-common_90_all.deb) ...
Setting up postgresql-common (90) ...
supported_versions: WARNING: Unknown Ubuntu release: 8.10*
This is not a PostgreSQL bug. It's looks like a problem with the
packages yo
On 04/07/10 01:04, pritesh modi wrote:
> Hello
>
> i am not understanding regarding this bug what s problem with that its not
> allowed to start the postgresql successfully what is a problem that coud not
> easily find out
Please provide error messages reported on the console, any information
fr
* Thom Brown (thombr...@gmail.com) wrote:
> psql -U postgres -d test -c "select tablename,
> pg_size_pretty(pg_table_size(tablename::regclass)) from pg_tables
> where schemaname = 'public' order by tablename;"
>
> And this, for some reason, works... which is how I did it the other
> day (hence why
On 27 May 2010 23:00, Tom Lane wrote:
> Thom Brown writes:
>> This probably isn't a legitimate bug, but as a precaution
>> I'm running the following command against PostgreSQL 9.0 beta 1:
>
>> psql -U postgres -d test -c "select tablename,
>> pg_size_pretty(pg_table_size(tablename::regclass))
Thom Brown writes:
> This probably isn't a legitimate bug, but as a precaution
> I'm running the following command against PostgreSQL 9.0 beta 1:
> psql -U postgres -d test -c "select tablename,
> pg_size_pretty(pg_table_size(tablename::regclass)) from pg_tables
> order by tablename;"
> And
On tor, 2010-05-27 at 22:41 +0100, Thom Brown wrote:
> This probably isn't a legitimate bug, but as a precaution
>
> I'm running the following command against PostgreSQL 9.0 beta 1:
>
> psql -U postgres -d test -c "select tablename,
> pg_size_pretty(pg_table_size(tablename::regclass)) from pg
On 03/05/10 01:30, Tom Lane wrote:
> Russell Smith writes:
>
>> On 02/05/10 01:36, Tom Lane wrote:
>>
>>> No, that's the intended place for them given the current division of
>>> labor between pg_dump and pg_dumpall. There have been complaints before
>>> about this, but no one has propose
Russell Smith writes:
> On 02/05/10 01:36, Tom Lane wrote:
>> No, that's the intended place for them given the current division of
>> labor between pg_dump and pg_dumpall. There have been complaints before
>> about this, but no one has proposed a better approach (where better
>> means "fixes this
On 02/05/10 01:36, Tom Lane wrote:
> Russell Smith writes:
>
>> Is this considered a bug that the only way to do a dump/restore with
>> database privileges is to use pg_dumpall?
>>
> No, that's the intended place for them given the current division of
> labor between pg_dump and pg_dumpall
Russell Smith writes:
> Is this considered a bug that the only way to do a dump/restore with
> database privileges is to use pg_dumpall?
No, that's the intended place for them given the current division of
labor between pg_dump and pg_dumpall. There have been complaints before
about this, but no
Holger Rauch writes:
> So, my question is: Why does the configure script not include these
> checks on Linux systems (for the bsd/string.h file and libbsd)?
Well, there are several reasons:
1. I don't think we really care that much --- the src/port/
implementations of those functions work fine,
On Thu, Mar 11, 2010 at 8:50 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Fri, Mar 5, 2010 at 8:09 AM, Tom Lane wrote:
>
>> > What I'd be for is breaking the docs out as a separate top-level target,
>> > ie "make docs", "make install-docs". I don't much care for Lou's
>> > suggestion
Robert Haas escribió:
> On Fri, Mar 5, 2010 at 8:09 AM, Tom Lane wrote:
> > What I'd be for is breaking the docs out as a separate top-level target,
> > ie "make docs", "make install-docs". I don't much care for Lou's
> > suggestion of tying it to a configure option because that imposes the
> >
On Fri, Mar 5, 2010 at 9:21 AM, Peter Eisentraut wrote:
> By splitting out the doc building into a separate target, we will have
> less users installing the documentation.
I don't see why. And even if it's true, it just means some people
were installing the docs "by accident" before even though
On Fri, Mar 5, 2010 at 8:09 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On tor, 2010-03-04 at 17:53 +, Lou Picciano wrote:
>>> ./configure --no-docs or ./configure --with-htmldocs-only
>
>> But that would be a negative regression for end users, who we want to
>> have the docs availabl
On fre, 2010-03-05 at 08:09 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On tor, 2010-03-04 at 17:53 +, Lou Picciano wrote:
> >> ./configure --no-docs or ./configure --with-htmldocs-only
>
> > But that would be a negative regression for end users, who we want to
> > have the docs
obert Haas"
, "Joe Conway" ,
pgsql-bugs@postgresql.org
Sent: Friday, March 5, 2010 8:09:54 AM GMT -05:00 US/Canada Eastern
Subject: Re: [BUGS] PostgreSQL-9.0alpha: jade required?
Peter Eisentraut writes:
> On tor, 2010-03-04 at 17:53 +, Lou Picciano wrote:
>> ./confi
Peter Eisentraut writes:
> On tor, 2010-03-04 at 17:53 +, Lou Picciano wrote:
>> ./configure --no-docs or ./configure --with-htmldocs-only
> But that would be a negative regression for end users, who we want to
> have the docs available by default, so they can read them.
"End users" in th
On tor, 2010-03-04 at 17:53 +, Lou Picciano wrote:
> While I'd agree a 'make all' should, uh... make _all_, and that make
> building based on lots of guessing is counterintuitive, an option to
> configure like:
>
> ./configure --no-docs or ./configure --with-htmldocs-only
>
> - with som
On tor, 2010-03-04 at 12:09 -0500, Robert Haas wrote:
> I think that the whole idea of make targets building different things
> depending on what you've built previously is confusing,
> counterintuitive, and illogical. make all should either build the
> docs, or not; trying to guess what the user
riginal Message -
From: "Robert Haas"
To: "Peter Eisentraut"
Cc: "Tom Lane" , "Joe Conway" , "Lou
Picciano" , pgsql-bugs@postgresql.org
Sent: Thursday, March 4, 2010 12:09:00 PM GMT -05:00 US/Canada Eastern
Subject: Re: [BUGS] PostgreSQL
On Thu, Mar 4, 2010 at 9:15 AM, Peter Eisentraut wrote:
> On ons, 2010-02-24 at 12:16 -0500, Tom Lane wrote:
>> Joe Conway writes:
>> > Related to this I have noticed in recent weeks on my own development
>> > machine that "make install" takes *much* longer, but only sporadically,
>> > due to the
On ons, 2010-02-24 at 12:16 -0500, Tom Lane wrote:
> Joe Conway writes:
> > Related to this I have noticed in recent weeks on my own development
> > machine that "make install" takes *much* longer, but only sporadically,
> > due to the docs building.
>
> This might be related to Peter's changes t
Lou Picciano writes:
> Now, you've reminded me of something: That one or more versions of tar have
> trouble with very long file/directory names
> I've run into this with one of the source trees we've been working in - was
> it here in PostgreSQL? Could this be a culprit?
I believe we dealt w
From: "Joseph Conway"
To: "Tom Lane"
Cc: "Peter Eisentraut" , "Lou Picciano"
, pgsql-bugs@postgresql.org, bsde...@gmail.com
Sent: Friday, February 26, 2010 12:29:43 AM GMT -05:00 US/Canada Eastern
Subject: Re: [BUGS] PostgreSQL-9.0alpha: jade required?
Tom Lane wrote:
> I wrote:
>> * $(GENERATED_SGML) is removed by make clean, therefore also by
>> make distclean
>> Ergo, this type of failure is *guaranteed* when trying to build
>> from a distribution tarball. This needs to be rethought.
>
> I looked at this some more, and this time I noticed th
I wrote:
> * $(GENERATED_SGML) is removed by make clean, therefore also by
> make distclean
> Ergo, this type of failure is *guaranteed* when trying to build
> from a distribution tarball. This needs to be rethought.
I looked at this some more, and this time I noticed that the makefile
has
.SECO
I wrote:
> That doesn't in itself explain a problem with building from the
> alpha tarball though. Is it possible there's a clock skew problem
> in the tarball's file timestamps?
I poked around in the alpha4 tarball and didn't find clock skew.
What I found out was that there's some fundamental fu
Joe Conway writes:
> Related to this I have noticed in recent weeks on my own development
> machine that "make install" takes *much* longer, but only sporadically,
> due to the docs building.
This might be related to Peter's changes to the docs build procedure.
The way things work now is that if
On 02/24/2010 08:43 AM, Lou Picciano wrote:
> Tom -
>
> Didn't realize I was arm waving - was I? (Sometimes email falls well
> short...)
>
> We've managed a build of PostgreSQL 9.0-alpha4 - nice! However, the #
> make install command apparently(?) hiccups
> on a dependency on Jade (we ain't u
rol over docs build in the
config script - specific kinds of docs/no docs at all/etc?
Thanks for any help, and for the great work! We love PostgreSQL!
Lou
- Original Message -
From: "Tom Lane"
To: "Lou Picciano"
Cc: pgsql-bugs@postgresql.org
Sent: Wednesda
Lou Picciano writes:
> Not sure it's exactly a bug, but in attempting a compile of
> PostgreSQL-9.0alpha, we are getting a choke on jade (don't have jade on this
> system)
> Can the config script test for jade or, better yet, allow an option to turn
> off build of documentation?
Would you sh
sergio dominguez writes:
> I started to work with postgresql but i find that all the relations I create
> disappear when I quit (\q) from the interactive terminal or after load a sql
> file.
It's difficult to say for sure when you haven't showed us exactly what
you did, but one possibility is tha
sergio dominguez escreveu:
> I started to work with postgresql but i find that all the relations I
> create disappear when I quit (\q)
>
This is not a bug. I bet your tables are loaded into a schema that is not in
the search_path.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Nov 09, 2009 at 10:28:51PM +0100, Tim van Loon wrote:
>
> hello,
>
> I have problems with installing postgresql 8.3
t would be helpful if you provided some more details. As it is, you
leave it to our crystal ball to come up with things as "w
Dear Tom,
Thanks for this, and sorry for not replying earlier. We finally obtained
a window to deploy this patch on the real (rather busy!) production
system as of last Saturday evening.
The good news is that the patch has now been in place for 5 days, and,
despite some very high loading, it
Richard Neill writes:
> The good news is that the patch has now been in place for 5 days, and,
> despite some very high loading, it has survived without a single crash.
> I'd venture to say that this issue is now fixed.
Great, thanks for the followup.
regards, tom lane
I wrote:
> Interestingly, the bug can no longer be reproduced in CVS HEAD, because
> pg_database no longer has a trigger. We had better fix it anyway of
> course, since future hash collisions are unpredictable. I'm wondering
> though whether to bother back-patching further than 8.4. Thoughts?
I
I wrote:
> I'll get you a real fix as soon as I can, but might not be till
> tomorrow.
The attached patch (against 8.4.x) fixes the problem as far as I can
tell. Please test.
regards, tom lane
Index: src/backend/utils/cache/relcache.c
Heikki Linnakangas writes:
> Tom Lane wrote:
>> 2. By chance, a shared-cache-inval flush comes through while it's doing
>> that, causing all non-open, non-nailed relcache entries to be discarded.
>> Including, in particular, the one that is "next" according to the
>> hash_seq_search's status.
> I
Tom Lane wrote:
> 2. By chance, a shared-cache-inval flush comes through while it's doing
> that, causing all non-open, non-nailed relcache entries to be discarded.
> Including, in particular, the one that is "next" according to the
> hash_seq_search's status.
I thought we have catchup interrupts
Tom Lane said:
> "Michael Brown" writes:
>> I have put in place a temporary workaround on the production system,
>> which is to insert a
>
>> // Pretend that the cache is always invalid
>> fprintf ( stderr, "*** bypassing cache ***\n" );
>> goto read_failed;
>
> I don't think this w
Tom Lane said:
> I shall go and do some further investigation, but at least it's now
> clear where to look. Thanks for the report, and for being so helpful in
> providing information!
Thank you!
I have put in place a temporary workaround on the production system, which
is to insert a
//
I wrote:
> But: the question at this point is why we've never seen such a report
> before 8.4. If this theory is correct, it's been broken for a *long*
> time. I can think of a couple of possible explanations:
> A: the problem can only manifest if this loop has work to do for
> a relcache entry
1 - 100 of 379 matches
Mail list logo
