Subject nearly says it all. Could we add it to the TODO list to have
per table statistics? I have a table here that requires a stats target
of 1000 in order for it to project values correctly (believe me, tried
everything in increments of 50 from 10 on up, it needs 1000). The
problem being t
The following bug has been logged online:
Bug reference: 1343
Logged by: r
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 Beta
Operating system: Windows XP SP2
Description:Problem with German Umlaut in the installer
Details:
Where:
1. fill in the mask
The following bug has been logged online:
Bug reference: 1342
Logged by: Ronny Schöniger
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 Beta
Operating system: Windows
Description:mistake in writing
Details:
The german windows installer contains a litt
POSTGRESQL BUG REPORT TEMPLATE
Your name : Kristofer Munn
Your email address : [EMAIL PROTECTED]
Syste
Hi,
Yes that fixed it. I don't know why? I was hunting around for anything to do
with ssl not with kerberos...
I could run the 7.4.6 configure without needing the symbolic link but
perhaps this is an issue restricted to RedHat and Whitebox.
Thanks a lot,
Aaron
- Original Message -
From
There appears to be a race condition in which dropping a view and replacing
it with an identically-named table inside one transaction while other
transactions are concurrently updating the view/table causes the following
error:
WARNING: Error occurred while executing PL/pgSQL function f
WARNI
Should I be able to
compile with gcc 3.3.2 (from sunfreeware) on solaris 10?
I'm using sparc, and
am getting some strange looking compiler errors when trying to do the
make.
I'm getting some
compiler parse errors when compiling exec.c.
make -C doc
allmake[1]: Entering directory
`
Frank van Vugt <[EMAIL PROTECTED]> writes:
> I guess this patch is already in the RC2 tree?
No, I was waiting for confirmation ...
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Hi Tom,
> Looks like the problem is associated with DEFERRED AFTER triggers
> The attached patch fixes the test case you sent; can you
> try it against your other problem?
I patched RC1 with this and tried the conversion again. Though still running,
it's passed the point where the mem-alloc err
On Monday December 6 2004 11:50, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > I can see the point of *not* dropping the sequence unless the
> > owning column is dropped. I just don't see the point of disabling the
> > useful ability to decouple the sequence-column association, and
> >
On Mon, Oct 25, 2004 at 02:22:37AM +0100, PostgreSQL Bugs List wrote:
> Description:ecpg precompile bug (valiable typedef & define )
>
> Details:
>
> The result to demand cannot be found although the following programs were
> performed.
Fix just committed. Thanks for the report.
Mich
"Ed L." <[EMAIL PROTECTED]> writes:
> I can see the point of *not* dropping the sequence unless the
> owning column is dropped. I just don't see the point of disabling the
> useful ability to decouple the sequence-column association, and dropping
> the default seems the most reasonable way to d
Frank van Vugt <[EMAIL PROTECTED]> writes:
> Looking forward to your assesment.
Looks like the problem is associated with DEFERRED AFTER triggers: we
don't normally set a snapshot for TransactionStmt commands, including
COMMIT, but there needs to be a snapshot set when running trigger
functions.
On Monday December 6 2004 9:45, Ed L. wrote:
> On Sun, 05 Dec 2004 14:54:38, Tom Lane wrote:
> > On Sunday December 5 2004 12:34, Ed L. wrote:
> > > The following queries result in a dropped sequence, but IMO should
> > > not:
> > >
> > > create table foo(id serial);
> > > create table bar(id integ
On Sun, 05 Dec 2004 14:54:38, Tom Lane wrote:
> On Sunday December 5 2004 12:34, Ed L. wrote:
> > The following queries result in a dropped sequence, but IMO should not:
> >
> > create table foo(id serial);
> > create table bar(id integer not null nextval('foo_id_seq'::text));
> > alter table foo a
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> select * from teleoperador;
> id | login | ip | tipo
> +--++--
> 0 | pablo| 10.0.0.106 | C
> 1 | builder | 10.0.0.107
> 10.0.0.107 | C
> 2 | reinaldo | 10.0.0
The following bug has been logged online:
Bug reference: 1341
Logged by: Pablo Borges
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.6
Operating system: Linux Slackware
Description:problem when showing resulted in the screen
Details:
select * from te
The following bug has been logged online:
Bug reference: 1340
Logged by: Pablo Borges
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.6
Operating system: Linux Slackware
Description:problem when showing resulted in the screen
Details:
select * from te
Hi Tom,
> Because the trigger function is plpgsql, this could happen only the
> first time the trigger is fired in a particular session (unless you are
> using EXECUTE to invoke the update command?). If the problem is related
> to the planner constant-folding environment, then the first-time-only
The following bug has been logged online:
Bug reference: 1339
Logged by: Florent Merlet
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.3
Operating system: CYGWIN_NT
Description:enable to init database cluster
Details:
I manage to use the 7.3 version w
20 matches
Mail list logo
