Bruce Momjian <[EMAIL PROTECTED]> writes:
> I just noticed that if I do BEGIN;CREATE TABLE..., and then start VACUUM
> of the database in another psql session, the VACUUM hangs until the
> transaction completes. Is this expected?
Sure. You have a write lock on pg_class ... not to mention a few
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> So, may by add to pg_opclass two fields?
> bool is_varlena_key
> bool is_lossy_compress
Certainly not 'is_varlena_key', since that's not all the info you
need about the key datatype --- a type OID would be more appropriate.
But it seems to me that we sh
On Fri, 25 May 2001, Vinod Kurup wrote:
> Hi,
>
> I think I've come across a bug in plpgsql. It happens in the following
> situation:
>
> I have 2 tables, one with a foreign key to the other.
> Inside a plpgsql function, I do:
> update row in table2
> delete that row in table2
> delete th
> > Removing dead records from rollback segments should
> > be faster than from datafiles.
>
> Is it for better locality or are they stored in a different way ?
Locality - all dead data would be localized in one place.
> Do you think that there is some fundamental performance advantage
> in mak
> > > >Oracle has MVCC?
> > >
> > > With restrictions, yes.
> >
> > What restrictions? Rollback segments size?
>
> No, that is not the whole story. The problem with their
> "rollback segment approach" is, that they do not guard against
> overwriting a tuple version in the rollback segment.
> Th
> Do we want to head for an overwriting storage manager?
>
> Not sure.
>
> Advantages: UPDATE has easy space reuse because usually done
> in-place, no index change on UPDATE unless key is changed.
>
> Disadvantages: Old records have to be stored somewhere for MVCC use.
> Could limit transa
> So, may by add to pg_opclass two fields?
> bool is_varlena_key
> bool is_lossy_compress
Sorry, I was wrong. In GiST, index_formtuple doesn't know about size of
fixed-length type of keys, because only loadable module has information
about structure of key. So, may be it needs to have funct
> What I find just about as objectionable as the old haskeytype hack is
> that the user has to tell you whether the index is lossy or not. This
> should be a property available from the system catalogs. Not sure where
> to put it; do we need another column in pg_opclass, or is someplace
> other
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> 2) check if the status of handle returned PQsetdbLogin is
>CONNECTION_BAD closePGconn. if so, do not call pqPuts (and
>pqFlush)
I like this approach. The other way, you'd have to be sure that all
failure paths close the socket before returning;
"Oliver Elphick" <[EMAIL PROTECTED]> writes:
> psql:x.sql:13: pqReadData() -- backend closed the channel unexpectedly.
This is the already-fixed-in-7.1.2 problem with empty SELECTs in
plpgsql.
regards, tom lane
---(end of broadcast)---
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> compress fully supports fixed-length and varlena types. The problem is
> index_formtuple - types of key and column could be different
> (example - polygon, where column has varlena type but key is fixed-length)
Right. There used to be a horrible kluge
Sometimes PQfinish() does not return forever in the following program.
conn = PQsetdbLogin();
if(PQstatus(conn) == CONNECTION_BAD)
{
PQfinish(conn); /* blocks here */
}
PQfinish calls closePGconn that call pqPuts. pqPuts calls select(2)
and it never returns if a connection associated wit
> > >> Impractical ? Oracle does it.
> > >
> > >Oracle has MVCC?
> >
> > With restrictions, yes.
>
> What restrictions? Rollback segments size?
No, that is not the whole story. The problem with their "rollback segment approach" is,
that they do not guard against overwriting a tuple version in
13 matches
Mail list logo
