, simple because most databases are
not terribly sensitive to the issue.
Cheers,
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(Redirected from Bugs to Hackers, as it seems not to be the same bug
as the original one.)
On Mon, Jun 9, 2014 at 3:50 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Jeff Janes wrote:
This patch seems to solve a problem I've also been having with non-existent
pg_multixact/members/13D35
and did
one very simple and useful thing: avoiding the printing of whole
screens full of hyphens when in 'expanded mode'. If we end up
reverting the other parts of this patch, hopefully we don't lose that
part.
Cheers,
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
.
So I propose to do that change as a separate commit. Per attached. This
has no functional changes, it's just refactoring.
Any objections?
This commit, or a related one, changed the default (i.e. commented out)
nature of:
#define WAL_DEBUG
Cheers,
Jeff
it yet, but is there a fundamental reason for
that or just a round tuit problem?
Cheers,
Jeff
have vague notions of what might be, then my notion probably
does not block your code.)
Cheers,
Jeff
On Monday, June 9, 2014, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com javascript:; writes:
On Sun, Jun 8, 2014 at 5:36 AM, David Rowley dgrowle...@gmail.com
javascript:; wrote:
The attached patch allows an ANTI-join plan to be generated in cases
like:
CREATE TABLE
On Fri, May 30, 2014 at 8:08 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 05/29/2014 07:39 PM, Jeff Janes wrote:
It also implicitly tested the xlog parallel write slots thing, as that is
common code to all recovery.
During development, I hit a lot of bugs in that patch
On Sun, May 25, 2014 at 8:40 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
While debugging the B-tree bug that Jeff Janes reported (
http://www.postgresql.org/message-id/CAMkU=1y=VwF07Ay+Cpqk_
7fpihrctmssv9y99sbghitkxpb...@mail.gmail.com), a new issue came up:
If you reach
are updated with heap_inplace_update in these
cases.
The page gets a new LSN, but the tuples do not get a new transaction ID.
Cheers,
Jeff
On Fri, May 30, 2014 at 8:09 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Sat, May 31, 2014 at 3:51 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, May 29, 2014 at 8:15 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Thu, May 29, 2014 at 10:09 PM, Jeff Janes jeff.ja...@gmail.com
On Mon, Jun 2, 2014 at 9:14 AM, Andres Freund and...@2ndquadrant.com
wrote:
Hi,
On 2014-06-02 09:03:25 -0700, Jeff Janes wrote:
GNU make does not realize that pg_xlogdump depends
on src/backend/access/rmgrdesc/heapdesc.c. (I don't know how or why it
has
that dependency, but changes
On Thu, May 29, 2014 at 8:15 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Thu, May 29, 2014 at 10:09 PM, Jeff Janes jeff.ja...@gmail.com wrote:
What features in 9.4 need more beta testing for recovery?
Another feature which have interaction with recovery is reduced WAL
for Update
checksum error in recovery with btree index
9.4 checksum errors in recovery with gin index
Cheers,
Jeff
prevent the warning.
Wouldn't it be better to use pgsocket rather than SOCKET?
Cheers,
Jeff
if it didn't,
the page would not be eligible for this treatment) and so the possibly torn
page will get overwritten in full.
Cheers,
Jeff
of their custom benchmark file
with a backslash? I'm having a hard time seeing what, other than malice,
would prod someone to do that.
Cheers,
Jeff
do too much performance testing of this, is it a correct
approach? It seems too easy.
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
On Sun, May 25, 2014 at 7:16 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 05/21/2014 10:22 PM, Jeff Janes wrote:
Testing partial-write crash-recovery in 9.4 (e12d7320ca494fd05134847e30)
with foreign keys, I found some btree index corruption.
...
https://drive.google.com
On Sunday, May 25, 2014, Heikki Linnakangas
hlinnakan...@vmware.comjavascript:_e(%7B%7D,'cvml','hlinnakan...@vmware.com');
wrote:
While debugging the B-tree bug that Jeff Janes reported (
http://www.postgresql.org/message-id/CAMkU=1y=VwF07Ay+Cpqk_
7fpihrctmssv9y99sbghitkxpb...@mail.gmail.com
On 5/25/14, 11:44 AM, Andres Freund wrote:
Hi,
On 2014-05-23 08:23:57 -0600, Jeff Ross wrote:
UDB=# \x
Expanded display is on.
UDB=# SELECT attrelid::regclass, attname, attnum, attlen, *
FROM pg_attribute
WHERE attrelid = 'masterairportlist'::regclass
ORDER BY attnum ASC;
UDB=#
[ RECORD 1
On 5/23/14, 7:36 AM, Andres Freund wrote:
Any chance you could, *before* you create the toast table, do a:
SELECT attrelid::regclass, attname, attnum, attlen, *
FROM pg_attribute
WHERE attrelid = 'a'::regclass
ORDER BY attnum ASC;
Where 'a' is replaced by the affected table?
Greetings,
On 5/23/14, 7:21 AM, Bruce Momjian wrote:
On Thu, May 22, 2014 at 09:20:38AM -0600, Jeff Ross wrote:
I just tested ALTER TABLE in 8.4 and it does create a toast table for
this case in 9.4:
CREATE TABLE test (x CHAR(10));
ALTER TABLE test ALTER COLUMN x TYPE CHAR(8000);
I
On 5/21/14, 2:37 PM, Bruce Momjian wrote:
On Wed, May 21, 2014 at 04:23:34PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Wed, May 21, 2014 at 10:56:59AM -0600, Jeff Ross wrote:
Yes, using 9.3's pg_dump of 8.4 and applying it to both an 8.4 and a
9.3 cluster
On 5/21/14, 9:13 AM, Bruce Momjian wrote:
On Wed, May 21, 2014 at 09:11:05AM -0600, Jeff Ross wrote:
-- For binary upgrade, set heap's relfrozenxid
UPDATE pg_catalog.pg_class
SET relfrozenxid = '1944'
WHERE oid = 'contact_email'::pg_catalog.regclass;
-- For binary upgrade, set toast's
wraps before this problem was encountered, so if that is
the problem it must be probabilistic rather than deterministic.
https://drive.google.com/folderview?id=0Bzqrh1SO9FcENWd6ZXlwVWpxU0Eusp=sharing
Cheers,
Jeff
if there are any non-empty ranges, in which case it has
*no* empty ranges
Note: I am using allTheSame in the logical sense; perhaps the flag is
an internal optimization that we can't rely on.
Regards,
Jeff Davis
*** a/src/backend/utils/adt/rangetypes_spgist.c
--- b/src/backend/utils/adt
On Tue, 2014-05-20 at 09:52 -0700, Jeff Davis wrote:
2. Why would any tuple have 2 nodes? If there are some non-empty ranges,
why not make a centroid and have 4 or 5 nodes?
This is slightly more complicated than I thought, because we need to do
something about the root node if a bunch of empty
and it
restored with psql to 9.3.4 with no issues but the overall migration
will really be too big to go this route.
Any ideas?
Thanks!
Jeff Ross
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On 5/20/14, 2:22 PM, Bruce Momjian wrote:
On Tue, May 20, 2014 at 12:59:31PM -0600, Jeff Ross wrote:
Removing support functions from new cluster ok
Copying user relation files
/var/lib/postgresql/8.4/main/base/4275487/4278965
Mismatch of relation OID in database FNBooking
On Mon, May 19, 2014 at 3:32 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 05/18/2014 06:30 AM, Jeff Janes wrote:
On Saturday, May 17, 2014, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
The seems to have fixed it.
Okay, thanks, committed.
Your torn-page generator
On Saturday, May 17, 2014, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 05/17/2014 12:28 AM, Jeff Janes wrote:
More fun with my torn page injection test program on 9.4.
24171 2014-05-16 14:00:44.934 PDT:WARNING: 01000: page verification
failed, calculated checksum 21100
to be reinitialized upon replay?
Cheers,
Jeff
conversion
[-Woverflow]
I think the solution is to use the pgsocket typedef from
src/include/port.h, rather than int. Like attached.
But I'm far from being a typedef lawyer, so maybe I am all wet.
Cheers,
Jeff
pgpipe.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql
?
Cheers,
Jeff
to partitioning, but removing warts from the
simpler case.
Cheers,
Jeff
consistent enough when the blocksize
varies?
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
chance of landing then any work on
incremental improvements would be pointless.
Thanks,
Jeff
PostgreSQL (or for that matter,
coding in C)?
Cheers,
Jeff
is overhead.
I'm all for finding something better if we can, but in the mean time this
is certainly not unexpected, and isn't it exactly what explain
(analyze,timing off) was invented for?
Cheers,
Jeff
On Wed, May 7, 2014 at 1:40 PM, Heikki Linnakangas
hlinnakan...@vmware.comwrote:
On 05/07/2014 10:35 AM, Jeff Janes wrote:
When recovering from a crash (with injection of a partial page write at
time of crash) against 7c7b1f4ae5ea3b1b113682d4d I get a checksum
verification failure.
16396
27799 2014-05-06 23:29:51.473 PDT:LOG: 0: aborting startup due to
startup process failure
Cheers,
Jeff
On Wed, May 7, 2014 at 12:48 AM, Andres Freund and...@2ndquadrant.comwrote:
Hi,
On 2014-05-07 00:35:35 -0700, Jeff Janes wrote:
When recovering from a crash (with injection of a partial page write at
time of crash) against 7c7b1f4ae5ea3b1b113682d4d I get a checksum
verification failure
access the same index leaf blocks and the same table blocks
repeatedly--that is why is only mostly about the table size, rather than
exclusively).
Cheers,
Jeff
On Wed, May 7, 2014 at 10:34 AM, Andres Freund and...@2ndquadrant.comwrote:
Hi,
On 2014-05-07 10:21:26 -0700, Jeff Janes wrote:
On Wed, May 7, 2014 at 12:48 AM, Andres Freund and...@2ndquadrant.com
wrote:
If you have the WAL a pg_xlogdump grepping for everything referring
, that would probably go a long way to getting some people to
work on carrying out the tests. Unless the conclusion was please have 3TB
or RAM and a 50 disk RAID, then there might be few takers.
Cheers,
Jeff
, and couldn't get
more than a small fraction of s_b to be so tightly bound in that the kernel
could forget about them. Unless of course the entire workload or close to
it fits in s_b.
Cheers,
Jeff
of these
queries has its own peculiar working set, then having e_c_s smaller than
s_b makes sense.
I have a hard time believe that this is at all common, however. Certainly
not common enough so to justify cranking the setting all the way the other
direction and then removing the crank handle.
Cheers,
Jeff
On Sat, May 3, 2014 at 1:11 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:
On Friday, May 2, 2014, Jeff Janes jeff.ja...@gmail.com wrote:
I've been working with an app that uses a schema name whose spelling is
hard to type, and the lack
this down to f9b50b7c18c8ce7de1fee59409fe2 Fix removal of files
in pgstats directories. I think that before that commit, the leftover
stats file was somehow tricking the system into vacuuming the databases
more aggressively following a crash.
Cheers,
Jeff
If I recall correctly, Tom pointed out a while back that the comment
justifying the lockless read of the VM bit was not correct (or at least
not complete).
I rewrote it, but it was part of a patch that was not accepted. Attached
is the comment patch only.
Regards,
Jeff Davis
*** a/src
On Friday, May 2, 2014, Jeff Janes jeff.ja...@gmail.com wrote:
I've been working with an app that uses a schema name whose spelling is
hard to type, and the lack of tab completion for SET search_path TO was
bugging me. So see attached.
I filter out the system schemata, but not public
(,...)
But those don't exist.
Cheers,
Jeff
I've been working with an app that uses a schema name whose spelling is
hard to type, and the lack of tab completion for SET search_path TO was
bugging me. So see attached.
I filter out the system schemata, but not public.
For commit fest next.
Cheers,
Jeff
conventional hash table type indexes. I
fear they're a lost cause.
I understand that those are the only ones worth fighting for. :)
Cheers,
Jeff
mapping partition
happens to contain it.
Cheers,
Jeff
On Wed, Apr 30, 2014 at 11:19 AM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Apr 30, 2014 at 11:03 AM, Jeff Janes jeff.ja...@gmail.com wrote:
If we don't put in the work to make them useful, then they won't ever
become
useful.
If we do put in the effort (and it would be considerable
from a hot backup. In the case of unlogged
tables, this does mean we would need a way to checkpoint them with a
non-shutdown checkpoint, though. I don't know if that would need a
different type of unlogged table, or a different type of checkpoint.
Cheers,
Jeff
manual vacuums is not going to be a complete cure anyway.
It would be nice to know why the scripts are doing the manual vacuum. Just
out of mythology, or is there an identifiable reason?
Cheers,
Jeff
, not the ACCESS EXCLUSIVE one used during truncation.
Cheers,
Jeff
DBA or the invoker of the vacuum which is the one to
say. Either one does seem a reasonable place to have such a say, although
perhaps not worth the effort to implement.
Cheers,
Jeff
We do lots of testing,
but it isn't strenuous enough to find the problems, or is testing the wrong
aspects of the system.
Cheers,
Jeff
that I wrote and submitted a patch, you might notice; but
I'll get to it eventually if no one beats me to it.
Cheers,
Jeff
, but the missing file might make those
problems less obvious.
Of course first blush is often wrong, but...
Cheers,
Jeff
On Fri, Mar 21, 2014 at 2:22 PM, MauMau maumau...@gmail.com wrote:
From: Jeff Janes jeff.ja...@gmail.com
Do people really just copy the files from one directory of local storage
to
another directory of local storage? I don't see the point of that.
It makes sense to archive WAL
On Saturday, March 29, 2014, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com javascript:; writes:
But, it is hard to tell what the real solution is, because the doc
doesn't
explain why it should refuse (and fail) to overwrite an existing file.
The
only reason I can
dynamically.
It is very easy and powerful once you get used to it. I find the hardest
part is remembering which directory guc.c lives in.
Cheers,
Jeff
do is determine if the existing archived file
is just a truncated version of the attempting-to-be archived file, and if
so overwrite it. Because if the first archival command fails with a
network glitch, it can leave behind a partial file.
Cheers,
Jeff
been.
I don't know if bugs reports (without patches) against pre-release versions
are supposed to go to hackers or to bugs. If someone has a strong
preference, they might want to clarify this on the bug report form.
Cheers,
Jeff
at the wrong part of
the release cycle.
Cheers,
Jeff
smaller result.
We should know the uncertainty will be large.
Cheers,
Jeff
schema only, but not much when dumping data.
Cheers,
Jeff
that the benefit is not
coming just by moving the io costs closer to the cpu costs
Cheers,
Jeff
at a large scale but that still comfortably fits in
RAM, and wait for a checkpoint sync phase to kick in.
The pgstat wait timeout is a symptom, not the cause.
Cheers,
Jeff
and 9.3.
Unfortunately the worst of those bottlenecks were in the server, so they
depend on what database you are upgrading from, and so won't help you much
upgrading from 9.1.
Cheers,
Jeff
with your actual data (or better yet a
synthetic data set whose generator you can share with us).
Cheers,
Jeff
that it worked well
(assuming of course that it does work well), and then be motivated to
improve it.
If this could be done as an extension I would just go (attempt to) do it.
But since WAL isn't pluggable, it can't go in as an extension.
Cheers,
Jeff
to
discourage that.)
Cheers,
Jeff
on
pgbench_accounts (abalance).
Cheers,
Jeff
, then the issue is back. So it looks it is
related to planner, ...
In addition to the issue Jeff mentioned, I'd suggest trying the same
workload with repeatable read. That can do *wonders* because of the
reduced number of snapshots.
I tested it, and it doesn't help.
Is there some patch, that I can
in prepared statement binding in 9.2? and
several related threads.
Cheers,
Jeff
password but don't share the same salting mechanism.
Cheers,
Jeff
On Fri, Feb 21, 2014 at 8:42 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/22/2014 12:20 AM, Alvaro Herrera wrote:
Jeff Janes escribió:
On Fri, Feb 21, 2014 at 7:04 AM, Alvaro Herrera
alvhe...@2ndquadrant.comwrote:
If you were to have a mechanism by which
libpq can store
to do--continue to make more and more connections as requests come
in faster than they can finish.)
Cheers,
Jeff
On Tue, Feb 18, 2014 at 9:12 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 02/18/2014 06:27 PM, Jeff Janes wrote:
On Tue, Feb 18, 2014 at 3:49 AM, MauMau maumau...@gmail.com wrote:
--- or in other words, greater variance in response times. With my
simple
understanding
starving the checkpointer functionality.
Cheers,
Jeff
On Sunday, February 16, 2014, Jim Nasby j...@nasby.net wrote:
On 2/14/14, 1:06 PM, Jeff Janes wrote:
On Fri, Feb 14, 2014 at 6:33 AM, Bruce Momjian br...@momjian.us mailto:
br...@momjian.us wrote:
On Fri, Feb 14, 2014 at 03:28:23AM -0500, Stephen Frost wrote:
Bruce
environment and then eventually want to compare
the diverged dev setup back to production, I often forget to compare the
pg_hba.conf file.
Cheers,
Jeff
inserts?), there would be
nothing to clean up in the indexes and that step would be skipped (already
in the current code). And if the indexes do need cleaning up, we certainly
can't set the page all visible without doing that clean up.
Cheers,
Jeff
On Sun, Feb 9, 2014 at 4:56 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Feb 9, 2014 at 6:33 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Since this commit (17676c785a95b2598c573), pgbench no longer uses
.pgpass to
obtain passwords, but instead prompts for a password
, it is reading the .pgpass file, it just seem like it
is not using it.
Cheers,
Jeff
,
and no one put it through enough serious testing to overcome that concern.
(Also, I think you should make your siftdown code look more like the
existing siftdown code.)
Cheers,
Jeff
success.
Cheers,
Jeff
a lot of client-side work and
network traffic.
Would a change to PQputCopyData be welcome?
Regards,
Jeff Davis
[1] http://www.postgresql.org/docs/9.3/static/protocol-flow.html
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
. So doing a git bisect is just painful. Is the MSVC build faster?
Cheers,
Jeff
you take a random
30,000 rows. But the knobs to do that currently do not exist, and I doubt
they would be welcomed if their only use is to support pg_upgrade. So that
idea is not a blocker to this patch, either.
Cheers,
Jeff
active that no
amount of vacuuming could ever keep it high.
Cheers,
Jeff
the scale so that all data fit in RAM but not in shared_buffers.
Or maybe you want it to fit in shared_buffers, since the buffer mapping
lock was contended in shared mode--that suggests the problem is finding the
buffer that already has the page, not making a buffer to have the page.
Cheers,
Jeff
have committed this now.
I'm getting this warning now with gcc (GCC) 4.4.7:
pg_shmem.c: In function 'PGSharedMemoryCreate':
pg_shmem.c:332: warning: 'allocsize' may be used uninitialized in this
function
pg_shmem.c:332: note: 'allocsize' was declared here
Cheers,
Jeff
: 11,218.628 ms
The cost estimates do not depend on the column used in the join despite a 6
fold difference in run time, so the planner is perhaps missing a trick
there.
Cheers,
Jeff
801 - 900 of 3173 matches
Mail list logo
