Sorry Bad, Cut and paste. This test is a strip down of much larger
test. The reason the metadata is there as this gets run from a
framework which exercises JDBC drivers from all of the major vendors
which is also the reason for the Drivers class.
As far as the INSERT, i did not look at the
The following bug has been logged online:
Bug reference: 3755
Logged by: Vasiliy Melnikov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.3
Operating system: WindowsXP + sp2
Description:Installation dont completed
Details:
Some time I use PostgreSQL on PC w
Koichi Suzuki wrote:
> I've found that B-tree crash recovery in 8.3 beta2 could make some
> tuples invisible through B-tree. They're visible if we read using but
> Seq-Scan. This happens in 8.3 beta2, but not in 8.2.4. Here's how it
> happens.
>
> 1. Create b-tree for a text type column.
> 2.
Hi,
I've found that B-tree crash recovery in 8.3 beta2 could make some
tuples invisible through B-tree. They're visible if we read using but
Seq-Scan. This happens in 8.3 beta2, but not in 8.2.4. Here's how it
happens.
1. Create b-tree for a text type column.
2. Make B-tree three-story, that
Do you have a core file? Can you provide stack trace output?
Thanks
Michael Charnoky wrote:
The following bug has been logged online:
Bug reference: 3752
Logged by: Michael Charnoky
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3beta2
Operating syst
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> There seems to be a bug in the B-tree split WAL reduction patch from
> Februrary. On split, we copy the HIKEY of the left page from the
> leftmost item on the right page, but that doesn't work because the
> leftmost key is not stored on intermediate
Thank you for your time, but i think there is still a driver issue here:
If i use the same types as i sent in the email and execute
select * from bit_in_min(1::bit)
I have no problems and the table is correctly updated.
This would lead me to believe that the driver has a problem with
corre
* Magnus Hagander wrote:
Christian Ullrich wrote:
psql tells me about an "invalid frontend message type 112". Most of the
time, that error comes as the first line of output from psql (above the
"Welcome to" line), sometimes it is displayed later:
Does it work if you run the client on the s
I have the following table
Table "public.authorsort"
Column | Type | Modifiers
--+---+---
ordernum | integer |
handle | character varying(30) |
Indexes: author_handle_idx btree (handle)
As you can tell I have a
"Michael Charnoky" <[EMAIL PROTECTED]> writes:
> 2007-11-15 15:38:03.880 PST: ERROR: could not find block containing chunk
> 0x902fb98
We can't do much about this without a self-contained test case.
> 2007-11-15 15:38:03.880 PST: STATEMENT: SELECT path_tag, dayset_tag,
> time2secs(ts_endtime),
Christian Ullrich wrote:
> The following bug has been logged online:
>
> Bug reference: 3750
> Logged by: Christian Ullrich
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3-beta2
> Operating system: Windows Server 2003
> Description:Invalid frontend message
The following bug has been logged online:
Bug reference: 3754
Logged by: RaviKumar.kapa
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.1
Operating system: Windows2000
Description:postgresql+hibernate
Details:
I have the dought.i.e
can I Use hibernate to c
RaviKumar.kapa wrote:
The following bug has been logged online:
Bug reference: 3754
Logged by: RaviKumar.kapa
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.1
Operating system: Windows2000
Description:postgresql+hibernate
Details:
I have the dought.i.e
The following bug has been logged online:
Bug reference: 3752
Logged by: Michael Charnoky
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3beta2
Operating system: Linux (Fedora Core 3) 2.6.17
Description:query yields "could not find block containing chunk",
the
Kris,
Thanks for the follow up.
Kris Jurka wrote:
Lance J. Andersen wrote:
Thank you for your time, but i think there is still a driver issue here:
If i use the same types as i sent in the email and execute
select * from bit_in_min(1::bit)
I have no problems and the table is correctly up
Michael Charnoky wrote:
2007-11-15 15:38:03.880 PST: ERROR: could not find block containing chunk
0x902fb98
This message appears in AllocSetFree or AllocSetRealloc function in
aset.c source. In both function it means that defined context does not
contain memory block. By my opinion there
16 matches
Mail list logo
