> The following bug has been logged online:
>
> Bug reference: 3253
> Logged by: Gary Winslow
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.4
> Operating system: Windows 2003 Server Standard SP1
> Description:8.2.4 Installer Displays No Default Install P
"Lee Chua" <[EMAIL PROTECTED]> writes:
> When we select and order by time we get 00:00:00 as the latest time of the
> day.
Really? It works as expected for me:
regression=# create table foo(f1 time);
CREATE TABLE
regression=# insert into foo values ('1:00:00'),('2:00:00'),('0:00:00'),
regression
Alvaro Herrera wrote:
Russell Smith wrote:
As I am not a frequent reporter of bugs, what happens now? It's been a
week since I wrote my last message and I'm unsure of whether anything
has, or is going to happen about this bug report. Alvaro has said it's
a "bug", so it needs fixing. But
Russell Smith wrote:
> As I am not a frequent reporter of bugs, what happens now? It's been a
> week since I wrote my last message and I'm unsure of whether anything
> has, or is going to happen about this bug report. Alvaro has said it's
> a "bug", so it needs fixing. But that has not trans
Russell Smith wrote:
CREATE ROLE test_role
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
CREATE ROLE invalid_grantor
SUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
SET ROLE invalid_grantor;
GRANT "postgres" TO "test_role";
SET ROLE postgres;
select * from pg_roles;
select pg_auth_members.*,
In the modified version of ECPG that we used for our benchmark, we
PREPARE'd all statements.
-Original Message-
From: Michael Meskes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 24, 2007 12:45 AM
To: William Lawrance
Cc: Tom Lane; pgsql-bugs@postgresql.org; [EMAIL PROTECTED]
Subject: R
We were about to submit a patch to ECPG to improve the performance
of embedded SQL, when we discovered that PREPARE had quit working.
Background:
We have a benchmark for a very large customer that consists of several
hundred programs containing several thousand embedded SQL statements.
In a thre
The following bug has been logged online:
Bug reference: 3253
Logged by: Gary Winslow
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Windows 2003 Server Standard SP1
Description:8.2.4 Installer Displays No Default Install Path and
Browse
The following bug has been logged online:
Bug reference: 3252
Logged by: Lee Chua
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.3
Operating system: FC4
Description:Select Order by time
Details:
When we select and order by time we get 00:00:00 as the lates
Tom Lane wrote:
There is one completely unexplainable bit here, though: I see no
evidence of LOCKTAG_TRANSACTION locks being taken or released anywhere
in this log excerpt. That makes no sense to me ... anyone?
They're filtered out by the trace_lock_oidmin test.
--
Heikki Linnakangas
Ente
The following bug has been logged online:
Bug reference: 3251
Logged by: CarlosCastaneda
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Windows XP
Description:selection of numeric columns from MS SQL Server return
wron values
Details:
I
The following bug has been logged online:
Bug reference: 3250
Logged by: Simon K
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2
Operating system: Windows XP
Description:Different ResultSets btw JDBC Driver and pgAdmin3
Details:
when i execute this query in
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The pending-fsync stuff in md.c is also expecting to be able to add
>> entries during a scan.
> No, mdsync starts the scan from scratch after calling AbsorbFsyncRequests.
That was last month ;-). It doesn't restart any more.
>
Tom Lane wrote:
The pending-fsync stuff in md.c is also expecting to be able to add
entries during a scan.
No, mdsync starts the scan from scratch after calling AbsorbFsyncRequests.
I don't think we can go in the direction of forbidding insertions during
a scan --- as the case at hand shows,
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I briefly went through all callers of hash_seq_init. The only place
> where we explicitly rely on being able to add entries to a hash table
> while scanning it is in tbm_lossify. There's more complex loops in
> portalmem.c and relcache.c, which I
Michael Meskes wrote:
> On Mon, Apr 23, 2007 at 02:02:04PM -0700, William Lawrance wrote:
> > Our first attempt to use the ECPG prepare interface revealed that ECPG
> > doesn't use the PQlib prepare function. The ECPG prepare replaces any
> > parameters with their values and presents a new SQL stat
Heikki Linnakangas wrote:
Tom Lane wrote:
Also, we have a generic issue that making fresh entries in a hashtable
might result in a concurrent hash_seq_search scan visiting existing
entries more than once; that's definitely not something any of the
existing callers are thinking about.
Ouch. Not
On Tue, Apr 24, 2007 at 02:25:41AM -0400, Tom Lane wrote:
> Marcin Waldowski <[EMAIL PROTECTED]> writes:
> > Ok, that's the end of the story :) My workmate has confirmed that during
> > night test PostgreSQL worked perfectly :)
>
> That fix was Obviously Necessary even without testing -- you're b
Tom Lane wrote:
It looks to me like the problem is that AtPrepare_Locks invokes
LockTagIsTemp, and that goes and reads various system catalogs, which
can result in new entries in the LOCALLOCK hash table, which might
result in a bucket split in same, which would result in some entries
possibly be
On Mon, Apr 23, 2007 at 02:02:04PM -0700, William Lawrance wrote:
> Our first attempt to use the ECPG prepare interface revealed that ECPG
> doesn't use the PQlib prepare function. The ECPG prepare replaces any
> parameters with their values and presents a new SQL statement to the
This is true and
Marcin Waldowski <[EMAIL PROTECTED]> writes:
> I was thinking that this fix will be included in 8.2.4 :) Now I know
> that it's too late (8.2.4 is released). Now I trying to find what
> conditions causes to realease new version of PostgreSQL (with fixes).
> Does any document exist about that?
N
Tom Lane wrote:
Marcin Waldowski <[EMAIL PROTECTED]> writes:
Ok, that's the end of the story :) My workmate has confirmed that during
night test PostgreSQL worked perfectly :)
That fix was Obviously Necessary even without testing -- you're being
too conservative about not applying it,
22 matches
Mail list logo
