date:20120326

Re: [HACKERS] Reporting WAL file containing checkpoint's REDO record in pg_controldata's result

2012-03-26 Thread Magnus Hagander

On Fri, Mar 23, 2012 at 18:05, Fujii Masao masao.fu...@gmail.com wrote:
 On Sat, Mar 24, 2012 at 1:49 AM, Robert Haas robertmh...@gmail.com wrote:
 On Fri, Mar 23, 2012 at 12:42 PM, Fujii Masao masao.fu...@gmail.com wrote:
 On Fri, Mar 23, 2012 at 9:41 PM, Robert Haas robertmh...@gmail.com wrote:
 On Fri, Mar 23, 2012 at 6:13 AM, Fujii Masao masao.fu...@gmail.com wrote:
 On Fri, Mar 23, 2012 at 5:56 PM, Magnus Hagander mag...@hagander.net 
 wrote:
 Might it be a good idea to put it on it's own row instead of changing
 the format of an existing row, in order not to break scripts and
 programs that are parsing the previous output?

 Good idea! What row name should we use for the WAL file containing
 REDO record? Latest checkpoint's REDO file?

 Sounds good to me.  I like the idea, too.  The status quo is an
 unnecessary nuisance, so this will be a nice usability improvement.

 Attached patch adds new row Latest checkpoint's REDO WAL segment: into
 the result of pg_controldata. I used the term WAL segment for the row name
 instead of file because WAL segment is used in another row Bytes per 
 WAL
 segment:. But better name?

 s/segment/file/g?

 Yep, file might be more intuitive for a user than segment. Attached is the
 file version of the patch.

We're already using file to mean something different *internally*,
don't we? And since pg_controldata shows fairly internal information,
I'm not sure this is the best idea.

Maybe compromise and call it segment file - that is both easier to
understand than segment, and not actually using a term that means
something else...

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_terminate_backend for same-role

2012-03-26 Thread Jeff Davis

On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
 On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao masao.fu...@gmail.com wrote:
  On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina dan...@heroku.com wrote:
  Parallel to pg_cancel_backend, it'd be nice to allow the user to just
  outright kill a backend that they own (politely, with a SIGTERM),
  aborting any transactions in progress, including the idle transaction,
  and closing the socket.
 
  +1
 
 Here's a patch implementing the simple version, with no more guards
 against signal racing than have been seen previously.  The more
 elaborate variants to close those races is being discussed in a
 parallel thread, but I thought I'd get this simple version out there.

Review:

After reading through the threads, it looks like there was no real
objection to this approach -- pid recycling is not something we're
concerned about.

I think you're missing a doc update though, in func.sgml:

For the less restrictive functionpg_cancel_backend/, the role of an
active backend can be found from
the structfieldusename/structfield column of the
structnamepg_stat_activity/structname view.

Also, high-availability.sgml makes reference to pg_cancel_backend(), and
it might be worthwhile to add an ...and pg_terminate_backend() there.

Other than that, it looks good to me.

Regards,
Jeff Davis



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: [COMMITTERS] pgsql: Replace empty locale name with implied value in CREATE DATABASE

2012-03-26 Thread Stefan Kaltenbrunner

On 03/26/2012 03:47 AM, Tom Lane wrote:
 Replace empty locale name with implied value in CREATE DATABASE and initdb.
 
 setlocale() accepts locale name  as meaning the locale specified by the
 process's environment variables.  Historically we've accepted that for
 Postgres' locale settings, too.  However, it's fairly unsafe to store an
 empty string in a new database's pg_database.datcollate or datctype fields,
 because then the interpretation could vary across postmaster restarts,
 possibly resulting in index corruption and other unpleasantness.
 
 Instead, we should expand  to whatever it means at the moment of calling
 CREATE DATABASE, which we can do by saving the value returned by
 setlocale().
 
 For consistency, make initdb set up the initial lc_xxx parameter values the
 same way.  initdb was already doing the right thing for empty locale names,
 but it did not replace non-empty names with setlocale results.  On a
 platform where setlocale chooses to canonicalize the spellings of locale
 names, this would result in annoying inconsistency.  (It seems that popular
 implementations of setlocale don't do such canonicalization, which is a
 pity, but the POSIX spec certainly allows it to be done.)  The same risk
 of inconsistency leads me to not venture back-patching this, although it
 could certainly be seen as a longstanding bug.
 
 Per report from Jeff Davis, though this is not his proposed patch.

