Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think what I conclude from this is that Windows TZ database is so
> bogus that we should avoid trying to rely on it -- I say if the user
> does not set "timezone" in postgresql.conf, refuse to start.
Remember we're also relying on the OS for the time
Magnus Hagander wrote:
> Tom Lane wrote:
>> This does suggest that we'll need to revisit the win32_tzmap[] list
>> every so often?
>
> Seems so. It's the first time I've heard of a timezone being *added* and
> not just changed, but obviously it does happen :-(
Hmm, was this table manually built
perhaps this helps
http://www.webservertalk.com/archive308-2007-3-1836413.html
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of vha
> Sent: Sunday, February 10, 2008 7:55 PM
> To: pgsql-bugs@postgresql.org
> Subject: [BUGS] BUG #3951: SELECT ... W
Tomas Szepe <[EMAIL PROTECTED]> writes:
>> Are you running with autovacuum on, or not?
> At the moment autovacuum is off, but it _might_ have been on in the first
> 40 hours or so... Sorry, I can't say exactly.
Okay ... so with autovac off, I can reproduce a problem this way:
1. Put 1000 repeti
The following bug has been logged online:
Bug reference: 3951
Logged by: vha
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: Windows XP SP2
Description:SELECT ... WHERE Param = ? does not work if Param is of
type bytea
Details:
I have a ta
> Tomas Szepe <[EMAIL PROTECTED]> writes:
> >> Are you doing anything that would involve lots of updates in these
> >> catalogs --- maybe repeatedly renaming a column, or something like that?
>
> > Hmm, I typically use a pair of
> > "ALTER TABLE table DISABLE TRIGGER USER;"/
> > "ALTER TABLE table
Tomas Szepe <[EMAIL PROTECTED]> writes:
>> Are you doing anything that would involve lots of updates in these
>> catalogs --- maybe repeatedly renaming a column, or something like that?
> Hmm, I typically use a pair of
> "ALTER TABLE table DISABLE TRIGGER USER;"/
> "ALTER TABLE table ENABLE TRIGGE
> After poking around in the code a bit, I found a way to reproduce the
> assert failure:
[snip]
Great!
> Another issue is that while I can create a page with
> MaxHeapTuplesPerPage dead tuples easily enough in testing, it's not
> clear how you managed to get into that state in the system catalog
Tomas Szepe <[EMAIL PROTECTED]> writes:
>> Do you perhaps have a ridiculously low fillfactor attached to
>> the system catalogs?
> I don't know - how do I tell?
If you did, you'd know it --- that's not something that would happen
without your trying to do it.
After poking around in the code a bi
On Feb 10, 2008 5:10 PM, Fusion Software (UK) Ltd
<[EMAIL PROTECTED]> wrote:
>
> Hi Dave
>
> Is this machine on a domain with any group policies or similar? I assume
> you're running the installations as Administrator?
> Its a basic default Vista installation with no domain or group policies.
> Mos
"Wolvesden" <[EMAIL PROTECTED]> writes:
> For some reason when I upgraded to 8.3 I can't get the server to start.
> What it keeps telling me is as Follows:
> pg_ctrl: another server might be running; trying to start server anyway
> FATAL: unreconized configuration parameter "redirect_stderr"
This
[Please keep messages CC'd to the list]
On Feb 10, 2008 4:25 PM, Fusion Software (UK) Ltd
<[EMAIL PROTECTED]> wrote:
>
> Just to update you on the latest. It appears that although we can get 8.3.0
> to install by installing the Visual C++ 2005 msi first, although it appears
> to work fine when it
The following bug has been logged online:
Bug reference: 3950
Logged by: Wolvesden
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: Windows XP
Description:Server Problems
Details:
For some reason when I upgraded to 8.3 I can't get the serve
On Feb 10, 2008 4:45 PM, Fusion Software (UK) Ltd
<[EMAIL PROTECTED]> wrote:
>
> Can also confirm that under exactly the same circumstances 8.2 installs
> without a hitch. There's definitiely a glitch somewhere in the 8.3
> installation package.
8.3 is the first release build with VC++ 2005 - pre
I'll upgrade to 8.2 ASAP. Once in 8.2, which value should I use for timezone
in postgresql.conf?
Thanks and regards,
Jorge
- Original Message -
From: "Magnus Hagander" <[EMAIL PROTECTED]>
To: "Jorge Campins" <[EMAIL PROTECTED]>
Cc: "Tom Lane" <[EMAIL PROTECTED]>;
Sent: Sunday, Febru
In 8.2, use pg_timezone_names to find the proper one for you - it'll
exist once you've upgraded :-)
//Magnus
Jorge Campins wrote:
I'll upgrade to 8.2 ASAP. Once in 8.2, which value should I use for
timezone in postgresql.conf?
Thanks and regards,
Jorge
- Original Message - From: "M
> >> Hmm, please see if you can get a stack trace from that (set the
> >> breakpoint at errfinish()). You might want to use vacuum verbose
> >> first so that you can figure out which individual table is causing it.
>
> > Ok, I recompiled CVS head with --enable-debug and with --enable-cassert
> >
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Try setting your timezone in postgresql.conf - that should override
whatever Windows has for you.
Unless his "8.1" is really 8.1.something-pretty-darn-recent, it's
not going to know about the latest Venezuela DST law change anyway.
Jorge Campins wrote:
How can I find which version I'm using? All I could see in pgAdmin is 8.1.
SELECT version();
Which value should I use for timezone in postgresql.conf? I tried select
* from pg_timezone_names to get a list of valid time zone names but it
failed with "relation pg_timezon
How can I find which version I'm using? All I could see in pgAdmin is 8.1.
Which value should I use for timezone in postgresql.conf? I tried select *
from pg_timezone_names to get a list of valid time zone names but it failed
with "relation pg_timezone_names does not exist."
Thanks and rega
20 matches
Mail list logo
