Steve Martin wrote:
Hi,
We are having trouble with the output of timestamp with time zone with
versions 8.1.10 and 8.3.1.
It seems reversed, and change over times are incorrect.
timezone for both is:
=> show timezone ;
TimeZone -
NZST-12NZDT
(1 row)
Note, change over times for
I have some problem with setting up PITR recovery on the database.
I have archive_command set properly and logs are shipping OK. Archive
timeout is also set (5 min).
When performing pg_start_backup the WAL is lets say on position
0001000100D9, then I start copy database to the second
My OS Type its: Windows Vista 64bits, Portuguese Brazil
I have installed the 8.3 with msi package
The message error was: "ailed to run initdb: 1!"
I serached google and i found nothing
On Sat, Apr 26, 2008 at 12:02 PM, Martijn van Oosterhout <[EMAIL PROTECTED]>
wrote:
> On Thu, Apr 24, 2008 at 0
Tom Lane wrote:
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
On Thu, Apr 24, 2008 at 06:30:27PM +1200, Steve Martin wrote:
=> show timezone ;
TimeZone
-
NZST-12NZDT
(1 row)
I have no idea what timezone that it. Presumably it switches between
daylight s
Tom Allison wrote:
Am I missing something in the fine print?
fine print = see 5.8.1 Caveats on
http://www.postgresql.org/docs/8.3/interactive/ddl-inherit.html
klint.
--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350
Ph: 02 6773 3789
Fax: 02 6773
create table master (
id serial,
mdn varchar(11),
meid varchar(18),
min varchar(11),
constraint mmm_master unique (mdn, meid, min)
);
insert into master(mdn, meid, min)
select mdn, meid, min from test_data where meid != '00'
limit 10;
Everything works up to this point...
insert
Ran into something really unexpected, but then I've never tried using
inherited tables.
I have a master table (named master) that has two child tables.
create table master (
id serial,
foo varchar(20),
bar varchar(20),
constraint foobar_master unique (foo,bar)
);
Now when I do this wit
Martijn van Oosterhout wrote:
Yes, if you're getting that message on a connection without having an
error on that connection then something is really wrong. Note, I've
never used PG with PHP so I can't help you with anything specific.
Turn on pgsql.auto_reset_persistent.
--
Best regards,
Hanne
"Matthew Dennis" <[EMAIL PROTECTED]> writes:
> Do SQL statements inside of plpgsql functions get planned upon every
> execution, only when the function is first executed/defined, or something
> else entirely?
First executed per session.
> Now, when bar is executed again, will PG (8.3.1) know th
On Sun, Apr 27, 2008 at 02:05:16PM +0200, Ivan Sergio Borgonovo wrote:
> "Eh?" was my same reaction. I'm going to check the logs... and be
> sure I wasn't dreaming.
> Do you confirm that if I wasn't dreaming and another page that should
> have opened another connection with pg_connect did cause ano
On Sun, Apr 27, 2008 at 2:06 AM, Matthew Dennis <[EMAIL PROTECTED]> wrote:
> Do SQL statements inside of plpgsql functions get planned upon every
> execution, only when the function is first executed/defined, or something
> else entirely?
They are planned on first execution and the plan is cached
On Sun, 27 Apr 2008 11:26:33 +0200
Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> > That would make postgresql a BIG BIG BIG lock.
> > If every rollback is going to block all connections that's a
> > problem. That's exactly why I pointed out that I was using plain
> > pg_connect and not pg_pc
On Sun, Apr 27, 2008 at 11:09:36AM +0200, Ivan Sergio Borgonovo wrote:
> > because each page got an error in a statement inside its
> > transaction. It then issued the above error over and over as you
> > attempted to execute the next statement.
>
> That would make postgresql a BIG BIG BIG lock.
>
On Sat, 26 Apr 2008 20:58:06 -0600
"Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 26, 2008 at 4:19 PM, Ivan Sergio Borgonovo
> <[EMAIL PROTECTED]> wrote:
> >
> > With the added @ everything seemed to be OK.
>
> No, the @ is just making php quietly swallow the postgresql errors
> that a
14 matches
Mail list logo
