On Mon, 2012-12-03 at 13:16 +, Simon Riggs wrote:
On 3 December 2012 09:56, Simon Riggs si...@2ndquadrant.com wrote:
I think the way forwards for this is...
1. Break out the changes around inCommit flag, since that is just
uncontroversial refactoring. I can do that. That reduces the
Hi,
On 2012-12-04 12:30:43 +0530, Pavan Deolasee wrote:
I was trying some simple queries on a Hot Standby with streaming
replication.
On standby, I do this:
postgres=# begin transaction isolation level repeatable read;
BEGIN
postgres=# explain verbose select count(b) from test WHERE a
On Tuesday, December 04, 2012 5:14 AM Pavan Deolasee wrote:
On Tue, Dec 4, 2012 at 3:16 AM, Robert Haas robertmh...@gmail.com wrote:
Also, if someone does have a 100GB relation, rereading 2MB of
visibility map pages at the end probably isn't a significant part of
the total cost. Even if 99.9%
On 12/03/2012 10:35 PM, Alvaro Herrera wrote:
So here's version 8. This fixes a couple of bugs and most notably
creates a separate PGPROC list for bgworkers, so that they don't
interfere with client-connected backends.
Nice, thanks. I'll try to review this again, shortly.
Regards
Markus
On Mon, 2012-12-03 at 09:56 +, Simon Riggs wrote:
1. Break out the changes around inCommit flag, since that is just
uncontroversial refactoring. I can do that. That reduces the noise
level in the patch and makes it easier to understand the meaningful
changes.
Done by you.
2. Produce an
2012-11-13 04:38 keltezéssel, Peter Eisentraut írta:
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
On 4 December 2012 01:34, Jeff Davis pg...@j-davis.com wrote:
I assume that refers to the discussion here:
http://archives.postgresql.org/pgsql-hackers/2012-02/msg01177.php
But that was quite a while ago, so is there a more recent discussion
that prompted this commit now?
Yes, this was
On 2012-12-04 10:18:36 +0100, Boszormenyi Zoltan wrote:
2012-11-13 04:38 keltezéssel, Peter Eisentraut írta:
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
On Tue, Dec 4, 2012 at 1:44 PM, Andres Freund and...@2ndquadrant.comwrote:
After max_standby_streaming_delay, the standby starts cancelling the
queries. I get an error like this on the standby:
postgres=# explain verbose select count(b) from test WHERE a 10;
FATAL: terminating
On Mon, Dec 3, 2012 at 3:20 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Nov 30, 2012 at 1:02 AM, Magnus Hagander mag...@hagander.net wrote:
In the interest of moving things along, I'll remove these for now at
least, and commit the rest of the patch, so we can keep working on the
On Mon, Dec 3, 2012 at 11:05 PM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Hi,
Thanks for your very good review!
Ibrar Ahmed ibrar.ah...@gmail.com writes:
I looked at the discussion for this patch and the patch itself. Here
are my comments and observations about the patch.
What I
Jan Wieck wrote:
Thinking about it, I'm not really happy with removing the
autovacuum_truncate_lock_check GUC at all.
Fact is that the deadlock detection code and the configuration
parameter for it should IMHO have nothing to do with all this in
the first place. A properly implemented
I was looking at the following code in heapam.c:
261 /*
262 * If the all-visible flag indicates that all tuples on the page
are
263 * visible to everyone, we can skip the per-tuple visibility
tests. But
264 * not in hot standby mode. A tuple that's already visible to all
On 2012-12-04 18:38:11 +0530, Pavan Deolasee wrote:
I was looking at the following code in heapam.c:
261 /*
262 * If the all-visible flag indicates that all tuples on the page
are
263 * visible to everyone, we can skip the per-tuple visibility
tests. But
264 * not in
On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
Thanks Andres. I also read the original thread and I now understand why we
are using FATAL here, at least until we have a better solution. Obviously
the connection reset is no good either because as someone
On 12/04/2012 02:40 AM, Christian Ullrich wrote:
Hello all,
the extension modules (TestUpgrade etc.) in the buildfarm client do
not use the make command override defined in the config file,
instead hardcoding command lines using make. This fails where make
is not GNU make.
Patch attached,
* Andrew Dunstan wrote:
On 12/04/2012 02:40 AM, Christian Ullrich wrote:
the extension modules (TestUpgrade etc.) in the buildfarm client do
not use the make command override defined in the config file,
Patch attached, which fixes the problem on jaguarundi.
Thanks, I will fix it, but
On Tue, Dec 4, 2012 at 8:08 AM, Pavan Deolasee pavan.deola...@gmail.com wrote:
I was looking at the following code in heapam.c:
261 /*
262 * If the all-visible flag indicates that all tuples on the page
are
263 * visible to everyone, we can skip the per-tuple visibility
On 12/04/2012 08:35 AM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 12/04/2012 02:40 AM, Christian Ullrich wrote:
the extension modules (TestUpgrade etc.) in the buildfarm client do
not use the make command override defined in the config file,
Patch attached, which fixes the
On 2012-12-04 08:38:48 -0500, Robert Haas wrote:
On Tue, Dec 4, 2012 at 8:08 AM, Pavan Deolasee pavan.deola...@gmail.com
wrote:
I was looking at the following code in heapam.c:
261 /*
262 * If the all-visible flag indicates that all tuples on the page
are
263 *
On Tue, Dec 4, 2012 at 9:00 AM, Andres Freund and...@2ndquadrant.com wrote:
Youre right, it currently seems to be possible, there's no LSN interlock
prohibiting this as far as I can see.
Yeah, there certainly isn't that. Now you could perhaps make an
argument that no operation that can
On Mon, Dec 3, 2012 at 10:06 PM, Bruce Momjian br...@momjian.us wrote:
FYI, someone put their new cluster inside an existing old tablespace,
and when they ran the script to delete their old install, their new
install was deleted too. My answer was, Don't do that.
Uh, wow. I feel bad for that
On Tue, Dec 4, 2012 at 09:37:46AM -0500, Robert Haas wrote:
On Mon, Dec 3, 2012 at 10:06 PM, Bruce Momjian br...@momjian.us wrote:
FYI, someone put their new cluster inside an existing old tablespace,
and when they ran the script to delete their old install, their new
install was deleted
Ibrar Ahmed ibrar.ah...@gmail.com writes:
I am still getting the same error message.
With the attached patch (v2), it works well:
create extension hstore version '1.2' from 'unpackaged';
DEBUG: execute_extension_script:
'/Users/dim/pgsql/ddl/share/extension/hstore--unpackaged--1.0.sql'
DEBUG:
Alvaro Herrera wrote:
One notable thing is that I had to introduce this in the postmaster
startup sequence:
/*
* process any libraries that should be preloaded at postmaster start
*/
process_shared_preload_libraries();
/*
* If loadable modules have added
On 2012-12-04 09:33:28 -0500, Robert Haas wrote:
On Tue, Dec 4, 2012 at 9:00 AM, Andres Freund and...@2ndquadrant.com wrote:
Youre right, it currently seems to be possible, there's no LSN interlock
prohibiting this as far as I can see.
Yeah, there certainly isn't that. Now you could
On Mon, Dec 03, 2012 at 01:12:48PM +0800, Jiang Guiqing wrote:
isinf() is not build to libecpg.so if build and install postgresql
by source on solaris9.
(isinf() is not contained within solaris9 system.)
...
I modify src/interfaces/ecpg/ecpglib/Makefile to resolve this problem.
The diff file
On Tue, Dec 4, 2012 at 10:38 AM, Andres Freund and...@2ndquadrant.com wrote:
I wonder if we could solve that by having an in-memory-only LSN that
only interlocks the hint bit writes, but doesn't cause full page
writes...
It's not really a hint bit, because if it fails to get set when the
After some diversions to fix bugs and refactor existing code, I've
committed a couple of small parts of this patch, which just add some
sanity checks to notice incorrect PITR scenarios. Here's a new version
of the main patch based on current HEAD.
- Heikki
streaming-tli-switch-8.patch.gz
On Tue, Dec 4, 2012 at 7:54 PM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Ibrar Ahmed ibrar.ah...@gmail.com writes:
I am still getting the same error message.
With the attached patch (v2), it works well:
create extension hstore version '1.2' from 'unpackaged';
DEBUG:
On 12/4/2012 8:06 AM, Kevin Grittner wrote:
Jan Wieck wrote:
I believe the check interval needs to be decoupled from the
deadlock_timeout again.
OK
This will leave us with 2 GUCs at least.
Hmm. What problems do you see with hard-coding reasonable values?
The question is what is
On Tue, Dec 4, 2012 at 8:03 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 4, 2012 at 9:00 AM, Andres Freund and...@2ndquadrant.com
wrote:
Youre right, it currently seems to be possible, there's no LSN interlock
prohibiting this as far as I can see.
Yeah, there certainly isn't
On Tue, Dec 4, 2012 at 04:45:16PM +0100, Michael Meskes wrote:
On Mon, Dec 03, 2012 at 01:12:48PM +0800, Jiang Guiqing wrote:
isinf() is not build to libecpg.so if build and install postgresql
by source on solaris9.
(isinf() is not contained within solaris9 system.)
...
I modify
On Mon, Dec 3, 2012 at 1:23 AM, Pavan Deolasee pavan.deola...@gmail.com wrote:
I was looking at the code in lazy_scan_heap() and I realized there are
couple of low-hanging optimizations that we can do there.
1. The for-loop walks through each block of the relation. But if scan_all is
set to
On Sun, Nov 18, 2012 at 4:54 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
Patch completely changes storage in posting lists and leaf pages of posting
trees. It uses varbyte encoding for BlockNumber and OffsetNumber.
BlockNumber are stored incremental in page. Additionally one bit of
On Sun, Dec 2, 2012 at 6:37 AM, Alastair Turner b...@ctrlf5.co.za wrote:
Patch for the changes discussed in
http://archives.postgresql.org/pgsql-hackers/2010-10/msg00919.php
attached (eventually ...)
In summary: If the input file (-f) doesn't exist or the ouput or log
files (-o and -l) can't
Hi everyone,
At
http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/xlogreader_v3
git://git.postgresql.org/git/users/andresfreund/postgres.git
you can find my attempt trying to bring the xlogreader from Heikki, as
modified by Alvaro, into a state where it
On 12/4/12 9:34 AM, Robert Haas wrote:
On Sun, Nov 18, 2012 at 4:54 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
Patch completely changes storage in posting lists and leaf pages of posting
trees. It uses varbyte encoding for BlockNumber and OffsetNumber.
BlockNumber are stored
On 2012-12-04 10:04:03 -0800, Josh Berkus wrote:
On 12/4/12 9:34 AM, Robert Haas wrote:
On Sun, Nov 18, 2012 at 4:54 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
Patch completely changes storage in posting lists and leaf pages of posting
trees. It uses varbyte encoding for
Yes, you are, rather. It might be possible to do something like:
json_get(json, variadic text) = json
Given that I already do the equivalent in Python, this would suit me
well. Not sure about other users ...
as long as it doesn't involve any testing beyond field name / array
index
On Tue, Dec 04, 2012 at 12:31:28PM -0500, Bruce Momjian wrote:
I have applied the attached patch to 9.0 to fix a merge conflict. I
patterned it after the commits you did to the other branches.
That is interesting. I fixed the same conflict and my git showed the commit,
but apparently that
However, for a very large user group -- users with ORMs which do their
own DDL migrations -- we could also use a way to log or WARN for table
rewrites. Since the ORMs are not gonna do an EXPLAIN.
An ORM is also quite unlikely to pay attention to a warning, much less a
postmaster log entry
Jan Wieck wrote:
[arguments for GUCs]
This is getting confusing. I thought I had already conceded the
case for autovacuum_truncate_lock_try, and you appeared to spend
most of your post arguing for it anyway. I think. It's a little
hard to tell. Perhaps the best thing is to present the issue to
On 12/4/2012 1:51 PM, Kevin Grittner wrote:
Jan Wieck wrote:
[arguments for GUCs]
This is getting confusing. I thought I had already conceded the
case for autovacuum_truncate_lock_try, and you appeared to spend
most of your post arguing for it anyway. I think. It's a little
hard to tell.
Hi!
On Sun, Dec 2, 2012 at 5:02 AM, Tomas Vondra t...@fuzzy.cz wrote:
I've tried to apply the patch with the current HEAD, but I'm getting
segfaults whenever VACUUM runs (either called directly or from autovac
workers).
The patch applied cleanly against 9b3ac49e and needed a minor fix when
On Mon, Dec 3, 2012 at 8:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Sorry for the delay. I've reviewed the patch. It was applied
successfully, and it worked well for tests I did including the example
you showed. I think it's worth the
On Tue, Dec 4, 2012 at 9:34 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Nov 18, 2012 at 4:54 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
Patch completely changes storage in posting lists and leaf pages of
posting
trees. It uses varbyte encoding for BlockNumber and
Patch looks good and also like it will/can be ready for 9.3. I'm happy
to put time into this as committer and/or reviewer and take further
responsibility for it, unless others wish to.
LIKES
* It's pretty simple to understand and use
* Check qual is stored in pre-parsed form. That is fast, and
Hello
I fully agree with Asif's arguments
previous tupconvert implementation was really strict - so using
enhanced tupconver has very minimal impact for old user - and I
checked same speed for plpgsql function - patched and unpatched pg.
tested
CREATE OR REPLACE FUNCTION public.foo(i integer)
Alexander Korotkov aekorot...@gmail.com writes:
On Mon, Dec 3, 2012 at 8:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But having said that, I'm wondering (without having read the patch)
why you need anything more than the existing resjunk field.
Actually, I don't know all the cases when resjunk
On Tue, Dec 4, 2012 at 11:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Mon, Dec 3, 2012 at 8:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But having said that, I'm wondering (without having read the patch)
why you need anything more than the
Alexander Korotkov escribió:
On Tue, Dec 4, 2012 at 9:34 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Nov 18, 2012 at 4:54 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
Patch completely changes storage in posting lists and leaf pages of
posting
trees. It uses varbyte
On Tue, 2012-12-04 at 10:15 +, Simon Riggs wrote:
On 4 December 2012 01:34, Jeff Davis pg...@j-davis.com wrote:
I assume that refers to the discussion here:
http://archives.postgresql.org/pgsql-hackers/2012-02/msg01177.php
But that was quite a while ago, so is there a more recent
On Tue, Dec 4, 2012 at 05:35:24PM -0300, Alvaro Herrera wrote:
This means to have two versions of code which deals with posting trees and
lists. For me it seems unlikely we have resources for maintenance of this.
Witness how GIN has gone with unfixed bugs for months, even though
patches
Hello
2012/11/27 Dimitri Fontaine dimi...@2ndquadrant.fr:
Hi,
Pavel Stehule pavel.steh...@gmail.com writes:
** missing doc
I still would prefer to have an ack about the premises of this patch
before spending time on writing docs for it, namely:
- we want a normalized command string
Pavel Stehule pavel.steh...@gmail.com writes:
I agree with these premisses. I am sure so normalised commands strings
are very nice feature, that can be helpful for generation clean audit
logs and messages. I see a one issue - testing a consistency between
commands and their deparsed forms.
Hi,
Here is the updated patch. I overlooked the loop, checking to free the
conversions map. Here are the results now.
postgres=# select sum(a) from generate_series(1,3000) g(i), lateral foo(i)
as (a numeric, b numeric);
sum
--
303000.0
(1 row)
postgres=# select sum(a) from
On 2012-12-01 14:45, Magnus Hagander wrote:
Someone just reported a problem when they had created a new tablespace
inside the old data directory. I'm sure there can be other issues
caused by this as well, but this is mainly a confusing scenario for
people now.
As there isn't (as far as I know
On 4.12.2012 20:12, Alexander Korotkov wrote:
Hi!
On Sun, Dec 2, 2012 at 5:02 AM, Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz wrote:
I've tried to apply the patch with the current HEAD, but I'm getting
segfaults whenever VACUUM runs (either called directly or from autovac
Josh Berkus j...@agliodbs.com writes:
However, for a very large user group -- users with ORMs which do their
own DDL migrations -- we could also use a way to log or WARN for table
rewrites. Since the ORMs are not gonna do an EXPLAIN.
An ORM is also quite unlikely to pay attention to a
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Maybe we can mark GIN indexes as invalid after pg_upgrade somehow, so
that they require reindex in the new cluster before they can be used for
queries or index updates.
Bumping the version number in the GIN metapage would be sufficient.
On Tue, Dec 4, 2012 at 05:35:27PM -0500, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Maybe we can mark GIN indexes as invalid after pg_upgrade somehow, so
that they require reindex in the new cluster before they can be used for
queries or index updates.
Bumping the
On Tue, 2012-12-04 at 01:03 -0800, Jeff Davis wrote:
3. I think we need an explicit test of this feature (as you describe
above), rather than manual testing. corruptiontester?
I agree, but I'm not 100% sure how to proceed. I'll look at Kevin's
tests for SSI and see if I can do something
On 4 December 2012 22:30, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
However, for a very large user group -- users with ORMs which do their
own DDL migrations -- we could also use a way to log or WARN for table
rewrites. Since the ORMs are not gonna do an
Sure, and the DevOps staff would be using the EXPLAIN feature (if we had
it). After which they could do little anyway except complain to the ORM
authors, who might or might not give a damn. I don't see that there's
enough value-added from what you suggest to justify the development
time.
I wrote:
So apparently this is something we broke since Nov 18. Don't know what
yet --- any thoughts?
Further experimentation shows that reverting commit
ffc3172e4e3caee0327a7e4126b5e7a3c8a1c8cf makes it work. So there's
something wrong/incomplete about that fix.
This is a bit urgent since
On Mon, Dec 03, 2012 at 01:14:30PM -0500, Andrew Dunstan wrote:
I think it would be reasonable for it to complain if it came across a
PG_VERSION file in an unexpected location.
That sounds like a reliable approach to detecting the hazard. Pseudocode:
chdir(proposed_tablespace_path)
On 2012-12-04 19:35:48 -0500, Tom Lane wrote:
I wrote:
So apparently this is something we broke since Nov 18. Don't know what
yet --- any thoughts?
Further experimentation shows that reverting commit
ffc3172e4e3caee0327a7e4126b5e7a3c8a1c8cf makes it work. So there's
something
On Tue, Dec 4, 2012 at 4:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
So apparently this is something we broke since Nov 18. Don't know what
yet --- any thoughts?
Further experimentation shows that reverting commit
ffc3172e4e3caee0327a7e4126b5e7a3c8a1c8cf makes it work. So there's
Sorry for the delay in following up here.
On Mon, Nov 26, 2012 at 8:30 PM, Karl O. Pinc k...@meme.com wrote:
On 11/26/2012 08:45:08 PM, Josh Kupershmidt wrote:
On Mon, Nov 26, 2012 at 3:42 PM, Robert Haas robertmh...@gmail.com
wrote:
On Mon, Nov 26, 2012 at 4:51 PM, Karl O. Pinc
On 12/04/2012 09:26:47 PM, Josh Kupershmidt wrote:
Sorry for the delay in following up here.
No problem at all.
Well, as far as I was able to tell, the use-case where this patch
worked without trouble was limited to restoring a table, or schema
with table(s), that:
a.) has some view(s)
On Mon, Dec 3, 2012 at 11:59 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sun, Dec 2, 2012 at 5:56 AM, Phil Sorber p...@omniti.com wrote:
Here is the updated patch. I renamed it, but using v5 to stay consistent.
After looking at this patch, I found the following problems:
- There
On 2012/12/05, at 14:46, Phil Sorber p...@omniti.com wrote:
On Mon, Dec 3, 2012 at 11:59 PM, Michael Paquier
So I understand what you mean by the ordering might change, but this
is actual output from the shell. I'm not sure how to convey that
sentiment properly here and still have a real
2012/12/4 Dimitri Fontaine dimi...@2ndquadrant.fr:
Pavel Stehule pavel.steh...@gmail.com writes:
I agree with these premisses. I am sure so normalised commands strings
are very nice feature, that can be helpful for generation clean audit
logs and messages. I see a one issue - testing a
74 matches
Mail list logo
