I don't know if I'm going to get a copy of
pg_filedump. What's the best way to fix this - dump
then restore?
CSN
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> CSN <[EMAIL PROTECTED]> writes:
> > oid | ctid| xmin | cmin | xmax |
> cmax | id
> >
>
+---+-+-
Martijn van Oosterhout writes:
> On Mon, Oct 10, 2005 at 05:28:17PM -0400, Tom Lane wrote:
>> But people were a bit worried about what
>> might break.
> In catalog/heap.c there already is a SystemAttributeByName() to do the
> legwork. Seems to me all you'd need to do is check just as you're about
On Mon, Oct 10, 2005 at 05:28:17PM -0400, Tom Lane wrote:
> I recall having proposed that we stop storing explicit pg_attribute
> entries for system columns, which would make this sort of change easier
> to make, and would save a pretty considerable amount of space in
> pg_attribute too. (In the p
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Oct 10, 2005 at 04:28:57PM -0400, Tom Lane wrote:
>> It's really highly annoying that we can't see the contents of the
>> infomasks for the rows.
> Any particular reason there isn't an infomask system column?
(a) inertia
(b) lack of desire to ad
On Mon, Oct 10, 2005 at 04:28:57PM -0400, Tom Lane wrote:
> It's really highly annoying that we can't see the contents of the
> infomasks for the rows.
Any particular reason there isn't an infomask system column?
--
Michael Fuhr
---(end of broadcast)-
On Mon, 2005-10-10 at 15:51, CSN wrote:
> I don't have a compiler on this machine. If somebody
> can point me to a copy of pg_filedump for Windows (I
> didn't see any using Google) I'd be happy to use it.
> Or perhaps I could compile it under cygwin.
>
> The hard drive is a Western Digital 200GB J
I don't have a compiler on this machine. If somebody
can point me to a copy of pg_filedump for Windows (I
didn't see any using Google) I'd be happy to use it.
Or perhaps I could compile it under cygwin.
The hard drive is a Western Digital 200GB JD (SATA),
if that can be used to determine how badl
CSN <[EMAIL PROTECTED]> writes:
> oid | ctid| xmin | cmin | xmax | cmax | id
> +---+-+--+-+--+-
> 125466 | (2672,11) | 1445346 |0 | 1481020 |0 | 985
> 125466 | (2745,50) | 1481020 |0 | 1682425 |2 | 985
Hmm. The fact tha
--- Michael Fuhr <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 09, 2005 at 12:46:51PM -0700, CSN wrote:
> > select * from table1 where id=586;
> > 586|a|b|c|d
>
> Do you get different results from the following
> queries?
>
> SET enable_seqscan TO on;
> SET enable_indexscan TO off;
> SELECT * FROM t
On Sun, Oct 09, 2005 at 12:46:51PM -0700, CSN wrote:
> select * from table1 where id=586;
> 586|a|b|c|d
Do you get different results from the following queries?
SET enable_seqscan TO on;
SET enable_indexscan TO off;
SELECT * FROM table1 WHERE id = 586;
SET enable_seqscan TO off;
SET enable_index
This is weird. I set up a table with a serial id field
and created a primary key on it. Then I imported data.
Running an app against it, I got periodic errors
stating "duplicate key violates unique constraint
"pkey_table1." Looking through the table (with
phppgadmin), there are duplicate rows:
id|
11 matches
Mail list logo
