On 12.11.2012 01:25, Tom Lane wrote:
Worse than that, GIST WAL replay seems to be a total disaster from this
standpoint, and I'm not convinced that it's even fixable without
incompatible WAL changes. There are several cases where index
insertion operations generate more than one WAL record
Jeff,
On 11/10/2012 12:08 AM, Jeff Davis wrote:
The bit indicating that a checksum is present may be lost due to
corruption.
Hm.. I see.
Sorry if that has been discussed before, but can't we do without that
bit at all? It adds a checksum switch to each page, where we just agreed
we don't
On 11/12/2012 05:55 AM, Greg Smith wrote:
Adding an initdb option to start out with everything checksummed seems
an uncontroversial good first thing to have available.
+1
So the following discussion really is for a future patch extending on
that initial checkpoint support.
One of the really
On 11/12/2012 04:44 PM, Markus Wanner wrote:
Jeff,
On 11/10/2012 12:08 AM, Jeff Davis wrote:
The bit indicating that a checksum is present may be lost due to
corruption.
Hm.. I see.
Sorry if that has been discussed before, but can't we do without that
bit at all? It adds a checksum switch
Thanks for comments,
Have to be careful to really not modify the
operands. numeric_out() and numeric_out_sci() are wrong; they
call get_str_from_var(), which modifies the argument. Same with
numeric_expr(): it passes the argument to
numericvar_to_double_no_overflow(), which passes it to
Hello, This is new version of identity projection patch.
Reverted projectionInfo and ExecBuildProjectionInfo. Identity
projection is recognized directly in ExecGroup, ExecResult, and
ExecWindowAgg. nodeAgg is reverted because I couldn't make it
sane..
The following is the result of performance
On 11/12/2012 10:44 AM, Craig Ringer wrote:
That'll make it hard for VACUUM, hint-bit setting, etc to
opportunistically checksum pages whenever they're doing a page write anyway.
It *is* a hard problem, yes. And the single bit doesn't really solve it.
So I'm arguing against opportunistically
Hi,
I have tried to solve this issue. Please see the attached patch.
With this patch, any expression is allowed in the return statement. For any
invalid expression an error is generated without doing any special handling.
When a row expression is used in the return statement then the resultant
Greg Smith g...@2ndquadrant.com writes:
Regardless, exactly how to prevent two concurrent processes from writing
the same file feels like the last step in the small roadmap for what
this feature needs.
Write a temp file and use rename(2) to move it into place is the
standard solution for
On Sun, Nov 11, 2012 at 6:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I already pointed out the inconsistency in heap_xlog_freeze about
whether a cleanup lock is needed. As is, this patch uses a cleanup
lock, but I suspect that a regular lock is sufficient --- comments?
Well, according to
Robert Haas robertmh...@gmail.com writes:
On Sun, Nov 11, 2012 at 6:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I already pointed out the inconsistency in heap_xlog_freeze about
whether a cleanup lock is needed. As is, this patch uses a cleanup
lock, but I suspect that a regular lock is
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 12.11.2012 01:25, Tom Lane wrote:
Worse than that, GIST WAL replay seems to be a total disaster from this
standpoint, and I'm not convinced that it's even fixable without
incompatible WAL changes.
Hmm. After the rewrite of that logic I
On Fri, Nov 9, 2012 at 3:03 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Thursday, November 08, 2012 10:42 PM Fujii Masao wrote:
On Thu, Nov 8, 2012 at 5:53 PM, Amit Kapila amit.kap...@huawei.com
wrote:
On Thursday, November 08, 2012 2:04 PM Heikki Linnakangas wrote:
On 19.10.2012
Greg Smith wrote:
On 11/11/12 2:56 PM, Jeff Davis wrote:
We could have a separate utility, pg_checksums, that can
alter the state and/or do an offline verification. And initdb would take
an option that would start everything out fully protected with
checksums.
Adding an initdb option to
On Fri, Sep 14, 2012 at 6:42 AM, Amit kapila amit.kap...@huawei.com wrote:
On Tuesday, September 11, 2012 7:07 PM Amit Kapila wrote:
On Monday, September 10, 2012 8:20 PM Amit Kapila wrote:
On Sunday, September 09, 2012 1:37 PM Amit Kapila wrote:
On Friday, September 07, 2012 11:19 PM Tom Lane
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-10 16:24:22 -0500, Tom Lane wrote:
If any of this stuff were getting used by external modules, changing it
would be problematic ... but fortunately, it isn't, because we lack
support for plug-in rmgrs. So I'm not worried about
On 10.11.2012 11:46, Chen Huajun wrote:
Unfortunately not all compilers support varargs macros. I bumped into
this in February, see
http://archives.postgresql.org/message-id/4f3b72e0.8040...@enterprisedb.com.
My last attempt to fix this was
at
Version 4.9 of the PostgreSQL buildfarm client has been released and is
available at
https://github.com/downloads/PGBuildFarm/client-code/build-farm-4_9.tgz
Changes since version 4.8:
. adjust git status checking to allow for messages from recent git releases
. add a module to test
On 2012-11-12 10:19:09 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-10 16:24:22 -0500, Tom Lane wrote:
If any of this stuff were getting used by external modules, changing it
would be problematic ... but fortunately, it isn't, because we lack
support for
Heikki Linnakangas wrote:
On 10.11.2012 11:46, Chen Huajun wrote:
Unfortunately not all compilers support varargs macros. I bumped into
this in February, see
http://archives.postgresql.org/message-id/4f3b72e0.8040...@enterprisedb.com.
My last attempt to fix this was
at
Hi,
Please find attached to this email an RFC patch implementing the basics
of the pg_dump --extension-script option. After much discussion around
the concept of an inline extension, we decided last year that a good
first step would be pg_dump support for an extension's script.
The approach I've
On Sat, Nov 10, 2012 at 05:59:54PM -0500, Bruce Momjian wrote:
On Sat, Nov 10, 2012 at 02:45:54PM -0800, Jeff Janes wrote:
On Sat, Nov 10, 2012 at 9:15 AM, Bruce Momjian br...@momjian.us wrote:
On Fri, Nov 9, 2012 at 04:23:40PM -0800, Jeff Janes wrote:
On Fri, Nov 9, 2012 at 3:06 PM,
On Fri, Nov 9, 2012 at 3:31 PM, Simon Riggs si...@2ndquadrant.com wrote:
So what we're talking about here is a new mode for COPY, that when
requested will pre-freeze tuples when loading into a newly
created/truncated table. If the table isn't newly created/truncated
then we'll just ignore it
On Fri, Nov 9, 2012 at 12:50:34AM -0500, Tom Lane wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Are sure the server you are dumping out of is head?
I experimented a bit with dumping/restoring 16000 tables matching
Bruce's test case (ie, one serial column apiece). The pg_dump profile
On Tue, Jul 31, 2012 at 8:09 AM, Amit kapila amit.kap...@huawei.com wrote:
Based on the discussion and suggestions in this mail chain, following
features can be implemented:
1. To compute the value of max LSN in data pages based on user input
whether he wants it for an individual
file, a
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 9, 2012 at 3:31 PM, Simon Riggs si...@2ndquadrant.com wrote:
So what we're talking about here is a new mode for COPY, that when
requested will pre-freeze tuples when loading into a newly
created/truncated table. If the table isn't newly
On Thu, Nov 8, 2012 at 3:45 AM, Filip Rembiałkowski
filip.rembialkow...@gmail.com wrote:
maybe this is a better group for this question?
I can't see why creating foreign key on table A referencing table B,
generates an AccessExclusiveLock on B.
It seems (to a layman :-) ) that only writes to
On Mon, Nov 12, 2012 at 11:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 9, 2012 at 3:31 PM, Simon Riggs si...@2ndquadrant.com wrote:
So what we're talking about here is a new mode for COPY, that when
requested will pre-freeze tuples when
Bruce Momjian br...@momjian.us writes:
On Fri, Nov 9, 2012 at 12:50:34AM -0500, Tom Lane wrote:
The hash_seq_search time is probably mostly associated with
AtEOXact_RelationCache, which is run during transaction commit and scans
the relcache hashtable looking for tables created in the current
Hi,
Attached is a patch (against head) which documents the
name of the constraint and index created when using
PRIMARY KEY with CREATE TABLE, and the name of the
index created when using UNIQUE. I haven't read all
the docs recently but I don't believe this is presently
documented.
It's unclear
Robert Haas escribió:
On Tue, Jul 31, 2012 at 8:09 AM, Amit kapila amit.kap...@huawei.com wrote:
I think I can see all of those things being potentially useful. There
are a couple of pending patches that will revise the WAL format
slightly; not sure how much those are likely to interfere
On 12.11.2012 17:52, Alvaro Herrera wrote:
Hopefully you noticed that contrib is broken.
Oops.. fixed.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, 2012-11-12 at 09:44 +0100, Markus Wanner wrote:
Can we simply write a progress indicator to pg_control or someplace
saying that all pages up to X of relation Y are supposed to have valid
checksums?
pg_control would not be the right place for that structure. It's
intended to be
Karl O. Pinc k...@meme.com writes:
Attached is a patch (against head) which documents the
name of the constraint and index created when using
PRIMARY KEY with CREATE TABLE, and the name of the
index created when using UNIQUE. I haven't read all
the docs recently but I don't believe this is
On Fri, Nov 9, 2012 at 12:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Are sure the server you are dumping out of is head?
I experimented a bit with dumping/restoring 16000 tables matching
Bruce's test case (ie, one serial column apiece). The pg_dump
On Sat, Nov 10, 2012 at 12:41:44PM -0500, Bruce Momjian wrote:
On Sat, Nov 10, 2012 at 07:17:34PM +0200, Ants Aasma wrote:
On Sat, Nov 10, 2012 at 7:10 PM, Bruce Momjian br...@momjian.us wrote:
I am confused why you see a loop. transfer_all_new_dbs() does a
merge-join of old/new database
On 11/12/2012 10:40:00 AM, Tom Lane wrote:
Karl O. Pinc k...@meme.com writes:
Attached is a patch (against head) which documents the
name of the constraint and index created when using
PRIMARY KEY with CREATE TABLE, and the name of the
index created when using UNIQUE.
Personally I
Hi,
Attached is version 4. Version 3 no longer
built against head.
On 10/16/2012 09:48:06 PM, Karl O. Pinc wrote:
On 09/23/2012 08:52:07 PM, Karl O. Pinc wrote:
On 09/23/2012 12:24:27 AM, Karl O. Pinc wrote:
On 09/23/2012 12:19:07 AM, Karl O. Pinc wrote:
On 09/21/2012 10:54:05
On Sun, 2012-11-11 at 23:55 -0500, Greg Smith wrote:
Adding an initdb option to start out with everything checksummed seems
an uncontroversial good first thing to have available.
OK, so here's my proposal for a first patch (changes from Simon's
patch):
* Add a flag to the postgres
Noah Misch wrote:
On Sun, Nov 11, 2012 at 02:18:11AM -0300, Alvaro Herrera wrote:
I will
move all the open patches to CF3, unless someone beats me to it. I
probably won't be able to get anything done tomorrow, so if somebody has
a boring Sunday I would appreciate the help.
Likewise.
On Mon, Nov 5, 2012 at 12:08 PM, Bruce Momjian br...@momjian.us wrote:
Magnus reported that a customer with a million tables was finding
pg_upgrade slow. I had never considered many table to be a problem, but
decided to test it. I created a database with 2k tables like this:
CREATE
On Mon, 2012-11-12 at 10:29 -0800, Jeff Janes wrote:
When I'm doing a pg_upgrade with thousands of tables, the shutdown
checkpoint after restoring the dump to the new cluster takes a very
long time, as the writer drains its operation table by opening and
individually fsync-ing thousands of
On 10 September 2012 17:50, Tom Lane t...@sss.pgh.pa.us wrote:
The point of the proposal that I am making is to have a simple,
low-maintenance solution for people who need a single-application
database. A compromise somewhere in the middle isn't likely to be an
improvement for anybody. For
On 12 November 2012 16:22, Robert Haas robertmh...@gmail.com wrote:
But I guess that raises the question - should COPY (FREEZE) silently
ignore the option for not-new relfilenodes, or should it error out?
Simon proposed the former, but I'm wondering if the latter would be
better.
It's got
On 11 November 2012 23:24, Tom Lane t...@sss.pgh.pa.us wrote:
Practically all WAL record types that touch multiple pages have some
bug of this type. In addition to btree_xlog_split, I found that
heap_xlog_update, ginRedoDeletePage, spgRedoAddLeaf, spgRedoMoveLeafs,
spgRedoAddNode,
On 12 November 2012 14:51, Tom Lane t...@sss.pgh.pa.us wrote:
The 9.0 code is broken, however. In
9.0, when a child page is split, the parent and new children are kept
locked until the downlinks are inserted/updated. If a concurrent scan
comes along and sees that incomplete state, it will
Jeff,
On 11/12/2012 06:52 PM, Jeff Davis wrote:
OK, so here's my proposal for a first patch (changes from Simon's
patch):
* Add a flag to the postgres executable indicating that it should use
checksums on everything. This would only be valid if bootstrap mode is
also specified.
* Add
Simon Riggs si...@2ndquadrant.com writes:
On 11 November 2012 23:24, Tom Lane t...@sss.pgh.pa.us wrote:
Practically all WAL record types that touch multiple pages have some
bug of this type. In addition to btree_xlog_split, I found that
heap_xlog_update, ginRedoDeletePage, spgRedoAddLeaf,
Here's an updated patch that fixes the GIST replay functions as well as
the other minor issues that were mentioned. Barring objections, I'll
set about back-patching this as far as 9.0.
One thing that could use verification is my fix for
gistRedoPageSplitRecord. AFAICS, the first page listed in
On Mon, Nov 12, 2012 at 12:09:08PM -0500, Bruce Momjian wrote:
OK, I have had some time to think about this. What the current code
does is, for each database, get a directory listing to know about any
vm, fsm, and 1gig extents that exist in the directory. It caches the
directory listing and
On Mon, Nov 12, 2012 at 03:59:27PM -0500, Bruce Momjian wrote:
The second approach would be to simply try to copy the fsm, vm, and
extent files, and ignore any ENOEXIST errors. This allows code
simplification. The downside is that it doesn't pull all files with
matching prefixes --- it
Bruce Momjian escribió:
--- 17,24
static void transfer_single_new_db(pageCnvCtx *pageConverter,
FileNameMap *maps, int size);
! static int transfer_relfile(pageCnvCtx *pageConverter, FileNameMap *map,
!
Bruce Momjian escribió:
It is possible that the poor 16k pg_upgrade value is caused by the poor
9.2 binary-upgrade number (189.38). Perhaps I need to hack up
pg_upgrade to allow a 9.3 to 9.3 upgrade to test this.
Hmm? This already works, since make check uses it, right?
--
--
Sent via
On Mon, Nov 12, 2012 at 1:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 10 September 2012 17:50, Tom Lane t...@sss.pgh.pa.us wrote:
The point of the proposal that I am making is to have a simple,
low-maintenance solution for people who need a single-application
database. A compromise
On Mon, Nov 12, 2012 at 06:14:59PM -0300, Alvaro Herrera wrote:
Bruce Momjian escribió:
--- 17,24
static void transfer_single_new_db(pageCnvCtx *pageConverter,
FileNameMap *maps, int size);
! static int transfer_relfile(pageCnvCtx
On Mon, Nov 12, 2012 at 12:09:08PM -0500, Bruce Momjian wrote:
The second approach would be to simply try to copy the fsm, vm, and
extent files, and ignore any ENOEXIST errors. This allows code
simplification. The downside is that it doesn't pull all files with
matching prefixes --- it
On 12 November 2012 21:26, Merlin Moncure mmonc...@gmail.com wrote:
I couldn't disagree more. The patch is small, logical, and fixes an
awful problem, namely that --single mode is basically unusable. As to
your wider point (namely, that you can't connect to it, therefore it's
bad), it has
On Fri, Nov 9, 2012 at 10:50 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Nov 8, 2012 at 9:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Are sure the server you are dumping out of is head?
I experimented a bit with dumping/restoring 16000 tables
vacuumlo is rather simpleminded about dealing with the list of LOs to be
removed - it just fetches them as a straight resultset. For one of my
our this resulted in an out of memory condition. The attached patch
tries to remedy that by using a cursor instead. If this is wanted I will
add it to
On 12 November 2012 16:51, Robert Haas robertmh...@gmail.com wrote:
Although there may be some workloads that access very large numbers of
tables repeatedly, I bet that's not typical.
Transactions with large numbers of DDL statements are typical at
upgrade (application or database release
On Mon, Nov 12, 2012 at 5:17 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 12 November 2012 16:51, Robert Haas robertmh...@gmail.com wrote:
Although there may be some workloads that access very large numbers of
tables repeatedly, I bet that's not typical.
Transactions with large numbers of
On 11/12/12 4:44 AM, Craig Ringer wrote:
Is it absurd to suggest using another bitmap, like the FSM or visibility
map, to store information on page checksumming while checksumming is
enabled but incomplete?
I spent some time thinking about that last week. One problem with it is
that the
On Mon, 2012-11-12 at 20:44 +0100, Markus Wanner wrote:
As described before in this thread, I think we might be able to do
without the has checksum-bit, as yet another simplification. But I
don't object to adding it, either.
I see. For a first patch, I guess that's OK. Might as well make it as
On 11/12/12 3:44 AM, Markus Wanner wrote:
Sorry if that has been discussed before, but can't we do without that
bit at all? It adds a checksum switch to each page, where we just agreed
we don't event want a per-database switch.
Once you accept that eventually there need to be online conversion
Jeff,
OK, so here's my proposal for a first patch (changes from Simon's
patch):
* Add a flag to the postgres executable indicating that it should use
checksums on everything. This would only be valid if bootstrap mode is
also specified.
* Add a multi-state checksums flag in
https://wiki.postgresql.org/wiki/Index-only_scans
This page is seriously out of date. It suggests they are not yet
implemented, but only being talked about.
Would someone who knows a lot about the subject (which is why I'm
sending this hackers, not web) like to take a whack at updating this?
On 13 November 2012 01:03, Jeff Janes jeff.ja...@gmail.com wrote:
https://wiki.postgresql.org/wiki/Index-only_scans
This page is seriously out of date. It suggests they are not yet
implemented, but only being talked about.
Attached is a piece I wrote on the feature. That might form the basis
On Sun, 2012-09-23 at 21:28 -0500, Karl O. Pinc wrote:
Patch to add CREATE TABLE AS to the See Also: section
of the CREATE TABLE docs.
committed
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Here is a patch to support RFC 2255 LDAP URLs in pg_hba.conf. So,
instead of, say
host ... ldap ldapserver=ldap.example.net ldapbasedn=dc=example, dc=net
ldapsearchattribute=uid
you could write
host ... ldap lapurl=ldap://ldap.example.net/dc=example,dc=net?uid?sub;
Apache and probably other
On Monday, November 12, 2012 12:07 PM Greg Smith wrote:
On 11/9/12 11:59 PM, Amit kapila wrote:
Please let me know if there are any objections or problems in above method
of implementation,
else I can go ahead to prepare the patch for the coming CF.
It may be the case that the locking
On Monday, November 12, 2012 8:23 PM Fujii Masao wrote:
On Fri, Nov 9, 2012 at 3:03 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Thursday, November 08, 2012 10:42 PM Fujii Masao wrote:
On Thu, Nov 8, 2012 at 5:53 PM, Amit Kapila amit.kap...@huawei.com
wrote:
On Thursday, November 08, 2012
On Monday, November 12, 2012 9:56 PM Alvaro Herrera wrote:
Robert Haas escribió:
On Tue, Jul 31, 2012 at 8:09 AM, Amit kapila amit.kap...@huawei.com wrote:
I think I can see all of those things being potentially useful. There
are a couple of pending patches that will revise the WAL format
I looked into the problem complained of here:
http://archives.postgresql.org/pgsql-general/2012-11/msg00279.php
which turns out to have nothing to do with joins and everything to do
with the fact that record_out() leaks memory like mad. It leaks both
the strings returned by the per-column output
On Monday, November 12, 2012 8:31 PM Merlin Moncure wrote:
On Fri, Sep 14, 2012 at 6:42 AM, Amit kapila amit.kap...@huawei.com wrote:
On Tuesday, September 11, 2012 7:07 PM Amit Kapila wrote:
On Monday, September 10, 2012 8:20 PM Amit Kapila wrote:
On Sunday, September 09, 2012 1:37 PM Amit
On Tuesday, November 13, 2012 3:11 AM Simon Riggs wrote:
On 12 November 2012 21:26, Merlin Moncure mmonc...@gmail.com wrote:
I couldn't disagree more. The patch is small, logical, and fixes an
awful problem, namely that --single mode is basically unusable. As to
your wider point (namely,
75 matches
Mail list logo
