On 24 January 2013 07:25, Pavan Deolasee wrote:
> On Thu, Jan 24, 2013 at 12:36 PM, Jeff Janes 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
>> acronym (one already used for somet
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 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 design decisions.
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 t
2013/1/24 Tom Lane :
> John R Pierce 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
>> deploying database servers.
>
On Wed, Jan 23, 2013 at 10:14 PM, Robert Haas 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. This trend include
Hi Jeff,
On Thu, Jan 24, 2013 at 2:41 PM, Jeff Janes 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. Even though the
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 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 due to Snapshot
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 ++
src/pl/plpgsql/src/pl_
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 b/src/backend/utils/adt/fl
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 insertions
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? Do
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
> 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
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 n
Robert Haas writes:
> On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
> 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
> throwing random junk into ProcessUt
Robert Haas 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()
+ returns event_tri
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 wrote:
> > The only reason the submitted version of logical decoding is
> > comparatively slow is that its xmin update policy is braindamaged,
> > working on that right now.
>
> I
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 someth
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 Comman
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 (pgsql-hackers@pos
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
On Thu, Jan 24, 2013 at 2:27 AM, Craig Ringer 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, but sure. :) I ch
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 poi
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 i
On Thu, Jan 24, 2013 at 10:11 AM, Kohei KaiGai wrote:
> 2013/1/24 Tom Lane :
>> John R Pierce 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,
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 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 some
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 writes:
Please let me know if I can do something to get the bug fix
(https://commitfest.postgresql.org/action/patch_view
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"
Tab
2013/1/24 Nikolay Samokhvalov :
> 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:
> > Did not
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 k
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 d
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 poss
Amit Kapila escribió:
> On Wednesday, January 23, 2013 11:51 PM Alvaro Herrera wrote:
> > Yes it is -- the /etc/postgresql// 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
> postgresql.conf inst
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, b
From: "Fujii Masao"
On Thu, Jan 24, 2013 at 7:42 AM, MauMau 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 regarding those problems (Tom and
Sim
On Thu, Jan 24, 2013 at 6:36 AM, Xi Wang 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 warning.
--
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
>> 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 pret
Xi Wang 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 these patche
On Thu, Jan 24, 2013 at 1:28 AM, Pavan Deolasee
wrote:
> Hi Jeff,
>
> On Thu, Jan 24, 2013 at 2:41 PM, Jeff Janes 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 t
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 generat
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 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 was one of
On 6 January 2013 21:58, Simon Riggs wrote:
> On 9 August 2012 10:45, Simon Riggs wrote:
>> On 22 June 2012 05:03, Kyotaro HORIGUCHI
>> wrote:
>>
>>>I hope this is promising.
>>
>> I've reviewed this and thought about it over some time.
>
> I've been torn between the need to remove the check
On 2013-01-24 11:22:52 -0500, Tom Lane wrote:
> Andres Freund 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
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 *sh
On Wed, Jan 23, 2013 at 8:12 PM, Fujii Masao wrote:
> On Thu, Jan 24, 2013 at 8:47 AM, Phil Sorber wrote:
>> On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane wrote:
>>> Phil Sorber writes:
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian wrote:
> On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom L
On 24.01.2013 18:24, Simon Riggs wrote:
On 6 January 2013 21:58, Simon Riggs 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
performing a switchover, it
On Thu, Jan 24, 2013 at 11:53 PM, MauMau wrote:
> From: "Fujii Masao"
>>
>> On Thu, Jan 24, 2013 at 7:42 AM, MauMau wrote:
>>>
>>> I searched through PostgreSQL mailing lists with "WAL contains references
>>> to
>>> invalid pages", and i found 19 messages. Some people encountered similar
>>> pr
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 c
Andres Freund 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
> which seems fi
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 a
On Thu, Jan 24, 2013 at 6:04 PM, Peter Eisentraut 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; sleep $
On 2013-01-24 12:02:59 -0500, Tom Lane wrote:
> Andres Freund 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 acquire
Magnus Hagander writes:
> On Thu, Jan 24, 2013 at 6:04 PM, Peter Eisentraut 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 ;)
> Yes, it's a convenience c
On Thu, Jan 24, 2013 at 6:25 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Jan 24, 2013 at 6:04 PM, Peter Eisentraut 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, obvious
Andres Freund 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 involved in havi
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 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
On 24 January 2013 16:52, Heikki Linnakangas wrote:
> On 24.01.2013 18:24, Simon Riggs wrote:
>>
>> On 6 January 2013 21:58, Simon Riggs wrote:
>>>
>>> I've been torn between the need to remove the checkpoint for speed and
>>>
>>> being worried about the implications of doing so.
>>>
>>> We promo
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
6)
a) If TR is contained in a FC with no intervening , then the scope clause SC of TR is the or innermost that
On Thu, Jan 17, 2013 at 07:54:55AM -0500, Robert Haas wrote:
> On Wed, Jan 16, 2013 at 1:38 PM, Tom Lane 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 on first a
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 h
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 wrote:
> On Wed, Jan 23, 2013 at 8:12 PM, Fujii Masao wrote:
>> On Thu, Jan 24, 2013 at 8:47 AM, Phil Sorber wrote:
>>> On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane wrote:
Phil Sorber writes:
> On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian w
On Thu, Jan 24, 2013 at 6:14 AM, Andres Freund 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 reasoning about why not h
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
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.
>
> REINDEX ALMOST
On Thu, Jan 24, 2013 at 01:29:56PM -0500, Robert Haas wrote:
> On Wed, Jan 23, 2013 at 1:45 PM, Alvaro Herrera
> 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)
* 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 c
On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan 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 PostgreSQL from scr
Bruce Momjian 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 TODO list f
On 2013-01-24 13:29:56 -0500, Robert Haas wrote:
> On Wed, Jan 23, 2013 at 1:45 PM, Alvaro Herrera
> 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
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, an
On 24 January 2013 17:44, Simon Riggs 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 it seems to ha
On 21.01.2013 15:19, Heikki Linnakangas wrote:
On 21.01.2013 15:06, Tom Lane wrote:
Jeff Davis 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 always-go-left is ever a
pref
On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao 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 application name of pg_is
On 21.01.2013 15:19, Heikki Linnakangas wrote:
On 21.01.2013 15:06, Tom Lane wrote:
Jeff Davis 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 always-go-left is ever a
pref
On 01/24/2013 01:44 PM, Jeff Janes wrote:
On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan 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
Heikki Linnakangas 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 the other equally
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
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 to
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 Davis writes:
>>>
On Mon, 2013-01-21 at 00:48 -0500, Tom Lane wrote:
> I looked at this patch.
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 n
Jameison Martin 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 (Tom's latest ema
Alexander Korotkov 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" to "look in rand
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 du
On 24.01.2013 22:35, Tom Lane wrote:
Alexander Korotkov 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
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 -0
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: Rober
critical, so 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@p
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
(https://commitfest.postgresql.
Heikki Linnakangas 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 it's really cheap, I
Bruce Momjian 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
--
Sent via pgsql
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 process
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 VACUUM FREEZE command
On Thu, Jan 24, 2013 at 04:51:04PM -0500, Tom Lane wrote:
> Bruce Momjian 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
>
1 - 100 of 143 matches
Mail list logo
