Re: age(xid) on hot standby

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: age(xid) on hot standby
Date: 2012-01-19 03:56:52
Message-ID: 7473.1326945412@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> I think we should apply the patch to return the correct SQLCODE in all
> cases, even if its supposedly not possible.

[ shrug... ] My opinion about that has not changed. Those are internal
sanity checks, and as such, ERRCODE_INTERNAL_ERROR is exactly the right
thing for them. If there are paths that can reach that code, we need to
find them and plug the holes with appropriate user-facing error checks
that say what it is the user is not supposed to do. In this example,
if we had decided that the right answer should be for age() to not be
allowed on standbys, then an error saying exactly that would be an
appropriate user-facing error. "You're not supposed to acquire a
transaction ID" is not intelligible to the average user, and giving it
another error code doesn't improve that situation.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2012-01-19 04:29:57 Re: Strange primary key constraint influence to grouping
Previous Message Noah Misch 2012-01-19 02:11:35 Re: foreign key locks, 2nd attempt