hmm seems like this commit broken quagga:


http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quaggadt=2012-03-26%2002%3A03%3A04


Stefan

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Speed dblink using alternate libpq tuple storage

2012-03-26 Thread Kyotaro HORIGUCHI

Hello, This is new version of patch for dblink using row processor.

 - Use palloc to allocate temporaly memoriy blocks.

 - Memory allocation is now done in once. Preallocate a block of
   initial size and palloc simplified reallocation code.

 - Resurrected the route for command invoking. And small
   adjustment of behavior on error.

 - Modification to fix connection name missing bug is removed out
   to another patch.

 - Commenting on the functions skipped over by lonjmp is
   withholded according to Marko's discussion.

 - rebased to e8476f46fc847060250c92ec9b310559293087fc

dblink_use_rowproc_20120326.patch - dblink row processor patch.
dblink_connname_20120326.patch- dblink connname fix patch.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/contrib/dblink/dblink.c b/contrib/dblink/dblink.c
index 36a8e3e..dd73aa5 100644
--- a/contrib/dblink/dblink.c
+++ b/contrib/dblink/dblink.c
@@ -63,11 +63,23 @@ typedef struct remoteConn
 	bool		newXactForCursor;		/* Opened a transaction for a cursor */
 } remoteConn;
 
+typedef struct storeInfo
+{
+	Tuplestorestate *tuplestore;
+	int nattrs;
+	MemoryContext oldcontext;
+	AttInMetadata *attinmeta;
+	char* valbuf;
+	int valbuflen;
+	char **cstrs;
+	bool error_occurred;
+	bool nummismatch;
+} storeInfo;
+
 /*
  * Internal declarations
  */
 static Datum dblink_record_internal(FunctionCallInfo fcinfo, bool is_async);
-static void materializeResult(FunctionCallInfo fcinfo, PGresult *res);
 static remoteConn *getConnectionByName(const char *name);
 static HTAB *createConnHash(void);
 static void createNewConnection(const char *name, remoteConn *rconn);
@@ -90,6 +102,10 @@ static char *escape_param_str(const char *from);
 static void validate_pkattnums(Relation rel,
    int2vector *pkattnums_arg, int32 pknumatts_arg,
    int **pkattnums, int *pknumatts);
+static void initStoreInfo(storeInfo *sinfo, FunctionCallInfo fcinfo);
+static void finishStoreInfo(storeInfo *sinfo);
+static int storeHandler(PGresult *res, PGrowValue *columns, void *param);
+
 
 /* Global */
 static remoteConn *pconn = NULL;
@@ -111,6 +127,9 @@ typedef struct remoteConnHashEnt
 /* initial number of connection hashes */
 #define NUMCONN 16
 
