Обсуждение: CTID: Anyway to lock it?

Поиск
Список
Период
Сортировка

CTID: Anyway to lock it?

От
Jim Hines
Дата:
Hello,
I have a piece of software that uses specific record numbers in order to pull
data from PG. It uses this query:
select "votes" ,  CTID, OID from database where ctid in ('(27, 55)')'

Apparently the CTID changes per record with each update. Is there anyway to
lock the CTID so that it doesn't change everytime I update a record?

thanks,


--
Jim Hines


Re: CTID: Anyway to lock it?

От
Tom Lane
Дата:
Jim Hines <jhines@wdtv.com> writes:
> Apparently the CTID changes per record with each update. Is there anyway to
> lock the CTID so that it doesn't change everytime I update a record?

No.  If your software is using CTID as a long-term (more than one
transaction) record identifier, then your software is broken.

            regards, tom lane

Re: CTID: Anyway to lock it?

От
"Dave Page"
Дата:

> -----Original Message-----
> From: Jim Hines [mailto:jhines@wdtv.com]
> Sent: 04 November 2002 19:00
> To: pgsql-odbc@postgresql.org
> Subject: [ODBC] CTID: Anyway to lock it?
>
>
> Hello,
> I have a piece of software that uses specific record numbers
> in order to pull
> data from PG. It uses this query:
> select "votes" ,  CTID, OID from database where ctid in ('(27, 55)')'
>
> Apparently the CTID changes per record with each update. Is
> there anyway to
> lock the CTID so that it doesn't change everytime I update a record?

No, I would think not. From the docs:

Ctid - The tuple ID of the tuple within its table. This is a pair (block
number, tuple index within block) that identifies the physical location
of the tuple. Note that although the ctid can be used to locate the
tuple very quickly, a row's ctid will change each time it is updated or
moved by VACUUM FULL. Therefore ctid is useless as a long-term row
identifier. The OID, or even better a user-defined serial number, should
be used to identify logical rows.

Regards, Dave.

Re: CTID: Anyway to lock it?

От
Jim Hines
Дата:
On Monday 04 November 2002 02:36 pm, you wrote:

> No, I would think not. From the docs:
>
> Ctid - The tuple ID of the tuple within its table. This is a pair (block
> number, tuple index within block) that identifies the physical location
> of the tuple. Note that although the ctid can be used to locate the
> tuple very quickly, a row's ctid will change each time it is updated or
> moved by VACUUM FULL. Therefore ctid is useless as a long-term row
> identifier. The OID, or even better a user-defined serial number, should
> be used to identify logical rows.

The way the Lyric software is configure to access this database is:
Datasource "PostgreSQL"
Table          "pelections02"
Field          "votes"
Record        "number"

Here is the log from it:

Global Options: Version='07.02.0003', fetch=100, socket=4096, unknown_sizes=0,
max_varchar_size=254, max_longvarchar_size=8190
                disable_optimizer=1, ksqo=1, unique_index=1,
use_declarefetch=0
                text_as_longvarchar=1, unknowns_as_longvarchar=0,
bools_as_char=1 NAMEDATALEN=64
                extra_systable_prefixes='dd_;', conn_settings=''
