On 24 January 2013 07:25, Pavan Deolasee pavan.deola...@gmail.com wrote:
On Thu, Jan 24, 2013 at 12:36 PM, Jeff Janes jeff.ja...@gmail.com wrote:
The docs on bgworker twice refer to HOT standby. I don't think that in
either case, the hot needs emphasis, and if it does making it look like an
On 01/24/2013 01:06 AM, Alexander Law wrote:
Hello,
Please let me know if I can do something to get the bug fix
(https://commitfest.postgresql.org/action/patch_view?id=902) committed.
I would like to fix other bugs related to postgres localization, but I
am not sure yet how to do it.
For
On 24 January 2013 01:17, Robert Haas robertmh...@gmail.com wrote:
I agree. The thing that scares me about the logical replication stuff
is not that it might be slow (and if your numbers are to be believed,
it isn't), but that I suspect it's riddled with bugs and possibly some
questionable
On Friday, December 7, 2012, Pavan Deolasee wrote:
Revised patch attached. This time much less invasive. I added a new
function heap_page_is_all_visible() to check if the given page is
all-visible and also return the visibility cutoff xid.
Hi Pavan,
lazy_vacuum_page now pins and unpins the
2013/1/24 Tom Lane t...@sss.pgh.pa.us:
John R Pierce pie...@hogranch.com writes:
On 1/23/2013 8:32 PM, Tom Lane wrote:
FWIW, in Fedora-land I see: ...
I'd be far more interested in what is in RHEL and CentOS.Fedora,
with its 6 month obsolescence cycle, is of zero interest to me for
On Wed, Jan 23, 2013 at 10:14 PM, Robert Haas robertmh...@gmail.com wrote:
I think there's been something of a professionalization of PostgreSQL
development over the last few years. More and more people are able
to get paid to work on PostgreSQL as part or in a few cases all of
their job.
Hi Jeff,
On Thu, Jan 24, 2013 at 2:41 PM, Jeff Janes jeff.ja...@gmail.com wrote:
lazy_vacuum_page now pins and unpins the vmbuffer for each page it marks
all-visible, which seems like a lot of needless traffic since the next
vmbuffer is likely to be the same as the previous one.
Good idea.
I'm sending three smaller patches for review, which try to fix icc
and pathscale (mis)compilation problems described in my last email.
Not sure if we need to fix the overflow check x + 1 = 0 (x 0) at
src/backend/executor/execQual.c:3088, which icc optimizes away, too.
Fix x + y x overflow
Robert Haas robertmh...@gmail.com writes:
Or maybe we should just silently ignore failures to look up the event
trigger. That might be better, because the DBA could always do:
DROP FUNCTION myeventtrgfn() CASCADE;
...and it would be undesirable for other sessions to error out in that
case
icc optimizes away the overflow check x + y x (y 0), because
signed integer overflow is undefined behavior in C. Instead, use
a safe precondition test x INT_MAX - y.
---
src/backend/utils/adt/varbit.c |7 +--
src/backend/utils/adt/varlena.c | 10 ++
icc optimizes away x + 1 x because signed integer overflow is
undefined behavior in C. Instead, simply check if x is INT_MAX.
---
src/backend/utils/adt/float.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/backend/utils/adt/float.c
icc optimizes away `check + VARHDRSZ = check' since signed integer
overflow is undefined behavior. Simplify the overflow check for
`VARHDRSZ + count * slen' as `count (INT_MAX - VARHDRSZ) / slen'.
---
src/backend/utils/adt/oracle_compat.c | 18 +++---
1 file changed, 7
On 24.01.2013 11:33, Xi Wang wrote:
I'm sending three smaller patches for review, which try to fix icc
and pathscale (mis)compilation problems described in my last email.
These patches look ok at a quick glance, but how do we ensure this kind
of problems don't crop back again in the future?
On Thursday, January 24, 2013 7:42 AM Noah Misch wrote:
On Wed, Jan 09, 2013 at 11:22:06AM +, Simon Riggs wrote:
On 24 December 2012 16:57, Amit Kapila amit.kap...@huawei.com
wrote:
Performance: Average of 3 runs of pgbench in tps
9.3devel | with trailing null patch
On 1/24/13 5:02 AM, Heikki Linnakangas wrote:
These patches look ok at a quick glance, but how do we ensure this kind
of problems don't crop back again in the future? Does icc give a warning
about these? Do we have a buildfarm animal that produces the warnings?
If we fix these, can we stop
On 24.01.2013 00:30, Andres Freund wrote:
Hi,
I decided to reply on the patches thread to be able to find this later.
On 2013-01-23 22:48:50 +0200, Heikki Linnakangas wrote:
logical changeset generation v4
This is a boatload of infrastructure for supporting logical replication, yet
we have no
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
- Context exposing and filtering
I'm not feeling very sanguine about any of this. I feel strongly that
we should try to do something that's more principled than just
Robert Haas robertmh...@gmail.com writes:
Can you point me specifically at what you have in mind so I can make
sure I'm considering the right thing?
Something like this part:
+ -- now try something crazy to ensure we don't crash the backend
+ create function test_event_trigger_drop_function()
Hi Robert, Hi all,
On 2013-01-23 20:17:04 -0500, Robert Haas wrote:
On Wed, Jan 23, 2013 at 5:30 PM, Andres Freund and...@2ndquadrant.com wrote:
The only reason the submitted version of logical decoding is
comparatively slow is that its xmin update policy is braindamaged,
working on that
On Thursday, January 24, 2013 1:56 AM Andres Freund wrote:
On 2013-01-22 12:32:07 +, Amit kapila wrote:
This closes all comments raised till now for this patch.
Kindly let me know if you feel something is missing?
I am coming late to this patch, so bear with me if I repeat somethign
On Thursday, January 24, 2013 2:58 AM Stephen Frost wrote:
Heikki,
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
FWIW, here's how I feel about some the patches. It's not an
exhaustive list.
Thanks for going through them and commenting on them.
built-in/SQL Command to edit
One random thing that caught my eye in the patch, I though I'd mention
it while I still remember: In heap_delete, you call heap_form_tuple() in
a critical section. That's a bad idea, because if it runs out of memory
- PANIC.
- Heikki
--
Sent via pgsql-hackers mailing list
On 2013-01-24 12:38:25 +0200, Heikki Linnakangas wrote:
On 24.01.2013 00:30, Andres Freund wrote:
Hi,
I decided to reply on the patches thread to be able to find this later.
On 2013-01-23 22:48:50 +0200, Heikki Linnakangas wrote:
logical changeset generation v4
This is a boatload of
On Thu, Jan 24, 2013 at 2:27 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 01/24/2013 01:50 AM, Phil Sorber wrote:
This looks good to me now. Compiles and works as described.
Ready to go?
https://commitfest.postgresql.org/action/patch_view?id=1008
I guess I wasn't ready to be so bold,
On 2013-01-24 13:28:18 +0200, Heikki Linnakangas wrote:
One random thing that caught my eye in the patch, I though I'd mention it
while I still remember: In heap_delete, you call heap_form_tuple() in a
critical section. That's a bad idea, because if it runs out of memory -
PANIC.
Good point,
On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
* The gram.y changes arround set_rest_(more|common) seem pretty
confused
to me.
E.g. its not possible anymore to set the timezone for a function.
What do you exactly mean by this part of comment.
The set_rest_more production is used in
On Thu, Jan 24, 2013 at 10:11 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2013/1/24 Tom Lane t...@sss.pgh.pa.us:
John R Pierce pie...@hogranch.com writes:
On 1/23/2013 8:32 PM, Tom Lane wrote:
FWIW, in Fedora-land I see: ...
I'd be far more interested in what is in RHEL and CentOS.
On Thu, Jan 24, 2013 at 03:45:36PM +0800, Craig Ringer wrote:
On 01/24/2013 01:34 AM, Tom Lane wrote:
Alexander Law exclus...@gmail.com writes:
Please let me know if I can do something to get the bug fix
(https://commitfest.postgresql.org/action/patch_view?id=902) committed.
It's waiting
On 01/24/2013 07:57 PM, Noah Misch wrote:
On Thu, Jan 24, 2013 at 03:45:36PM +0800, Craig Ringer wrote:
On 01/24/2013 01:34 AM, Tom Lane wrote:
Alexander Law exclus...@gmail.com writes:
Please let me know if I can do something to get the bug fix
Hello,
some app created tables ussing uppercase letters in table names (this app
was migrated from mysql). One tries to use \d to search tables info:
ru=# \d pnct_Board
Did not find any relation named pnct_Board.
Of course, it works with :
ru=# \d pnct_Board
Table
2013/1/24 Nikolay Samokhvalov samokhva...@gmail.com:
some app created tables ussing uppercase letters in table names (this app
was migrated from mysql). One tries to use \d to search tables info:
...
Could this be considered as gotcha?
The thing is that Postgres reply is pretty much clear:
On Thu, Jan 24, 2013 at 09:05:59AM +0530, Ashutosh Bapat wrote:
I agree, answering the question, whether the particular attempt of
starting a server succeeded or not, will need the current behaviour.
Now, question is which of these behaviours should be default?
That would work. pg_upgrade
On Thursday, January 24, 2013 5:25 PM Andres Freund wrote:
On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
* The gram.y changes arround set_rest_(more|common) seem pretty
confused
to me.
E.g. its not possible anymore to set the timezone for a function.
What do you exactly mean
On 2013-01-24 18:37:29 +0530, Amit Kapila wrote:
On Thursday, January 24, 2013 5:25 PM Andres Freund wrote:
On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
* The gram.y changes arround set_rest_(more|common) seem pretty
confused
to me.
E.g. its not possible anymore to set
Amit Kapila escribió:
On Wednesday, January 23, 2013 11:51 PM Alvaro Herrera wrote:
Yes it is -- the /etc/postgresql/version/cluster directory (where
postgresql.conf resides) is owned by user postgres.
So in that case we can consider postgresql.auto.conf to be in path w.r.t
On 01/24/2013 03:42 AM, Craig Ringer wrote:
On 01/24/2013 01:06 AM, Alexander Law wrote:
Hello,
Please let me know if I can do something to get the bug fix
(https://commitfest.postgresql.org/action/patch_view?id=902) committed.
I would like to fix other bugs related to postgres localization,
From: Fujii Masao masao.fu...@gmail.com
On Thu, Jan 24, 2013 at 7:42 AM, MauMau maumau...@gmail.com wrote:
I searched through PostgreSQL mailing lists with WAL contains references
to
invalid pages, and i found 19 messages. Some people encountered similar
problem. There were some discussions
On Thu, Jan 24, 2013 at 6:36 AM, Xi Wang xi.w...@gmail.com wrote:
icc optimizes away the overflow check x + y x (y 0), because
signed integer overflow is undefined behavior in C. Instead, use
a safe precondition test x INT_MAX - y.
I should mention gcc 4.7 does the same, and it emits a
On Tue, Jan 22, 2013 3:27 PM Hari Babu wrote:
On Saturday, January 19, 2013 5:49 PM Magnus Hagander wrote:
On Fri, Jan 18, 2013 at 1:05 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 18.01.2013 13:41, Amit Kapila wrote:
On Friday, January 18, 2013 3:46 PM Heikki Linnakangas wrote:
On Thursday, January 24, 2013 6:51 PM Andres Freund wrote:
On 2013-01-24 18:37:29 +0530, Amit Kapila wrote:
On Thursday, January 24, 2013 5:25 PM Andres Freund wrote:
On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
* The gram.y changes arround set_rest_(more|common) seem pretty
Xi Wang xi.w...@gmail.com writes:
On 1/24/13 5:02 AM, Heikki Linnakangas wrote:
If we fix these, can we stop using -frapv on gcc? Is there any way to
get gcc to warn about these?
I believe we can get rid of -fwrapv once we fix all such checks.
TBH, I find that statement to be nonsense, and
On Thu, Jan 24, 2013 at 1:28 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Hi Jeff,
On Thu, Jan 24, 2013 at 2:41 PM, Jeff Janes jeff.ja...@gmail.com wrote:
lazy_vacuum_page now pins and unpins the vmbuffer for each page it marks
all-visible, which seems like a lot of needless traffic
On 13-01-24 06:40 AM, Andres Freund wrote:
Fair enough. I am also working on a user of this infrastructure but that
doesn't help you very much. Steve Singer seemed to make some stabs at
writing an output plugin as well. Steve, how far did you get there?
I was able to get something that
On Thu, Jan 24, 2013 at 08:50:36AM -0500, Andrew Dunstan wrote:
On 01/24/2013 03:42 AM, Craig Ringer wrote:
On 01/24/2013 01:06 AM, Alexander Law wrote:
Hello,
Please let me know if I can do something to get the bug fix
(https://commitfest.postgresql.org/action/patch_view?id=902)
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
* Writing the temporary file to .$pid seems like a bad idea, better use
one file for that, SET PERSISTENT is protected by an exclusive lock
anyway.
I think we can use one temporary file, infact that
On 6 January 2013 21:58, Simon Riggs si...@2ndquadrant.com wrote:
On 9 August 2012 10:45, Simon Riggs si...@2ndquadrant.com wrote:
On 22 June 2012 05:03, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
I hope this is promising.
I've reviewed this and thought about it over some
On 2013-01-24 11:22:52 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
* Writing the temporary file to .$pid seems like a bad idea, better use
one file for that, SET PERSISTENT is protected by an exclusive lock
anyway.
On 1/24/13 10:48 AM, Tom Lane wrote:
The fundamental problem here is that the compiler, unless told otherwise
by a compilation switch, believes it is entitled to assume that no
integer overflow will happen anywhere in the program. Therefore, any
error check that is looking for overflow
On Wed, Jan 23, 2013 at 8:12 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 24, 2013 at 8:47 AM, Phil Sorber p...@omniti.com wrote:
On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Phil Sorber p...@omniti.com writes:
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian
On 24.01.2013 18:24, Simon Riggs wrote:
On 6 January 2013 21:58, Simon Riggssi...@2ndquadrant.com wrote:
I've been torn between the need to remove the checkpoint for speed and
being worried about the implications of doing so.
We promote in multiple use cases. When we end a PITR, or are
On Thu, Jan 24, 2013 at 11:53 PM, MauMau maumau...@gmail.com wrote:
From: Fujii Masao masao.fu...@gmail.com
On Thu, Jan 24, 2013 at 7:42 AM, MauMau maumau...@gmail.com wrote:
I searched through PostgreSQL mailing lists with WAL contains references
to
invalid pages, and i found 19 messages.
Alvaro Herrera wrote:
Improve concurrency of foreign key locking
I noticed a bug in visibility routines when pg_upgrade is involved:
tuples marked FOR UPDATE in the old cluster (i.e. HEAP_XMAX_INVALID not
set, HEAP_XMAX_EXCL_LOCK set, HEAP_XMAX_IS_MULTI not set) are invisible
(dead) on the new
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-24 11:22:52 -0500, Tom Lane wrote:
Say again? Surely the temp file is being written by whichever backend
is executing SET PERSISTENT, and there could be more than one.
Sure, but the patch acquires SetPersistentLock exlusively beforehand
After reviewing this, it appears to me that this is really just a very
verbose version of
archive_command = 'sleep $initialsleep; while test $(psql -AtX -c select
pg_xlogfile_name(something) $$%f$$ collate \C\;) = t; sleep $sleep; done'
I think it might be better to just document this as an
On Thu, Jan 24, 2013 at 6:04 PM, Peter Eisentraut pete...@gmx.net wrote:
After reviewing this, it appears to me that this is really just a very
verbose version of
archive_command = 'sleep $initialsleep; while test $(psql -AtX -c select
pg_xlogfile_name(something) $$%f$$ collate \C\;) = t;
On 2013-01-24 12:02:59 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-24 11:22:52 -0500, Tom Lane wrote:
Say again? Surely the temp file is being written by whichever backend
is executing SET PERSISTENT, and there could be more than one.
Sure, but the
Magnus Hagander mag...@hagander.net writes:
On Thu, Jan 24, 2013 at 6:04 PM, Peter Eisentraut pete...@gmx.net wrote:
I think it might be better to just document this as an example. I don't
quite see the overhead of maintaining another tool justified.
Well, obviously I don't entirely agree ;)
On Thu, Jan 24, 2013 at 6:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Jan 24, 2013 at 6:04 PM, Peter Eisentraut pete...@gmx.net wrote:
I think it might be better to just document this as an example. I don't
quite see the overhead of
Andres Freund and...@anarazel.de writes:
Backend A: does SET PERSISTENT foobar =..;
Backend B: does SET PERSISTENT foobar =..;
Now B overwrites the config change A has made as they are all stored in
the same file.
Say what? I thought the plan was one setting per file, so that we don't
get
Hello
so there is updated version
+ some lines of doc
+ new regress tests
there are no reply to my previous mail - so I choose
concat(variadic null) --- NULL
concat(variadic '{}') --- empty string
this behave should not be precedent for any other variadic any
function, because concat() and
On 2013-01-24 12:30:02 -0500, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Backend A: does SET PERSISTENT foobar =..;
Backend B: does SET PERSISTENT foobar =..;
Now B overwrites the config change A has made as they are all stored in
the same file.
Say what? I thought the
On 24 January 2013 16:52, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 24.01.2013 18:24, Simon Riggs wrote:
On 6 January 2013 21:58, Simon Riggssi...@2ndquadrant.com wrote:
I've been torn between the need to remove the checkpoint for speed and
being worried about the implications
Folks,
Andrew Gierth asked me to send this out as his email is in a parlous
state at the moment. My comments will follow in replies. Without
further ado:
SQL2008 says, for 7.6 table reference
6)
a) If TR is contained in a from clause FC with no intervening query
expression, then the
On Thu, Jan 17, 2013 at 07:54:55AM -0500, Robert Haas wrote:
On Wed, Jan 16, 2013 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Where I really need someone to hit me upside the head with a
clue-stick is the code I added to the bottom of RelationBuildDesc()
in relcache.c. The idea is that
Hi Kevin,
The patch conflicts with git master; I tested against master@{2013-01-20}.
On Wed, Jan 16, 2013 at 12:40:55AM -0500, Kevin Grittner wrote:
I've been struggling with two areas:
- pg_dump sorting for MVs which depend on other MVs
From your later messages, I understand that you have
9.1 introduced delayed validation on FKs, and 9.2 on table constraints,
however neither one has been useful due to lesser-locks on ALTER TABLE
being reverted (see
http://www.postgresql.org/message-id/1330350691-su...@alvh.no-ip.org),
preventing the lock benefits during the VALIDATE stage.
I don't
On Fri, Jan 25, 2013 at 1:45 AM, Phil Sorber p...@omniti.com wrote:
On Wed, Jan 23, 2013 at 8:12 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 24, 2013 at 8:47 AM, Phil Sorber p...@omniti.com wrote:
On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Phil Sorber
On Thu, Jan 24, 2013 at 6:14 AM, Andres Freund and...@2ndquadrant.com wrote:
Thats way much more along the lines of what I am afraid of than the
performance stuff - but Heikki cited those, so I replied to that.
Note that I didn't say this must, must go in - I just don't think
Heikki's
Thanks for looking at this!
Noah Misch wrote:
For the benefit of the archives, I note that we almost need not truncate an
unlogged materialized view during crash recovery. MVs are refreshed in a
VACUUM FULL-like manner: fill a new relfilenode, fsync it, and point the MV's
pg_class to that
On Wed, Jan 23, 2013 at 1:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Andres Freund escribió:
I somewhat dislike the fact that CONCURRENTLY isn't really concurrent
here (for the listeners: swapping the indexes acquires exlusive locks) ,
but I don't see any other naming being better.
On Thu, Jan 24, 2013 at 01:29:56PM -0500, Robert Haas wrote:
On Wed, Jan 23, 2013 at 1:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Andres Freund escribió:
I somewhat dislike the fact that CONCURRENTLY isn't really concurrent
here (for the listeners: swapping the indexes acquires
* Robert Haas (robertmh...@gmail.com) wrote:
Now, the bad news is, I don't think it's very reasonable to try to
commit this to 9.3. I think it is just too much stuff too late in the
cycle. I've reviewed some of the patches from time to time but there
is a lot more stuff and it's big and
On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:
A long time ago I had a lot of sympathy with this answer, but these days not
so much. Getting a working mingw/msys environment sufficient to build a bare
bones
Bruce Momjian br...@momjian.us writes:
On Thu, Jan 24, 2013 at 01:29:56PM -0500, Robert Haas wrote:
I'm kind of unconvinced of the value proposition of this patch. I
mean, you can DROP INDEX CONCURRENTLY and CREATE INDEX CONCURRENTLY
today, so ... how is this better?
This has been on the
On 2013-01-24 13:29:56 -0500, Robert Haas wrote:
On Wed, Jan 23, 2013 at 1:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Andres Freund escribió:
I somewhat dislike the fact that CONCURRENTLY isn't really concurrent
here (for the listeners: swapping the indexes acquires exlusive
On 24.01.2013 20:27, Robert Haas wrote:
Before getting bogged down in technical commentary, let me say this
very clearly: I am enormously grateful for your work on this project.
Logical replication based on WAL decoding is a feature of enormous
value that PostgreSQL has needed for a long time,
On 24 January 2013 17:44, Simon Riggs si...@2ndquadrant.com wrote:
At replay, an end-of-recovery record should be a signal to the hot standby
mechanism that there are no transactions running in the master at that
point, same as a shutdown checkpoint.
I had a reason why I didn't do that, but
On 21.01.2013 15:19, Heikki Linnakangas wrote:
On 21.01.2013 15:06, Tom Lane wrote:
Jeff Davispg...@j-davis.com writes:
On Mon, 2013-01-21 at 00:48 -0500, Tom Lane wrote:
I looked at this patch. ISTM we should not have the option at all but
just do it always. I cannot believe that
On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao masao.fu...@gmail.com wrote:
set_pglocale_pgservice() should be called?
I think that the command name (i.e., pg_isready) should be given to
PQpingParams() as fallback_application_name. Otherwise, the server
by default uses unknown as the
On 21.01.2013 15:19, Heikki Linnakangas wrote:
On 21.01.2013 15:06, Tom Lane wrote:
Jeff Davispg...@j-davis.com writes:
On Mon, 2013-01-21 at 00:48 -0500, Tom Lane wrote:
I looked at this patch. ISTM we should not have the option at all but
just do it always. I cannot believe that
On 01/24/2013 01:44 PM, Jeff Janes wrote:
On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:
A long time ago I had a lot of sympathy with this answer, but these days not
so much. Getting a working mingw/msys environment
Heikki Linnakangas hlinnakan...@vmware.com writes:
I did some experimenting with that. I used the same test case Alexander
did, with geonames data, and compared unpatched version, the original
patch, and the attached patch that biases the first best tuple found,
but still sometimes chooses
On Thu, Jan 24, 2013 at 01:29:10PM -0500, Kevin Grittner wrote:
Noah Misch wrote:
For the benefit of the archives, I note that we almost need not truncate an
unlogged materialized view during crash recovery. MVs are refreshed in a
VACUUM FULL-like manner: fill a new relfilenode, fsync it,
On 01/24/2013 02:41 PM, Andrew Dunstan wrote:
What advantages does mingw have over MSVC? Is it just that it is
cost-free, or is it easier to use mingw than MSVC for someone used to
building on Linux? (mingw certainly does not seem to have the
advantage of being fast!)
See Craig's email
On Thu, Jan 24, 2013 at 11:26 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 21.01.2013 15:19, Heikki Linnakangas wrote:
On 21.01.2013 15:06, Tom Lane wrote:
Jeff Davispg...@j-davis.com writes:
On Mon, 2013-01-21 at 00:48 -0500, Tom Lane wrote:
I looked at this patch. ISTM we
Noah Misch wrote:
On Thu, Jan 24, 2013 at 01:29:10PM -0500, Kevin Grittner wrote:
Noah Misch wrote:
For the benefit of the archives, I note that we almost need not truncate an
unlogged materialized view during crash recovery. MVs are refreshed in a
VACUUM FULL-like manner: fill a new
Jameison Martin jameis...@yahoo.com writes:
there have been a lot of different threads on this patch. i'm going to take a
stab at teasing them out, summarizing them, and addressing them individually.
Thanks for reviewing the bidding so carefully.
4.3) does it violate a principle in the code
Alexander Korotkov aekorot...@gmail.com writes:
There is another cause of overhead when use randomization in gistchoose:
extra penalty calls. It could be significant when index fits to cache. In
order evade it I especially change behaviour of my patch from look
sequentially and choose random
On Wed, Jan 23, 2013 at 04:58:57PM -0500, Bruce Momjian wrote:
Attached is a ready-to-apply version of the patch. I continued to use
postmaster.pid to determine if I need to try the start/stop test ---
that allows me to know which servers _might_ be running, because a
server start failure
On Thu, Jan 24, 2013 at 03:14:15PM -0500, Kevin Grittner wrote:
Noah Misch wrote:
On Thu, Jan 24, 2013 at 01:29:10PM -0500, Kevin Grittner wrote:
Noah Misch wrote:
For the benefit of the archives, I note that we almost need not truncate
an
unlogged materialized view during crash
On 24.01.2013 22:35, Tom Lane wrote:
Alexander Korotkovaekorot...@gmail.com writes:
There is another cause of overhead when use randomization in gistchoose:
extra penalty calls. It could be significant when index fits to cache. In
order evade it I especially change behaviour of my patch from
On Wed, Aug 15, 2012 at 11:09:18PM +0530, Sushant Sinha wrote:
I will do the profiling and present the results.
Sushant, do you have any profiling results on this issue from August?
---
On Wed, 2012-08-15 at 12:45
On Wed, Aug 29, 2012 at 01:13:51PM +, Rajeev rastogi wrote:
From: pgsql-bugs-ow...@postgresql.org [pgsql-bugs-ow...@postgresql.org] on
behalf of Bruce Momjian [br...@momjian.us]
Sent: Wednesday, August 29, 2012 8:46 AM
To: Tom Lane
Cc: Robert
the fact that we may lose the dirty bit is
OK.
Regards,
Jeff Davis
replace-tli-with-checksums-20130124.patch.gz
Description: GNU Zip compressed data
checksums-20130124.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 01/24/2013 11:19 AM, Noah Misch wrote:
On Thu, Jan 24, 2013 at 08:50:36AM -0500, Andrew Dunstan wrote:
On 01/24/2013 03:42 AM, Craig Ringer wrote:
On 01/24/2013 01:06 AM, Alexander Law wrote:
Hello,
Please let me know if I can do something to get the bug fix
Heikki Linnakangas hlinnakan...@vmware.com writes:
BTW, one thing that I wondered about this: How expensive is random()?
I'm assuming not very, but I don't really know. Alexander's patch called
random() for every tuple on the page, while I call it only once for each
equal-penalty tuple. If
Bruce Momjian br...@momjian.us writes:
Would someone make the doc change outlined above? Thanks.
Sorry, I'd nearly forgotten about this issue. Will see about fixing the
docs. (It looks like some of the comments in execMain.c could use work
too.)
regards, tom lane
--
Hi,
I have a bug pending that autovacuum fails to give priority to
for-wraparound tables. When xid consumption rate is high and dead tuple
creation is also high, it is possible that some tables are waiting for
for-wraparound vacuums that don't complete in time because the workers
are busy
On Wed, Jan 23, 2013 at 02:02:46PM -0500, Bruce Momjian wrote:
As a reminder, COPY FREEZE still does not issue any warning/notice if
the freezing does not happen:
Requests copying the data with rows already frozen, just as they
would be after running the commandVACUUM FREEZE/
On Thu, Jan 24, 2013 at 04:51:04PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Would someone make the doc change outlined above? Thanks.
Sorry, I'd nearly forgotten about this issue. Will see about fixing the
docs. (It looks like some of the comments in execMain.c could
1 - 100 of 143 matches
Mail list logo