+/* Initial block size for value buffer in storeHandler */
+#define INITBUFLEN 64
+
 /* general utility */
 #define xpfree(var_) \
 	do { \
@@ -503,6 +522,7 @@ dblink_fetch(PG_FUNCTION_ARGS)
 	char	   *curname = NULL;
 	int			howmany = 0;
 	bool		fail = true;	/* default to backward compatible */
+	storeInfo   storeinfo;
 
 	DBLINK_INIT;
 
@@ -559,15 +579,51 @@ dblink_fetch(PG_FUNCTION_ARGS)
 	appendStringInfo(buf, FETCH %d FROM %s, howmany, curname);
 
 	/*
+	 * Result is stored into storeinfo.tuplestore instead of
+	 * res-result retuned by PQexec below
+	 */
+	initStoreInfo(storeinfo, fcinfo);
+	PQsetRowProcessor(conn, storeHandler, storeinfo);
+
+	/*
 	 * Try to execute the query.  Note that since libpq uses malloc, the
 	 * PGresult will be long-lived even though we are still in a short-lived
 	 * memory context.
 	 */
-	res = PQexec(conn, buf.data);
+	PG_TRY();
+	{
+		res = PQexec(conn, buf.data);
+	}
+	PG_CATCH();
+	{
+		ErrorData *edata;
+
+		finishStoreInfo(storeinfo);
+		edata = CopyErrorData();
+		FlushErrorState();
+
+		/* Skip remaining results when storeHandler raises exception. */
+		PQskipResult(conn, TRUE);
+		ReThrowError(edata);
+	}
+	PG_END_TRY();
+
+	finishStoreInfo(storeinfo);
+
 	if (!res ||
 		(PQresultStatus(res) != PGRES_COMMAND_OK 
 		 PQresultStatus(res) != PGRES_TUPLES_OK))
 	{
+		/* finishStoreInfo saves the fields referred to below. */
+		if (storeinfo.nummismatch)
+		{
+			/* This is only for backward compatibility */
+			ereport(ERROR,
+	(errcode(ERRCODE_DATATYPE_MISMATCH),
+	 errmsg(remote query result rowtype does not match 
+			the specified FROM clause rowtype)));
+		}
+
 		dblink_res_error(conname, res, could not fetch from cursor, fail);
 		return (Datum) 0;
 	}
@@ -579,8 +635,8 @@ dblink_fetch(PG_FUNCTION_ARGS)
 (errcode(ERRCODE_INVALID_CURSOR_NAME),
  errmsg(cursor \%s\ does not exist, curname)));
 	}
+	PQclear(res);
 
-	materializeResult(fcinfo, res);
 	return (Datum) 0;
 }
 
@@ -640,6 +696,7 @@ dblink_record_internal(FunctionCallInfo fcinfo, bool is_async)
 	remoteConn *rconn = NULL;
 	bool		fail = true;	/* default to backward compatible */
 	bool		freeconn = false;
+	storeInfo   storeinfo;
 
 	/* check to see if caller supports us returning a tuplestore */
 	if (rsinfo == NULL || !IsA(rsinfo, ReturnSetInfo))
@@ -660,6 +717,7 @@ dblink_record_internal(FunctionCallInfo fcinfo, bool is_async)
 		{
 			/* text,text,bool */
 			DBLINK_GET_CONN;
+			conname = text_to_cstring(PG_GETARG_TEXT_PP(0));
 			sql = text_to_cstring(PG_GETARG_TEXT_PP(1));
 			fail = PG_GETARG_BOOL(2);
 		}
@@ -715,164 +773,229 @@ dblink_record_internal(FunctionCallInfo fcinfo, bool is_async)
 	rsinfo-setResult = NULL;
 	rsinfo-setDesc = NULL;
 
