Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It sounds like a mind-numbingly tedious task though :-(
> Added to TODO:
> {{TodoItemEasy
> |Revise the src/timezone/tznames abbreviation files:
BTW, it just occurred to me to wonder whether we couldn't modify the
"zic" application
Tom Lane wrote:
> Well, it's intentional that the view not contain *every* abbrev,
> since there are conflicts. But I have noticed that the files under
> src/timezone/tznames/ seem to be missing some abbreviations that are
> in fact known in the zic database. Somebody ought to go through that
>
"" <[EMAIL PROTECTED]> writes:
> It looks like pg_timezone_abbrevs is missing some entries?
Well, it's intentional that the view not contain *every* abbrev,
since there are conflicts. But I have noticed that the files under
src/timezone/tznames/ seem to be missing some abbreviations that are
in f
The following bug has been logged online:
Bug reference: 4377
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Fedora 7
Description:casting result of timeofday() to timestamp fails in some
timezones
Details:
It looks like pg_t
2008/8/26 Tom Lane <[EMAIL PROTECTED]>:
> Jeff Davis <[EMAIL PROTECTED]> writes:
>> => -- make "foo" into a subquery and add a no-op
>> => -- to prevent it from pulling up the subquery
>> => select max(a), generate_series(1,2) as g from (select a as a from foo
>> offset 0) dummy;
>> ERROR: set-val
Jeff Davis <[EMAIL PROTECTED]> writes:
> => -- make "foo" into a subquery and add a no-op
> => -- to prevent it from pulling up the subquery
> => select max(a), generate_series(1,2) as g from (select a as a from foo
> offset 0) dummy;
> ERROR: set-valued function called in context that cannot acce
On Tue, 2008-08-26 at 01:04 -0400, Tom Lane wrote:
> Please provide some more detail about those experiments. The test case
> hasn't been seen to fail in the buildfarm, AFAIR.
Dan Farina, my colleague at Truviso, was experimenting with some query
transformations that pushed the range table entrie
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Peter Eisentraut" <[EMAIL PROTECTED]> writes:
>> Well, the problem is mainly that there is no query, because the bytes
>> arriving
>> are garbage. A human observer could make sense of it in some cases, but not
>> a computer in the general case.
> Ho
Zahid Khan <[EMAIL PROTECTED]> writes:
> I see one behavior change is PG8.3 and PG 8.2 .I was getting error of
> underflow value in PG8.2 when i
> tried to insert '1E-307' in double precision column .And my
> application was expecting the same error condition with the same
> values against PG 8
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Thomas H. wrote:
>> maybe its by design (to not insert badly encoded characters into the
>> utf8 encoded logs)? nevertheless to debug those faulty programm/codes,
>> it would help to see what query provokes the error...
>
> Well, the problem is main
Peter Schuller wrote:
> I will go hide in a corner now...
FWIW, as soon as you come out of the corner, you can solve the problem
easily by manually copying the file back from the archive location into
pg_xlog and restarting the server.
--
Alvaro Herrerahttp://www
Peter Schuller wrote:
> It would be embarressing if I caused this problem myself by
> misunderstanding wal_archiving. My understanding has been that once
> wal_archive gets called, no one ever cares what happens with the file
> except if I want to do PITR (since the whole point is to offload it
>
> I'll go and re-read the documentation on this immediately. If this is
> the problem, I do apologies for the noise and people's time.
So it is, as far as I can tell. The script should not remove the
file. I don't know what I was thinking. This was not a smart thing to
do...
I sincerely apologies
> > -rw--- 1 postgres postgres 16777216 Aug 26 17:16
> > 0001001800EE
> > drwx-- 2 postgres postgres 305232 Aug 26 17:14 archive_status
> >
> > Note that the archival of the ED xlog file started at 17:14:52,
> > and I cancelled the VACUUM FULL at 17:16:06.
>
> What's
Peter Schuller wrote:
> The pg_xlog directory contains:
>
> -rw--- 1 postgres postgres 16777216 Aug 26 17:16 0001001800EE
> drwx-- 2 postgres postgres 305232 Aug 26 17:14 archive_status
>
> Note that the archival of the ED xlog file started at 17:14:52,
> and I cancel
Hello,
[note: in pastes below, the only thing changes are database names and
hostnames, for privacy reasons; otherwise plain cut'n'paste including
typos...)
Very short version: I cancelled a VACUUM FULL; server crashed; won't
start again because it tries to access an obsolete WAL log file that
is
Thomas H. wrote:
> maybe its by design (to not insert badly encoded characters into the
> utf8 encoded logs)? nevertheless to debug those faulty programm/codes,
> it would help to see what query provokes the error...
Well, the problem is mainly that there is no query, because the bytes arriving
a
can you share the PostgreSQL version you are using
PG8.3.1
maybe you are facing some sort of corruption?
I do not know. All other works fine except that.
- Original Message -
From: "Hans-Juergen Schoenig" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, August 26, 200
[EMAIL PROTECTED] wrote:
select ats.id, ap.value from akh_test_suit ats
LEFT JOIN akh_properties ap on ap.ID = ats.test_suit_type_id
where ats.ID = 472
id | value
472 | 472
ID -- integer
value -- text
select * from akh_test_suit ats
LEFT JOIN akh_properties ap on ap.ID = ats.test_suit_type_id
whe
thomas wrote:
The following bug has been logged online:
Bug reference: 4281
Logged by: thomas
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Windows 2003
Description:some types of errors do not log statements
Details:
this isn't reall
select ats.id, ap.value from akh_test_suit ats
LEFT JOIN akh_properties ap on ap.ID = ats.test_suit_type_id
where ats.ID = 472
id | value
472 | 472
ID -- integer
value -- text
select * from akh_test_suit ats
LEFT JOIN akh_properties ap on ap.ID = ats.test_suit_type_id
where ats.ID = 472 and ap.v
I see one behavior change is PG8.3 and PG 8.2 .I was getting error of
underflow value in PG8.2 when i
tried to insert '1E-307' in double precision column .And my
application was expecting the same error condition with the same
values against PG 8.3.3 as well.but now this vaule is inserted succe
The following bug has been logged online:
Bug reference: 4376
Logged by: Cong
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2
Operating system: WindowXP
Description:Running as a database
Details:
Make it as a database but i don't know how to convert it into
Hallo Craig,
Craig Ringer schrieb:
So: the user's report is incorrect in blaming pg_restore, but correct in
that comments on the public schema (and presumably other default schema)
aren't preserved by pg_dump | pg_restore. The real reason appears to be
that they're not dumped in the first place.
On Tue, Aug 26, 2008 at 7:16 AM, Janardhanachari, Jagadeesha
<[EMAIL PROTECTED]> wrote:
> HI,
>
> Thanks for your reply, but tell me what is the default password for
> postgres on windows environment ?
Assuming you used the installer, whatever password you entered when
prompted. It won't let you c
HI,
Thanks for your reply, but tell me what is the default password for
postgres on windows environment ?
___
Jagu
Fidelity Business Services India.
Mobile: 9900540134
Direct : 40334528
Voip : 8-658-1596
Any comments or statements made in this email are not
26 matches
Mail list logo
