Robert Haas writes:
> On Mon, Aug 27, 2012 at 9:58 AM, Bruce Momjian wrote:
>> From Tom Lane in the above thread:
>>> Hmm. I can see how that would happen if you're using one of the Windows
>>> environments wherein malloc's done inside libpq have to be free'd inside
>>> libpq. (The PQExpBuffer
On Mon, Aug 27, 2012 at 9:58 AM, Bruce Momjian wrote:
> On Tue, Jan 17, 2012 at 04:46:50PM -0500, David Schnur wrote:
>> I finally had time to test this further on a variety of systems, and was
>> unable
>> to reproduce on any non-Windows platform. The dump even works fine on
>> Windows
>> XP;
On Tue, Jan 17, 2012 at 04:46:50PM -0500, David Schnur wrote:
> I finally had time to test this further on a variety of systems, and was
> unable
> to reproduce on any non-Windows platform. The dump even works fine on Windows
> XP; just not Windows 7.
>
> This prompted me to do a little more res
I finally had time to test this further on a variety of systems, and was
unable to reproduce on any non-Windows platform. The dump even works fine
on Windows XP; just not Windows 7.
This prompted me to do a little more research, and this time I found this
thread from Sept. 2011:
http://postgresq
David Schnur writes:
> I probably can't get a stack trace, but I was able to reproduce it with
> just that function. Without the function, pg_dump works fine. I can DROP
> the function, pg_dump works, then add it back again and pg_dump crashes.
Hmph. I still can't reproduce this here, which se
I confirm this as a bug. First ANALYZE after crash recovery leaves stats
showing as zeroes. Repeatable on CVS HEAD with ANALYZE and VACUUM
ANALYZE.
Forwarding to bugs.
On Wed, 2008-09-24 at 15:29 -0400, Chirag Dave wrote:
>
> Testing AutoVac on 8.3 , i came across the problem of loosing stats
Devrim GÜNDÜZ wrote:
Hi,
On Thu, 2008-05-15 at 04:21 -0700, shohorab hossain wrote:
For few days I am trying to install postgresql-8.3.1 in RHEL4. My
machine configuration is Intel Pentium IV. I have followed the
installation document of postgresql that was included with source
distribution.
Hi,
On Thu, 2008-05-15 at 04:21 -0700, shohorab hossain wrote:
> For few days I am trying to install postgresql-8.3.1 in RHEL4. My
> machine configuration is Intel Pentium IV. I have followed the
> installation document of postgresql that was included with source
> distribution.
>
> I am facing t
I already found that it's possible to store passwords in the file pgpass.conf
in the %APPDATA% directory. But that file isn't stored in that location. In
fact it doesn't exist in my disk. I already checked the "Store password"
Filipe,
You need to create that file yourself. Using the format
True.
Dirk
Tom Lane wrote:
=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes:
This is not a large object. We are seeing rows with duplicate oids
because the OID counter is not changed after the dump (exported with
--oids) is being loaded.
How does 8.1 prevent to allo
=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes:
> This is not a large object. We are seeing rows with duplicate oids
> because the OID counter is not changed after the dump (exported with
> --oids) is being loaded.
> How does 8.1 prevent to allocate duplicate OIDs?
If there's a uni
This is not a large object. We are seeing rows with duplicate oids
because the OID counter is not changed after the dump (exported with
--oids) is being loaded.
How does 8.1 prevent to allocate duplicate OIDs?
Regards,
Dirk
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Dirk Lutzebäck wrote:
>> how can one set the global OID counter in 8.1.X? We think it would work
>> in 8.0.X using the COPY WITH OIDS command but this does not work in
>> 8.1.X anymore.
> pg_resetxlog -o
> (Postmaster stopped of course)
Possibly more
Dirk Lutzebäck wrote:
> Hi,
>
> how can one set the global OID counter in 8.1.X? We think it would work
> in 8.0.X using the COPY WITH OIDS command but this does not work in
> 8.1.X anymore.
pg_resetxlog -o
(Postmaster stopped of course)
--
Alvaro Herrerahttp:/
"Peter Ivarsson" <[EMAIL PROTECTED]> writes:
>>> FATAL: could not read statistics message: Resource temporarily
>>> unavailable
>> What platform is this on exactly, and what version of Postgres?
> PostgreSQL version 8.0.4 and OS is OsX 10.3 on a Mac G4.
I spent some time trying to duplicate t
Pallav Kalva wrote:
> I am using 7.4.2 on Redhat 9 Linux 2.4. I know iam on old version, we
> are actually planning to move to 8.0.1 soon, I just wanted to know if
> this is bug if so if it is 7.4.2 related .
You just need to stop your server, install 7.4.7 and restart. There is
no reason to b
I am using 7.4.2 on Redhat 9 Linux 2.4. I know iam on old version, we
are actually planning to move to 8.0.1 soon, I just wanted to know if
this is bug if so if it is 7.4.2 related .
Tom Lane wrote:
Pallav Kalva <[EMAIL PROTECTED]> writes:
do you think this problem is specific to the 7.4.2
Pallav Kalva <[EMAIL PROTECTED]> writes:
> do you think this problem is specific to the 7.4.2
> version .
You didn't say what platform this is, but it might be related to this
7.4.3 fix:
2004-04-24 16:10 tgl
* src/backend/libpq/ip.c (REL7_4_STABLE): Ensure getaddrinfo_all
retur
Hi Tom,
Thanks! for the quick reply actually i forgot to attach the log file
in my first email, the next email has the attachment, anyways here is
the output from the log file. as you can see i have 5 numbers in the ip
address which was a typo and postgres crashes when it reads the hba file
[EMAIL PROTECTED] writes:
>Yesterday, our production database was crashed as soon as we added an
> invlid
> entry in the pg_hba.conf file. Immediately, after the SIGHUP it tried to read
> the pg_hba.conf file and it couldnt validate the IP address and restarted the
> postgres server, as soon a
Donald Fraser wrote:
I have a standard Redhat 9 installation with the exception of
upgrading bison to bison-1.875-7.1
I can build the postgres rpm files from the source for version 7.4.5
no problems with the following command: rpmbuild --rebuild --define
'build89 1' --define 'python 0' --define 'te
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
A workaround is symlinking /usr/lib/kerberos/* to /usr.
We are aware of that and 7.4.7 will ship with that change.
Regards,
On Mon, 31 Jan 2005, Donald Fraser wrote:
I have a standard Redhat 9 installation with the exception of upgrading bison
to b
I had a similar problem after upgrade to 7.4.2,
Try:
SET enable_hashagg = false;
Before you execute that SELECT stmt
If you don't want disable it in postgresql.conf
Jie Liang
-Original Message-
From: Adi Alurkar [mailto:[EMAIL PROTECTED]
Sent: Monday, June 07, 2004 5:01 PM
To: [EMAIL P
Jie Liang wrote:
Does 7.3* support this? Can you tell me a bit more about it, please?
Hash aggregate..?
>I had a similar problem after upgrade to 7.4.2,
>Try:
>SET enable_hashagg = false;
>Before you execute that SELECT stmt
>If you don't want disable it in postgresql.conf
>
>Jie Liang
>
>
JC Jan Christensen <[EMAIL PROTECTED]> writes:
> creating system viewsok
> loading pg_description...ERROR: end-of-copy marker does
> not match previous newline style
> CONTEXT: COPY tmp_pg_description, line 1542: ""
> initdb: failed
I was about to say I tho
Tom Lane wrote:
> Breen Ouellette <[EMAIL PROTECTED]> writes:
> > The result of this ambiguity is that the
> > latest CD release of OpenBSD (3.4) no longer includes Postgresql
>
> We are not changing the license text we inherited from Berkeley.
> We do not have the right to, nor any interest in do
Breen Ouellette <[EMAIL PROTECTED]> writes:
> The result of this ambiguity is that the
> latest CD release of OpenBSD (3.4) no longer includes Postgresql
We are not changing the license text we inherited from Berkeley.
We do not have the right to, nor any interest in doing so.
Our interpretation
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > #\d t_a
> > Table "public.t_a"
> > Column | Type | Modifiers
> > +-+---
> > a | integer |
> > b | integer | default 4
>
> This is a bug, or at least a bad idea
"Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> On: Sunday, July 13, 2003 4:19 AM "Tom Lane" <[EMAIL PROTECTED]> wrote:
>> So? Sounds to me like it's working as intended.
> Well the documentation says:
> IMMUTABLE [...] If this option is given,
> any call of the function with all-constant
> a
On: Sunday, July 13, 2003 4:19 AM "Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > the function is immutable but is executed 3 times
> > ( one for each row).
>
> So? Sounds to me like it's working as intended.
Well the documentation says:
IMMUTABLE [...
"Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> the function is immutable but is executed 3 times
> ( one for each row).
So? Sounds to me like it's working as intended.
regards, tom lane
---(end of broadcast)---
TIP 6: Have
Daniel Rubio <[EMAIL PROTECTED]> writes:
> Yes, there's a core in the data directory, here is the stack trace:
> bash-2.03# pstack /apps/pgsql-7.3.2/data/core
> core '/apps/pgsql-7.3.2/data/core' of 6308:
> /apps/pgsql-7.3.2/bin/postmaster -D /apps/pgsql-7.3.2/da
> 00123e24 user_group_bsearch_cm
On Mon, 2003-02-24 at 23:03, Oliver Elphick wrote:
> different for different countries. There was a discussion of this on
> the patches list recently
> (http://archives.postgresql.org/pgsql-patches/2003-02/msg00038.php and
> the surrounding thread). The SQL spec calls for the Gregorian calendar
>
On Mon, Feb 24, 2003 at 11:06:38PM -0500, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I guess adding 1 day to 1752-09-02 should give us 1752-09-14, but your
> > right, it gives us 1752-09-03.
>
> As was pointed out at length just recently, the transition from Julian
> to Gregori
On Tue, 2003-02-25 at 22:08, Tim Ellis wrote:
> On Mon, 2003-02-24 at 23:03, Oliver Elphick wrote:
> > different for different countries. There was a discussion of this on
> > the patches list recently
> > (http://archives.postgresql.org/pgsql-patches/2003-02/msg00038.php and
> > the surrounding t
On Mon, 2003-02-24 at 22:59, Robert Treat wrote:
> [EMAIL PROTECTED] rms_db]$ cal 9 1752
>September 1752
> Su Mo Tu We Th Fr Sa
>1 2 14 15 16
> 17 18 19 20 21 22 23
> 24 25 26 27 28 29 30
>
> I guess adding 1 day to 1752-09-02 should give us 1752-09-14, but your
> right, it gives us
Robert Treat <[EMAIL PROTECTED]> writes:
> I guess adding 1 day to 1752-09-02 should give us 1752-09-14, but your
> right, it gives us 1752-09-03.
As was pointed out at length just recently, the transition from Julian
to Gregorian calendars happened at different times in different places.
So the a
[EMAIL PROTECTED] rms_db]$ cal 9 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
I guess adding 1 day to 1752-09-02 should give us 1752-09-14, but your
right, it gives us 1752-09-03.
Forwarding this to -bugs
Robert Treat
On Sun, 200
On Thu, Feb 20, 2003 at 11:07:55PM -0500, Tom Lane wrote:
> Ganesan R <[EMAIL PROTECTED]> writes:
> > I am using 7.3.2. postmaster prints this on starting up:
>
> > LOG: ReadRecord: bad resource manager data checksum in record at 0/E42144
>
> > pg_resetxlog is able to recover from the problem; b
On Thu, Feb 20, 2003 at 11:07:55PM -0500, Tom Lane wrote:
> Ganesan R <[EMAIL PROTECTED]> writes:
> > I am using 7.3.2. postmaster prints this on starting up:
>
> > LOG: ReadRecord: bad resource manager data checksum in record at 0/E42144
>
> > pg_resetxlog is able to recover from the problem; b
Ganesan R <[EMAIL PROTECTED]> writes:
> We've able recreate the problem on another platform;
It seems pretty dang odd that you should be able to reproduce the
problem on two different platforms, when no one else has reported it
at all. Can you think of anything unusual that might be shared by
the
Ganesan R <[EMAIL PROTECTED]> writes:
> I am using 7.3.2. postmaster prints this on starting up:
> LOG: ReadRecord: bad resource manager data checksum in record at 0/E42144
> pg_resetxlog is able to recover from the problem; but I am concerned because
> I can reproduce the scenario very easily.
Murthy Kambhampaty <[EMAIL PROTECTED]> writes:
> "/home/postgres/postgresql-7.3/src/test/regress/./tmp_check/install//usr/loc
> al/pgsql/bin/pg_encoding: relocation error:
> /home/postgres/postgresql-7.3/src/test/regress/./tmp_check/install//usr/loca
> l/pgsql/bin/pg_encoding: undefined symbol: pg_
Have you read the SCO FAQ?
http://www.us.postgresql.org/users-lounge/docs/faq.html
Also, we are about to release 7.3. Would you please try 7.3beta3 and
let us know how that works?
---
Shibashish wrote:
> Dear Sir,
Jie Liang <[EMAIL PROTECTED]> writes:
> I use:
> pg_dump -Fc -d urldb > urldb.out.020810
^^
There you have it. Better read the pg_dump help output again.
regards, tom lane
---(end of broadcast)---
TIP 4: Don'
45 matches
Mail list logo
