date:20190520

pldbgapi error

2019-05-20 Thread Prakash Ramakrishnan

Hi Team,

We are trying to install the pldbgapi extension in postgresql 11.3 server
but we getting below error,Please do the needful,

==> make USE_PGXS=1
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic -fPIC
-I/usr/pgsql-11/lib/pgxs/src/makefiles/../../src/pl/plpgsql/src -I. -I./
-I/usr/pgsql-11/include/server -I/usr/pgsql-11/include/internal
-D_GNU_SOURCE -I/usr/include/libxml2  -I/usr/include  -c -o
plpgsql_debugger.o plpgsql_debugger.c
plpgsql_debugger.c: In function ‘plpgsql_send_vars’:
plpgsql_debugger.c:263:16: error: ‘TRUE’ undeclared (first use in this
function)
isArg = TRUE;
^
plpgsql_debugger.c:263:16: note: each undeclared identifier is reported
only once for each function it appears in
plpgsql_debugger.c:244:4: warning: enumeration value ‘PLPGSQL_DTYPE_ROW’
not handled in switch [-Wswitch]
switch( estate->datums[i]->dtype )
^
plpgsql_debugger.c:244:4: warning: enumeration value ‘PLPGSQL_DTYPE_REC’
not handled in switch [-Wswitch]
plpgsql_debugger.c:244:4: warning: enumeration value
‘PLPGSQL_DTYPE_RECFIELD’ not handled in switch [-Wswitch]
plpgsql_debugger.c:244:4: warning: enumeration value
‘PLPGSQL_DTYPE_ARRAYELEM’ not handled in switch [-Wswitch]
plpgsql_debugger.c:244:4: warning: enumeration value
‘PLPGSQL_DTYPE_PROMISE’ not handled in switch [-Wswitch]
plpgsql_debugger.c: In function ‘find_datum_by_name’:
plpgsql_debugger.c:484:9: error: ‘PLPGSQL_DTYPE_EXPR’ undeclared (first use
in this function)
case PLPGSQL_DTYPE_EXPR:
 ^
plpgsql_debugger.c:462:3: warning: enumeration value
‘PLPGSQL_DTYPE_PROMISE’ not handled in switch [-Wswitch]
   switch( frame->datums[i]->dtype )
   ^
plpgsql_debugger.c: In function ‘print_rec’:
plpgsql_debugger.c:575:9: error: ‘PLpgSQL_rec’ has no member named ‘tupdesc’
  if (tgt->tupdesc == NULL)
 ^
plpgsql_debugger.c:578:29: error: ‘PLpgSQL_rec’ has no member named
‘tupdesc’
  for( attNo = 0; attNo < tgt->tupdesc->natts; ++attNo )
 ^
plpgsql_debugger.c:580:36: error: ‘PLpgSQL_rec’ has no member named ‘tup’
   char * extval = SPI_getvalue( tgt->tup, tgt->tupdesc, attNo + 1 );
^
plpgsql_debugger.c:580:46: error: ‘PLpgSQL_rec’ has no member named
‘tupdesc’
   char * extval = SPI_getvalue( tgt->tup, tgt->tupdesc, attNo + 1 );
  ^
In file included from /usr/pgsql-11/include/server/postgres.h:46:0,
 from plpgsql_debugger.c:12:
plpgsql_debugger.c:582:51: error: ‘PLpgSQL_rec’ has no member named
‘tupdesc’
   dbg_send( "v:%s.%s:%s\n", var_name, NameStr(
tgt->tupdesc->attrs[attNo]->attname ), extval ? extval : "NULL" );
   ^
/usr/pgsql-11/include/server/c.h:576:25: note: in definition of macro
‘NameStr’
 #define NameStr(name) ((name).data)


-- 
Thanks,
Prakash.R

Bug in documentation (trim(...))?

2019-05-20 Thread Johann Spies

The following illustrates the problem (removing double quotes from a
string):











*js=# select regexp_replace(regexp_replace( '"University of Cape Town"',
'^"', ''),'"$', ''); regexp_replace
- University of Cape Town(1 row)js=# trim(both '"'
from '"University of Cape Town"');ERROR:  syntax error at or near
"trim"LINE 1: trim(both '"' from '"University of Cape Town"');*

Example from the documentation:





*js=# trim(both 'xyz' from 'yxTomxx');ERROR:  syntax error at or near
"trim"LINE 1: trim(both 'xyz' from 'yxTomxx');^*
I would think that "trim" if it works in this case would be a cheaper
function than using rexexp_replace twice.

Or is there another way?

Regards
Johann
-- 
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)

pg_upgrade can result in early wraparound on databases with high transaction load

2019-05-20 Thread Jason Harvey

Hello,

This week I upgraded one of my large(2.8TB), high-volume databases from 9
to 11. The upgrade itself went fine. About two days later, we unexpectedly
hit transaction ID wraparound. What was perplexing about this was that the
age of our oldest `datfrozenxid` was only 1.2 billion - far away from where
I'd expect a wraparound. Curiously, the wraparound error referred to a
mysterious database of `OID 0`:

UPDATE ERROR: database is not accepting commands to avoid wraparound data
loss in database with OID 0

We were able to recover after a few hours by greatly speeding up our vacuum
on our largest table.

In a followup investigation I uncovered the reason we hit the wraparound so
early, and also the cause of the mysterious OID 0 message. When pg_upgrade
executes, it calls pg_resetwal to set the next transaction ID. Within
pg_resetwal is the following code:
https://github.com/postgres/postgres/blob/6cd404b344f7e27f4d64555bb133f18a758fe851/src/bin/pg_resetwal/pg_resetwal.c#L440-L450

This sets the controldata to have a fake database (OID 0) on the brink of
transaction wraparound. Specifically, after pg_upgrade is ran, wraparound
will occur within around 140 million transactions (provided the autovacuum
doesn't finish first). I confirmed by analyzing our controldata before and
after the upgrade that this was the cause of our early wraparound.

Given the size and heavy volume of our database, we tend to complete a
vacuum in the time it takes around 250 million transactions to execute.
With our tunings this tends to be rather safe and we stay well away from
the wraparound point under normal circumstances.

Unfortunately we had no obvious way of knowing that the upgrade would place
our database upon the brink of wraparound. In fact, since this info is only
persisted in the controldata, the only way to discover this state to my
knowledge would be to inspect the controldata itself. Other standard means
of monitoring for wraparound risk involve watching `pg_database` or
`pg_class`, which in this case tells us nothing helpful since the fake
database present in the controldata is not represented in those stats.

I'd like to suggest that either the pg_upgrade->pg_resetwal behaviour be
adjusted, or the pg_upgrade documentation highlight this potential
scenario. I'm happy to contribute code and/or documentation pull requests
to accomplish this.

41 matches

Mail list logo