-	/* synchronous query, or async result

Re: [HACKERS] Command Triggers, v16

2012-03-26 Thread Robert Haas

On Sun, Mar 25, 2012 at 12:15 PM, Andres Freund and...@2ndquadrant.com wrote:
 On Friday, March 16, 2012 10:40:46 AM Dimitri Fontaine wrote:
  This will have the effect of calling triggers outside of alphabetic
  order. I don't think thats a good idea even if one part is ANY and the
  other a specific command.
  I don't think there is any reason anymore to separate the two? The only

  callsite seems to look like:
 The idea is to have a predictable ordering of command triggers. The code
 changed in the patch v16 (you pasted code from git in between v15 and
 v16, I cleaned it up) and is now easier to read:

                 case CMD_TRIGGER_FIRED_BEFORE:
                         whenstr = BEFORE;
                         procs[0] = cmd-before_any;
                         procs[1] = cmd-before;
                         break;

                 case CMD_TRIGGER_FIRED_AFTER:
                         whenstr = AFTER;
                         procs[0] = cmd-after;
                         procs[1] = cmd-after_any;
                         break;

 So it's BEFORE ANY then BEFORE command then AFTER command then AFTER
 ANY. That's an arbitrary I made and we can easily reconsider. Triggers
 are called in alphabetical order in each “slot” here.

 In my mind it makes sense to have ANY triggers around the specific
 triggers, but it's hard to explain why that feels better.
 I still think this would be a mistake. I don't have a hard time imagining
 usecases where a specific trigger should be called before or after an ANY
 trigger because e.g. it wants to return a more specific error or doesn't want
 to check all preconditions already done by the ANY trigger... All that would
 be precluded by enforcing a strict ordering between ANY and specific triggers.
 I don't see a use-case that would benefit from the current behaviour...

Dimitri's proposed behavior would be advantageous if you have an ANY
trigger that wants to take over the world and make sure that nobody
else can run before it.  I think, though, that's not a case we want to
cater to - all of this stuff requires superuser privileges anyway, so
we should assume that the DBA knows what he's doing.  So +1 for making
it strictly alphabetical, as we do with other triggers.  Everything
that can be done under Dimitri's proposal can also be done in that
scheme, but the reverse is not true.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Reporting WAL file containing checkpoint's REDO record in pg_controldata's result

2012-03-26 Thread Robert Haas

On Mon, Mar 26, 2012 at 2:50 AM, Magnus Hagander mag...@hagander.net wrote:
 s/segment/file/g?

 Yep, file might be more intuitive for a user than segment. Attached is 
 the
 file version of the patch.

 We're already using file to mean something different *internally*,
 don't we? And since pg_controldata shows fairly internal information,
 I'm not sure this is the best idea.

 Maybe compromise and call it segment file - that is both easier to
 understand than segment, and not actually using a term that means
 something else...

It's also kind of wordy.  I think file is fine.  There are a few
references to xlogid indicating a file number, but the actual field
name is just xlogid.  We also use the term file to mean the other
thing, as in XLOGfileslop, and I have a hard time believing anyone's
really going to get confused about what is meant here.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Support for foreign keys with arrays

2012-03-26 Thread Gabriele Bartolini


Hello Tom,


 I started to look at this patch a bit.  I'm quite confused by the fact
 that some, but not all, of the possible FK action types now come in an
 EACH variant.  This makes no sense at all to me.  ISTM that EACH is a
 property of the FK constraint as a whole, that is that it says the
 constraint is from array elements on the referencing side to column
 values on the referenced side, rather than the normal case of column
 values to column values.


The specification that Gianni posted applies only to v5 of the patch.
The original idea was indeed to have the whole foreign key to be defined 
with an EACH property (initially we were actually thinking of the ARRAY 
keyword following your advice, then for grammar reasons we opted for EACH).
However, during the actual development we faced some difficulties with 
multi-column foreign keys.
Through discussions on this list and with the reviewer we opted to allow 
the EACH keyword at column level.
We started with the case where at most one column is EACH, which is 
easier to understand.
The case of two or more EACH columns in the same foreign key has been 
left open for future development.



 Why would the possible actions be affected, and why only these?


We  had to add the EACH variant to two actions (EACH CASCADE and EACH 
SET  NULL), in order to leave users the flexibility to choose the 
operation  to be performed in case of delete or update of one or more 
elements from  the referenced table.
Some  users indeed might prefer that, in case a referenced row is 
deleted,  the whole row is deleted (therefore they'd use the standard 
CASCADE  action). Others mights simply require that references to that 
row is  removed from the referencing array (therefore they'd use the 
variant  EACH CASCADE action). The same concept applies for SET NULL 
(the whole  array is set to NULL) and EACH SET NULL (referencing 
elements are set to  NULL).


Thank you.

Cheers,
Gabriele

--
 Gabriele Bartolini - 2ndQuadrant Italia
 PostgreSQL Training, Services and Support
 gabriele.bartol...@2ndquadrant.it | www.2ndQuadrant.it

Re: [HACKERS] Reporting WAL file containing checkpoint's REDO record in pg_controldata's result

2012-03-26 Thread Tom Lane

Robert Haas robertmh...@gmail.com writes:
 On Mon, Mar 26, 2012 at 2:50 AM, Magnus Hagander mag...@hagander.net wrote:
 s/segment/file/g?

 We're already using file to mean something different *internally*,
 don't we? And since pg_controldata shows fairly internal information,
 I'm not sure this is the best idea.
 
 Maybe compromise and call it segment file - that is both easier to
 understand than segment, and not actually using a term that means
 something else...

 It's also kind of wordy.  I think file is fine.

+1 for file.  I think the internal usage of file to mean roughly
4GB worth of WAL is going to go away soon anyway, as there won't be
much reason to worry about the concept once LSN arithmetic is 64-bit.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Replace empty locale name with implied value in CREATE DATABASE

2012-03-26 Thread Tom Lane

Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
 On 03/26/2012 03:47 AM, Tom Lane wrote:
 Replace empty locale name with implied value in CREATE DATABASE and initdb.

 hmm seems like this commit broken quagga:
 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quaggadt=2012-03-26%2002%3A03%3A04

Hm, it's hard to see how that patch would have affected the
create-conversions step but not any preceding one.  Can you provide
a stack trace from the core dump?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Weak-memory specific problem in ResetLatch/WaitLatch (follow-up analysis)

2012-03-26 Thread Robert Haas

On Sat, Mar 24, 2012 at 1:01 PM, Michael Tautschnig m...@debian.org wrote:
Here, the two writes on Worker 0 corresponds to lines 15 and 16. And indeed
line 16 is exactly the call to SetLatch. For solving problem 1, the mp idiom,
the following options are possible (in all cases stronger synchronisation
primitives may be used, i.e., the strongest Power barrier, sync, may be used,
or
lwsync may be used instead of an address dependency):

1. An lwsync at the beginning of SetLatch, and lwsync in ResetLatch
(preferably
after the write).
2. An lwsync at the beginning of SetLatch, and an address dependency in
ResetLatch.

To address the second problem, the lb idiom, an address dependency has to be
put
either in WaitLatch or SetLatch.

To fix both problems, the performance-wise cheapest option would thus be
placing
an address dependency in ResetLatch and an lwsync in SetLatch. For practical
reasons, however, placing an lwsync in both places (at the beginning of
SetLatch
and after the write in ResetLatch) might be preferable, as address
dependencies
may be optimised away by the C compiler or require inline assembly in a form
not
as easy to factor out as lwsync, plus the interface of ResetLatch would have
to
be amended.

In summary, we were thus able to show that both points marked with XXX there
really ought to be a memory barrier in

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4e15a4db5e65e43271f8d20750d6500ab12632d0

are the appropriate points to place memory synchronisation primitives, and
picking an lwsync-equivalent in both cases is sound and does not require any
other modifications.

It's interesting that you've concluded that memory barriers are needed
in exactly the two places that Tom concluded they were needed. I
think your analysis of what type of memory barrier is required is
faulty, however. In your version of the code, setting the latch is
represented by a single store. However, SetLatch() is more
complicated than that - it does a load, and depending on the results
of the load, it does a store and then maybe a system call. I suspect
that if you change line 16 to read:

if (!latch[i+1 % WORKERS]) latch[i+1 % WORKERS] = 1;

...then your tool will tell you that you need a full barrier before
that rather than just a store/store barrier.

After staring at this for a while, I am fairly certain that
ResetLatch() needs a full barrier, too. It seems to me that the
formal hazard you're guarding against by inserting an lwsync here is
the load/load dependency between loading the latch and loading the
flag. In your version, that's probably OK, but in real life, it's
not, because WaitLatch() can wake up for a variety of reasons, not
just because the latch has been set. So the following is possible:
worker #1 executes line 14, worker #2 wakes up after line 19 and
executes line 10 and then performs the load on line 12 before the
store on line 11 (since the lwsync you propose doesn't act as a
store/load barrier), worker #1 executes lines 15 and 16, worker #2 now
does the store on line 11. At this point we are hosed, because worker
#2 has clobbered worker #1's attempt to set the latch without seeing
that the flag is set, and everybody goes into the tank and waits
forever (or until worker #2 receives another wake-up from some other
source, at which point we'll be back in business).

I proposed before that a barrier was also needed at the start of
WaitLatch(), to guard against a load/load dependency between loading
the flag (line 12) and loading the latch (line 19). Our version of
WaitLatch doesn't busy-wait, so the concern is approximately that we
could do the load at line 19, conclude that no waiting is needed, then
do the load at line 12, do the store at line 14, and then go to sleep.
That actually can't happen with this exact code, because if we were
to execute line 14 then we'd also hit the proposed lwsync at line 16
and so the loads would happen in order. But lines 15-16 need not be
there: the most common use of this machinery is to hand of requests
from a foreground process to a background process, and the background
process need not be friendly enough to supply a barrier after checking
the flag and before calling WaitLatch(). I think a load/load barrier
here would be enough, but we've actually got a full barrier, because
WaitLatch calls drainSelfPipe() before checking the flag, and as noted
in the comments we assume that a system call acts as a full barrier.
So there's no live bug here, but I think it's worth noting that you
can't conclude that WaitLatch() doesn't need a barrier on the basis of
this simplified example.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Odd out of memory problem.

2012-03-26 Thread Andrew Dunstan



I'm not sure if this is a bug, but I have wrestling with this problem 
for a client.


Platform is Windows Servers 2003 64 bit, PostgreSQL 8.4.8., 4Gb RAM, 
running on an Amazon VM.


Shared buffers: 512Mb, work_mem: 25Mb. There are only a handful of 
connections to the database, and no other activity.


We are seeing the error shown below. The table in question has two 
columns (Oid, int) and roughly 43m rows. The only other thing remarkable 
about the settings is that effective_cache_size is set to 5Gb, which is 
clearly too high, but surely that shouldn't cause a memory error.


I'm really perplexed as to why this fairly simple query should cause an 
out of memory error:


   select loid, max(pageno) from ldata group by loid order by 2 desc
   limit 10;

I can't see what I might be missing.


cheers

andrew

   TopMemoryContext: 49816 total in 6 blocks; 5384 free (7 chunks);
   44432 used
  TopTransactionContext: 8192 total in 1 blocks; 7696 free (0
   chunks); 496 used
  Record information cache: 8192 total in 1 blocks; 1800 free (0
   chunks); 6392 used
  Type information cache: 8192 total in 1 blocks; 1800 free (0
   chunks); 6392 used
  Operator class cache: 8192 total in 1 blocks; 3848 free (0
   chunks); 4344 used
  Operator lookup cache: 24576 total in 2 blocks; 14072 free (6
   chunks); 10504 used
  MessageContext: 40960 total in 3 blocks; 29920 free (6 chunks);
   11040 used
  smgr relation table: 8192 total in 1 blocks; 2816 free (0
   chunks); 5376 used
  TransactionAbortContext: 32768 total in 1 blocks; 32752 free (0
   chunks); 16 used
  Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used
  PortalMemory: 8192 total in 1 blocks; 8040 free (0 chunks); 152 used
PortalHeapMemory: 1024 total in 1 blocks; 920 free (0 chunks);
   104 used
  ExecutorState: 8192 total in 1 blocks; 2144 free (1 chunks);
   6048 used
TupleSort: 40984 total in 3 blocks; 24208 free (10 chunks);
   16776 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
AggContext: 864018432 total in 127 blocks; 3400 free (110
   chunks); 864015032 used
  TupleHashTable: 619175960 total in 95 blocks; 821528 free
   (331 chunks); 618354432 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
  Relcache by OID: 8192 total in 1 blocks; 3376 free (0 chunks);
   4816 used
  CacheMemoryContext: 667696 total in 20 blocks; 169960 free (2
   chunks); 497736 used
pg_shdepend_reference_index: 1024 total in 1 blocks; 240 free
   (0 chunks); 784 used
pg_depend_depender_index: 1024 total in 1 blocks; 152 free (0
   chunks); 872 used
pg_depend_reference_index: 1024 total in 1 blocks; 152 free (0
   chunks); 872 used
pg_largeobject_loid_pn_index: 1024 total in 1 blocks; 280 free
   (0 chunks); 744 used
pg_database_datname_index: 1024 total in 1 blocks; 344 free (0
   chunks); 680 used
pg_index_indrelid_index: 1024 total in 1 blocks; 304 free (0
   chunks); 720 used
pg_opclass_am_name_nsp_index: 1024 total in 1 blocks; 152 free
   (0 chunks); 872 used
pg_foreign_data_wrapper_name_index: 1024 total in 1 blocks; 344
   free (0 chunks); 680 used
pg_enum_oid_index: 1024 total in 1 blocks; 344 free (0 chunks);
   680 used
pg_class_relname_nsp_index: 1024 total in 1 blocks; 240 free (0
   chunks); 784 used
pg_foreign_server_oid_index: 1024 total in 1 blocks; 344 free
   (0 chunks); 680 used
pg_statistic_relid_att_index: 1024 total in 1 blocks; 240 free
   (0 chunks); 784 used
pg_cast_source_target_index: 1024 total in 1 blocks; 240 free
   (0 chunks); 784 used
pg_language_name_index: 1024 total in 1 blocks; 344 free (0
   chunks); 680 used
pg_authid_oid_index: 1024 total in 1 blocks; 304 free (0
   chunks); 720 used
pg_amop_fam_strat_index: 1024 total in 1 blocks; 88 free (0
   chunks); 936 used
pg_index_indexrelid_index: 1024 total in 1 blocks; 304 free (0
   chunks); 720 used
pg_ts_template_tmplname_index: 1024 total in 1 blocks; 280 free
   (0 chunks); 744 used
pg_ts_config_map_index: 1024 total in 1 blocks; 192 free (0
   chunks); 832 used
pg_opclass_oid_index: 1024 total in 1 blocks; 304 free (0
   chunks); 720 used
pg_foreign_data_wrapper_oid_index: 1024 total in 1 blocks; 344
   free (0 chunks); 680 used
pg_auth_members_member_role_index: 1024 total in 1 blocks; 280
   free (0 chunks); 744 used
pg_ts_dict_oid_index: 1024 total in 1 blocks; 344 free (0
   chunks); 680 used
pg_conversion_default_index: 1024 total in 1 blocks; 128 free
   (0 chunks); 896 used
pg_operator_oprname_l_r_n_index: 1024 total in 1 blocks; 88
   free (0 chunks); 936 used

Re: [HACKERS] heap_freeze_tuple locking requirements

2012-03-26 Thread Robert Haas

On Fri, Mar 23, 2012 at 11:02 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
 Excerpts from Robert Haas's message of mié mar 21 21:50:24 -0300 2012:
 heap_freeze_tuple() was apparently designed at one point to cope with
 being called with either a shared or exclusive buffer lock.  But none
 of the current callers call it with a shared lock; they all call it
 with an exclusive lock, except for the heap-rewrite code which doesn't
 take (or need) a lock at all.

 Since this is just dead code removal, I propose to apply this to 9.2.

 +1

Thanks, done.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

66 matches

Mail list logo