Alvaro Herrera wrote:
I see another hole in this area. See do_start_worker() -- there we only
consider the offsets limit to determine a database to be in
almost-wrapped-around state (causing emergency attention). If the
database in members trouble has no pgstat entry, it might get
On Wed, Jun 17, 2015 at 6:58 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Thomas Munro wrote:
Thanks. As mentioned elsewhere in the thread, I discovered that the
same problem exists for page boundaries, with a different error
message. I've tried the attached repro scripts on 9.3.0,
Bruce Momjian wrote:
On Sun, Jun 14, 2015 at 11:21:35AM -0400, Tom Lane wrote:
For pretty much the same reason, I'm not in favor of small caps either.
Even assuming we can do that consistently (which I bet we can't; we
do not have all that much control over how web browsers render HTML),
On Thu, Dec 11, 2014 at 10:24:20AM -0800, Jeff Janes wrote:
On Thu, Dec 11, 2014 at 8:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
2. The amount of pre-release testing we get from people outside the
hard-core development crowd seems to be continuing to decrease.
We were fortunate that somebody
Hi,
Currently the issue is easily reproducible. Steps to reproduce:
* Set some aggressive values for auto-vacuuming.
* Run a heavy database update/delete/insert queries. This leads to invoking
auto-vacuuming in quick successions.
* Change the system time to older for eg. 1995-01-01
Suddenly
On Tue, Jun 16, 2015 at 1:08 PM, Xiaoyulei xiaoyu...@huawei.com wrote:
In XidInMVCCSnapshot, it will check xid from tuple if is in snapshot-subxip.
It means tuple store subtransaction?
Tuple stores only the transaction id related to the operation. This
can be either main transaction id or sub
On Fri, Jun 12, 2015 at 9:02 PM, Fujii Masao wrote:
You want to draft a patch? Should I?
Please feel free to try that! :)
OK, so attached are a patch and a test case able to trigger easily the
error. Apply the patch and run the test case to reproduce the
following failure:
$ ERROR: could not
On 6/14/15 9:50 AM, Alvaro Herrera wrote:
+ values[0] = MultiXactState-oldestMultiXactId;
What about oldestOffset and offsetStopLimit? Seems those would be useful
too. Looks good other than that.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in
On 6/14/15 10:22 AM, Alvaro Herrera wrote:
To me, it feels like there are two different features here that would
be better separated. First, there's the idea of having a table that
gets auto-joined to other tables whenever you access it, so that the
user sees one really wide table but really
On 6/8/15 3:26 PM, Joel Jacobson wrote:
So I've heard from Magnus Hagander today IRL at our Stockholm PostgreSQL
User Group meeting where we discussed this idea. He told me the overhead
in the statistics collector is mainly when reading from it, not that
much when writing to it.
I've heard
Hello,
Maybe, For DBAs,
It might be better to show vacuum progress in pg_stat_activity.
(if we'd do, add a free-style column like progress ?) This column might also
be able to use for other long time commands like ANALYZE, CREATE/RE INDEX and
COPY. To realize this feature, we certainly need to
On Mon, Jun 15, 2015 at 08:47:12AM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
While Windows was the bellwether, harm potential is greater on non-Windows
systems. pg_perm_setlocale() sets the LC_CTYPE environment variable to help
PL/Perl avoid clobbering the process locale;
On Sun, Jun 14, 2015 at 11:21:35AM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
OK, new idea. What about, instead of having the last name be all-caps,
we have the last name start with an uppercase letter, then use smallcaps
for the rest of the last name:
On Sun, Jun 14, 2015 at 02:12:16PM -0400, Bruce Momjian wrote:
I have run a script to count the number of listitem items in the
major release notes of each major version of Postgres back to 7.4:
7.4280
8.0238
8.1187
8.2230
8.3237
14 matches
Mail list logo