conn_encoding='OTHER'
conn=331625856, query=' '
conn=331625856, query='select version()'
    [ fetched 1 rows ]
    [ PostgreSQL version string = 'PostgreSQL 7.2.1 on i686-pc-linux-gnu,
compiled by GCC 2.96' ]
    [ PostgreSQL version number = '7.2' ]
conn=331625856, query='set DateStyle to 'ISO''
conn=331625856, query='set geqo to 'OFF''
conn=331625856, query='select oid from pg_type where typname='lo''
    [ fetched 0 rows ]
conn=331625856, query='select pg_client_encoding()'
    [ fetched 1 rows ]
    [ Client encoding = 'SQL_ASCII' (code = 0) ]
conn=331625856,

PGAPI_DriverConnect(out)='DSN=PostgreSQL;DATABASE=news5;SERVER=192.168.1.1;PORT=5432;UID=postgres;PWD=a209155;A6=;A7=100;A8=4096;B0=254;B1=8190;BI=0;C2=dd_;;CX=18250fab'

conn=331625856, query='select u.usename, c.relname, a.attname, a.atttypid,
t.typname, a.attnum, a.attlen, a.atttypmod, a.attnotnull, c.relhasrules from
pg_user u, pg_class c, pg_attribute a, pg_type t where u.usesysid =
c.relowner and c.oid= a.attrelid and a.atttypid = t.oid and (a.attnum > 0)
and c.relname = 'pelections02' order by c.relname, attnum'
    [ fetched 13 rows ]
PGAPI_Columns:
table='pelections02',field_name='county',type=1043,name='varchar'
PGAPI_Columns: table='pelections02',field_name='party',type=1042,name='bpchar'
PGAPI_Columns:
table='pelections02',field_name='amend',type=1043,name='varchar'
PGAPI_Columns:
table='pelections02',field_name='ticket',type=1042,name='bpchar'
PGAPI_Columns:
table='pelections02',field_name='office',type=1043,name='varchar'
PGAPI_Columns:
table='pelections02',field_name='candidate',type=1043,name='varchar'
PGAPI_Columns:
table='pelections02',field_name='votes',type=1700,name='numeric'
PGAPI_Columns: table='pelections02',field_name='for',type=1700,name='numeric'
PGAPI_Columns:
table='pelections02',field_name='against',type=1700,name='numeric'
PGAPI_Columns:
table='pelections02',field_name='precincts',type=1043,name='varchar'
PGAPI_Columns: table='pelections02',field_name='uo',type=1042,name='bpchar'
PGAPI_Columns:
table='pelections02',field_name='notes',type=1043,name='varchar'
PGAPI_Columns: table='pelections02',field_name='ref',type=1700,name='numeric'
conn=331625856, query='Select "precincts" , CTID, OID from pelections02 where
ctid = '(,)';select ctid, oid from pelections02'
    [ fetched 0 rows ]
    [ fetched 139 rows ]
conn=331625856, query='Select "precincts" , CTID, OID from pelections02 where
ctid in ('(35, 52)')'
    [ fetched 1 rows ]
conn=331625856, query='Select "precincts" , CTID, OID from pelections02 where
ctid in ('(39, 46)')'
    [ fetched 1 rows ]
conn=331625856, query='Select "candidate" , CTID, OID from pelections02 where
ctid = '(,)';select ctid, oid from pelections02'
    [ fetched 0 rows ]
    [ fetched 139 rows ]
conn=331625856, query='Select "candidate" , CTID, OID from pelections02 where
ctid in ('(35, 52)')'
    [ fetched 1 rows ]
conn=331625856, query='Select "candidate" , CTID, OID from pelections02 where
ctid in ('(38, 36)')'
    [ fetched 1 rows ]
conn=331625856, query='Select "votes" , CTID, OID from pelections02 where ctid
= '(,)';select ctid, oid from pelections02'
    [ fetched 0 rows ]
    [ fetched 139 rows ]
conn=331625856, query='Select "votes" , CTID, OID from pelections02 where ctid
in ('(35, 52)')'
    [ fetched 1 rows ]
conn=331625856, query='Select "votes" , CTID, OID from pelections02 where ctid
in ('(38, 36)')'
    [ fetched 1 rows ]
conn=331625856, query='Select "votes" , CTID, OID from pelections02 where ctid
= '(,)';select ctid, oid from pelections02'
    [ fetched 0 rows ]
    [ fetched 139 rows ]
conn=331625856, query='Select "votes" , CTID, OID from pelections02 where ctid
in ('(35, 52)')'
    [ fetched 1 rows ]
conn=331625856, query='Select "votes" , CTID, OID from pelections02 where ctid
in ('(40, 1)')'
    [ fetched 1 rows ]
conn=331625856, PGAPI_Disconnect



The folks at Chyron say they are not specifiing CTID and that it must be
within the ODBC driver. Could this be the case? If so, what setting would
control this?


--
Jim Hines
IT Mgr, WDTV NewsChannel 5
Your Hometown News

TEL:304.848.5000
FAX:304.842.7501
<http://www.wdtv.com>
<jhines@wdtv.com>

WDTV NewsChannel 5 is a CBS Affiliate

Re: CTID: Anyway to lock it?

От
"Dave Page"
Дата:

> -----Original Message-----
> From: Jim Hines [mailto:jhines@wdtv.com]
> Sent: 04 November 2002 20:06
> To: pgsql-odbc@postgresql.org; Dave Page
> Subject: Re: [ODBC] CTID: Anyway to lock it?
>
> The folks at Chyron say they are not specifiing CTID and that
> it must be
> within the ODBC driver. Could this be the case? If so, what
> setting would
> control this?

Hmm, yes - it appears to be in inner_process_tokens(QueryParse *qp,
QueryBuild *qb) in convert.c. I don't know what options might affect
that though I'm afraid - do you know Hiroshi?

Regards, Dave.

Re: CTID: Anyway to lock it?

От
Hiroshi Inoue
Дата:
Dave Page wrote:
>
> > -----Original Message-----
> > From: Jim Hines [mailto:jhines@wdtv.com]
> > Sent: 04 November 2002 20:06
> > To: pgsql-odbc@postgresql.org; Dave Page
> > Subject: Re: [ODBC] CTID: Anyway to lock it?
> >
> > The folks at Chyron say they are not specifiing CTID and that
> > it must be
> > within the ODBC driver. Could this be the case? If so, what
> > setting would
> > control this?
>
> Hmm, yes - it appears to be in inner_process_tokens(QueryParse *qp,
> QueryBuild *qb) in convert.c. I don't know what options might affect
> that though I'm afraid - do you know Hiroshi?

The driver uses CTID and OID to implement updatable cursors.
Please turn off the *Updatable cursors* DSN option if you
don't like the behavior.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

Re: CTID: Anyway to lock it?

От
Jim Hines
Дата:
> > Hmm, yes - it appears to be in inner_process_tokens(QueryParse *qp,
> > QueryBuild *qb) in convert.c. I don't know what options might affect
> > that though I'm afraid - do you know Hiroshi?
>
> The driver uses CTID and OID to implement updatable cursors.
> Please turn off the *Updatable cursors* DSN option if you
> don't like the behavior.
>
> regards,
> Hiroshi Inoue
>     http://w2422.nsk.ne.jp/~inoue/

If I turn off the cursors, the Lyric software complains about an Invalid
Cursor state.


--
Jim Hines
IT Mgr, WDTV NewsChannel 5
Your Hometown News

TEL:304.848.5000
FAX:304.842.7501
<http://www.wdtv.com>
<jhines@wdtv.com>

WDTV NewsChannel 5 is a CBS Affiliate

Re: CTID: Anyway to lock it?

От
Hiroshi Inoue
Дата:

Jim Hines wrote:
>
> > > Hmm, yes - it appears to be in inner_process_tokens(QueryParse *qp,
> > > QueryBuild *qb) in convert.c. I don't know what options might affect
> > > that though I'm afraid - do you know Hiroshi?
> >
> > The driver uses CTID and OID to implement updatable cursors.
> > Please turn off the *Updatable cursors* DSN option if you
> > don't like the behavior.
> >
> > regards,
> > Hiroshi Inoue
> >       http://w2422.nsk.ne.jp/~inoue/
>
> If I turn off the cursors, the Lyric software complains about an Invalid
> Cursor state.

If the software requires keyset-driven/static cursors with
optimistic concurrency control, you may have to turn on the
option or need the help of e.g. ODBC cursor library.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/