(2012/03/12 19:21), Etsuro Fujita wrote:
> According to the following documentation on IterateForeignScan() in
> 50.2. Foreign Data Wrapper Callback Routines, I have created a patch to
> support the error handling in file_fdw. Please find attached a patch.
>
> Note that PostgreSQL's executor
On Tue, Mar 13, 2012 at 1:59 AM, Jeff Janes wrote:
> On Fri, Mar 9, 2012 at 2:45 AM, Heikki Linnakangas
> wrote:
>>
>>
>> Thanks!
>>
>> BTW, I haven't forgotten about the recovery bugs Jeff found earlier. I'm
>> planning to do a longer run with his test script - I only run it for about
>> 1000 it
Bruce Momjian writes:
> Copying the statistics from the old server is on the pg_upgrade TODO
> list. I have avoided it because it will add an additional requirement
> that will make pg_upgrade more fragile in case of major version changes.
> Does anyone have a sense of how often we change the st
x27;t really need to be fsync'd?
Regards,
Jeff Davis
initdb-fsync-20120312.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Mar 13, 2012 at 12:03 PM, Tom Lane wrote:
> Fujii Masao writes:
>> On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane wrote:
>>> The main actual simplification would be in getting rid of the "hole"
>>> at the end of each 4GB worth of WAL, cf this bit in xlog_internal.h:
>>> If we can't get rid of
On mån, 2012-03-12 at 13:04 -0700, Daniel Farina wrote:
> On the more constructive side, if I were to till the fields to change
> this aspect of the optimizer, is there any interest in rectifying the
> operator-function confusion?
I once proposed to do that [1], but there was not much enthusiasm
e
On Mon, Mar 12, 2012 at 9:41 PM, Noah Misch wrote:
>
> I created a CF entry for this and marked it Ready for Committer.
i wasn't sure if create an entry this late was a good idea or not...
but now i feel better because is less probable that it will fall out
on the cracks, thanks
> You left the
>
On Mon, Mar 12, 2012 at 06:38:30PM -0700, Daniel Farina wrote:
> You probably are going to ask: "why not just run ANALYZE and be done
> with it?" The reasons are:
>
> * ANALYZE can take a sufficiently long time on large databases that
> the downtime of switching versions is not attractive
>
>
Fujii Masao writes:
> On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane wrote:
>> The main actual simplification would be in getting rid of the "hole"
>> at the end of each 4GB worth of WAL, cf this bit in xlog_internal.h:
>> If we can't get rid of that and have a continuous 64-bit WAL address
>> space t
On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas wrote:
>>> On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane wrote:
Hm. I think "thousands" is an overestimate, but yeah the logic could be
greatly simplified. However, I'm n
There is one more (known) stop-ship problem in SPGiST, which I'd kind of
like to get out of the way now before I let my knowledge of that code
get swapped out again. This is that SPGiST is unsafe for use by hot
standby slaves.
The problem comes from "redirect" tuples, which are short-lifespan
obj
On Fri, Mar 09, 2012 at 02:18:02AM -0500, Jaime Casanova wrote:
> On Wed, Feb 22, 2012 at 12:27 AM, Noah Misch wrote:
> > On Tue, Feb 14, 2012 at 02:04:26AM -0500, Jaime Casanova wrote:
> >>
> >> 1) pgstattuple-gin_spgist.patch
> >> This first patch adds gin and spgist support to pgstattuple, also
On Sat, Mar 10, 2012 at 3:23 AM, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 12:38 PM, Magnus Hagander wrote:
>> On Fri, Mar 9, 2012 at 18:18, Tom Lane wrote:
>>> Magnus Hagander writes:
On Fri, Mar 9, 2012 at 15:37, Tom Lane wrote:
> Why would it be useful to use pg_size_pretty on xl
On Mon, Mar 12, 2012 at 4:45 PM, Jeff Janes wrote:
>>> Do you think the difference is in the CPU architecture, or the
>>> IO subsystem?
>>
>> That is an excellent question. I tried looking at vmstat output, but
>> a funny thing kept happening: periodically, the iowait column would
>> show a gigan
As noted by the manual, pg_statistic is ported in any way when
performing pg_upgrade. I have been investigating what it would take
to (even via just a connected SQL superuser client running UPDATE or
INSERT against pg_statistic) get at least some baseline statistics
into the database as quickly as
On Mon, Mar 12, 2012 at 01:28:11PM -0400, Robert Haas wrote:
> I spent some time thinking about this over the weekend, and I have an
> observation, and an idea. Here's the observation: I believe that
> locking a tuple whose xmin is uncommitted is always a noop, because if
> it's ever possible for
On Fri, Mar 09, 2012 at 03:04:23PM -0500, Tom Lane wrote:
> The main actual simplification would be in getting rid of the "hole"
> at the end of each 4GB worth of WAL, cf this bit in xlog_internal.h:
>
> /*
> * We break each logical log file (xlogid value) into segment files of the
> * size indi
On Fri, Mar 09, 2012 at 11:33:36AM -0500, Bruce Momjian wrote:
> On Fri, Mar 09, 2012 at 10:41:53AM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > The problem is that these files are being created often by shell
> > > redirects, e.g. pg_dump -f out 2> log_file. There is no clean way to
>
On Thu, Mar 08, 2012 at 08:33:48PM -0500, Bruce Momjian wrote:
> OK, it seems people do care about keeping log files from multiple runs
> so I went with Tom's idea and have:
>
> -
> pg_upgrade run on Thu Mar 8 19:30:12
On Mon, Mar 12, 2012 at 21:53, Marti Raudsepp wrote:
> Hi list,
>
> I don't know who's maintaining the PostgreSQL GitHub mirror, but it
> hasn't been updated for 6 days now:
> https://github.com/postgres/postgres
>
> Just letting you know.
Thanks for letting us know. I think it's because we misse
Hi list,
I don't know who's maintaining the PostgreSQL GitHub mirror, but it
hasn't been updated for 6 days now:
https://github.com/postgres/postgres
Just letting you know.
Regards,
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On Mon, Mar 12, 2012 at 10:55 AM, Robert Haas wrote:
> On Mon, Mar 12, 2012 at 12:32 PM, Jeff Janes wrote:
>> On Nate Boley's machine, the difference was ~100% increase rather than
>> ~10%.
>
> Oh, right. I had forgotten how dramatic the changes were in those
> test runs. I guess I should be ha
On Mon, Mar 12, 2012 at 12:22 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Mon, Mar 12, 2012 at 7:52 AM, Tom Lane wrote:
>>> Will Leinweber writes:
I created an index on an hstore function, fetchval(hstore, text), however
when I use the -> infix operator which resolves to the ver
On 09.03.2012 12:04, Heikki Linnakangas wrote:
I've been doing some performance testing with this, using a simple C
function that just inserts a dummy WAL record of given size. I'm not
totally satisfied. Although the patch helps with scalability at 3-4
concurrent backends doing WAL insertions, it
On Mon, Mar 12, 2012 at 6:14 PM, Robert Haas wrote:
> Considering that nobody's done any work to resolve the uncertainty
> about whether the worst-case performance characteristics of this patch
> are acceptable, and considering further that it was undergoing massive
> code churn for more than a m
Daniel Farina writes:
> On Mon, Mar 12, 2012 at 7:52 AM, Tom Lane wrote:
>> Will Leinweber writes:
>>> I created an index on an hstore function, fetchval(hstore, text), however
>>> when I use the -> infix operator which resolves to the very same function,
>>> this index is not used. It should be
Jaime Casanova wrote:
> is there any other place we can add a more detailed explanation?
> so from your text after saying "usually there is no reason for"
> you can add a parentesis saying "more info in "
Sure, I'll look around for a good spot.
-Kevin
--
Sent via pgsql-hackers mailing list
On Mon, Mar 12, 2012 at 1:50 PM, Simon Riggs wrote:
> On Mon, Mar 12, 2012 at 5:28 PM, Robert Haas wrote:
>> In other words, we'd entirely avoid needing to make mxacts crash-safe,
>> and we'd avoid most of the extra SLRU lookups that the current
>> implementation requires; they'd only be needed w
On Mon, Mar 12, 2012 at 12:39 PM, Kevin Grittner
wrote:
>
> Do we really want to get into all that in the middle of step-by-step
> instructions for the simple case?
>
is there any other place we can add a more detailed explanation? so
from your text after saying "usually there is no reason for" y
On Mon, Mar 12, 2012 at 12:32 PM, Jeff Janes wrote:
> On Nate Boley's machine, the difference was ~100% increase rather than
> ~10%.
Oh, right. I had forgotten how dramatic the changes were in those
test runs. I guess I should be happy that the absolute numbers on
this machine were as high as t
On Mon, Mar 12, 2012 at 5:28 PM, Robert Haas wrote:
> In other words, we'd entirely avoid needing to make mxacts crash-safe,
> and we'd avoid most of the extra SLRU lookups that the current
> implementation requires; they'd only be needed when (and for as long
> as) the locked tuple was not yet a
On Mon, Mar 12, 2012 at 12:30 PM, Kohei KaiGai wrote:
>> Suppose that the connection starts out in context connection_pooler_t.
>> Based on the identity of the user, we transition to foo_t, bar_t, or
>> baz_t. If it's possible, by any method, for one of those contexts to
>> get back to connectio
Jaime Casanova wrote:
> On Mon, Mar 12, 2012 at 10:41 AM, Kevin Grittner
> wrote:
>> Attached is a doc patch based on a suggestion by Rural Hunter to
>> address something he found confusing while setting up
>> partitioning.
>>
>> Original thread is here:
>>
>> http://archives.postgresql.org/pgsql
On Mon, Mar 12, 2012 at 10:41 AM, Kevin Grittner
wrote:
> Attached is a doc patch based on a suggestion by Rural Hunter to
> address something he found confusing while setting up partitioning.
>
> Original thread is here:
>
> http://archives.postgresql.org/pgsql-admin/2012-03/msg00066.php
>
you c
On Sun, Feb 26, 2012 at 9:47 PM, Robert Haas wrote:
>> Regarding performance, the good thing about this patch is that if you
>> have an operation that used to block, it might now not block. So maybe
>> multixact-related operation is a bit slower than before, but if it
>> allows you to continue op
Alvaro Herrera writes:
> Also, what do you think about adding the ability to dump pg_filenode.map
> files? Do you think it belongs in pg_filedump, or should we look at
> doing that elsewhere?
Not sure. It does already contain the ability to dump pg_control, but
that seems like rather a wart (no
On Mon, Mar 12, 2012 at 7:52 AM, Tom Lane wrote:
> Will Leinweber writes:
>> I created an index on an hstore function, fetchval(hstore, text), however
>> when I use the -> infix operator which resolves to the very same function,
>> this index is not used. It should be used.
>
> Don't hold your br
On Fri, Mar 9, 2012 at 2:45 AM, Heikki Linnakangas
wrote:
>
>
> Thanks!
>
> BTW, I haven't forgotten about the recovery bugs Jeff found earlier. I'm
> planning to do a longer run with his test script - I only run it for about
> 1000 iterations - to see if I can reproduce the PANIC with both the ea
Excerpts from tgl's message of lun mar 12 12:08:33 -0400 2012:
> Log Message:
> ---
> Updates for latest Postgres 9.2 sources.
> We no longer need pg_crc.c, and hence not a source tree, yay.
FWIW I had some fun last week compiling this to 9.1 sources because I
was using a VPATH build. I
On Sat, Mar 10, 2012 at 7:55 PM, Robert Haas wrote:
> I've finally been able to run some more tests of the effect of
> adjusting wal_buffers to values higher than 16MB. I ran the test on
> the 16 core (x 4 hw threads/core) IBM POWER7 machine, with my usual
> configuration settings:
>
> shared_buf
2012/3/12 Robert Haas :
> On Mon, Mar 12, 2012 at 11:13 AM, Kohei KaiGai wrote:
>> 2012/3/12 Robert Haas :
>>> On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai wrote:
It is a practical reason. In case when httpd open the connection to PG and
set a suitable security label according to the
On Mon, Mar 12, 2012 at 11:13 AM, Kohei KaiGai wrote:
> 2012/3/12 Robert Haas :
>> On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai wrote:
>>> It is a practical reason. In case when httpd open the connection to PG and
>>> set a suitable security label according to the given credential prior to
>>>
Attached is a doc patch based on a suggestion by Rural Hunter to
address something he found confusing while setting up partitioning.
Original thread is here:
http://archives.postgresql.org/pgsql-admin/2012-03/msg00066.php
-Kevin
*** a/doc/src/sgml/ddl.sgml
--- b/doc/src/sgml/ddl.sgml
***
2012/3/12 Robert Haas :
> On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai wrote:
>> It is a practical reason. In case when httpd open the connection to PG and
>> set a suitable security label according to the given credential prior to
>> launch
>> of user application, then keep this connection for
Excerpts from Noah Misch's message of jue mar 08 12:11:37 -0300 2012:
>
> On Wed, Mar 07, 2012 at 04:57:12PM -0500, Robert Haas wrote:
> > As a side note, the documentation for PQexec() is misleading about
> > what will happen if COPY is present in a multi-command string. It
> > says: "Note how
On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai wrote:
> It is a practical reason. In case when httpd open the connection to PG and
> set a suitable security label according to the given credential prior to
> launch
> of user application, then keep this connection for upcoming request, it is
> wor
On Sat, Mar 10, 2012 at 4:35 PM, Yeb Havinga wrote:
> The semantics are muddled because the client labels are mixed with labels
> from trusted procedures. The stack you described upthread may also exhibit
> surprising behaviour. If a trusted procedure is called, it's label is pushed
> onto the sta
2012/3/11 Yeb Havinga :
> On 2012-03-10 10:39, I wrote:
>
>>
>> I can probably write some docs tomorrow.
>>
>
> Attached is v5 of the patch, with is exactly equal to v4 but with added
> documentation.
>
Thanks for your dedicated volunteer. I'm under checking of the updates
at documentation.
> Som
Will Leinweber writes:
> I created an index on an hstore function, fetchval(hstore, text), however
> when I use the -> infix operator which resolves to the very same function,
> this index is not used. It should be used.
Don't hold your breath. Create an index on the expression you intend to
use
2012/3/9 Robert Haas :
> On Tue, Mar 6, 2012 at 9:14 AM, Kohei KaiGai wrote:
>> [ new patch ]
>
> Are we absolutely certain that we want the semantics of
> sepgsql_setcon() to be transactional? Because if we made them
> non-transactional, this would be a whole lot simpler, and it would
> still me
On Sun, Mar 11, 2012 at 11:51 PM, Fujii Masao wrote:
> On Sun, Mar 11, 2012 at 12:55 PM, Robert Haas wrote:
>> I've finally been able to run some more tests of the effect of
>> adjusting wal_buffers to values higher than 16MB. I ran the test on
>> the 16 core (x 4 hw threads/core) IBM POWER7 mac
Sorry ,here is the link the scribe project in reference it's a kernel
based record and replay system.
https://github.com/nviennot/linux-2.6-scribe
On Wed, Mar 7, 2012 at 5:25 PM, Ali Ahmed wrote:
>
> I am looking for some project suggestions to make proposals for an OS
> course at Columbia unive
I am looking for some project suggestions to make proposals for an OS
course at Columbia university (4-6weeks length single person), working with
Scribe ( kernel based application record and replay) focusing on DBMS ( I
would like to focus on postgres) .
I have some ideas on the line of explore usa
I created an index on an hstore function, fetchval(hstore, text), however
when I use the -> infix operator which resolves to the very same function,
this index is not used. It should be used.
I have included an example:
Table with hstore index:
de10keipt01939=> \d log_data
Dear Developers,
I am looking for elegant and effective way for running jobs inside a
database or cluster - for now I can not find that solution.
OK if You say "use cron" or "pgAgent" I say I know that solutions, but
the are not effective and elegant. Compilation of "pgAgent" is a pain
(especial
On Mon, Mar 12, 2012 at 10:27 PM, Fujii Masao wrote:
> On Mon, Mar 12, 2012 at 7:58 PM, Heikki Linnakangas
> wrote:
>> On 09.03.2012 13:40, Fujii Masao wrote:
>>>
>>> I found the bug which causes walsender to enter into busy loop
>>> when replication connection is terminated. Walsender consumes
>
On Mon, Mar 12, 2012 at 7:58 PM, Heikki Linnakangas
wrote:
> On 09.03.2012 13:40, Fujii Masao wrote:
>>
>> I found the bug which causes walsender to enter into busy loop
>> when replication connection is terminated. Walsender consumes
>> lots of CPU resource (%sys), and this situation lasts until
I believe that attached version of patch can be backpatched. It fixes this
problem without altering of index building procedure. It just makes checks
in internal pages softener enough to compensate effect of gist_box_same
implementation.
--
With best regards,
Alexander Korotkov.
*** a/src/back
On 09.03.2012 13:40, Fujii Masao wrote:
I found the bug which causes walsender to enter into busy loop
when replication connection is terminated. Walsender consumes
lots of CPU resource (%sys), and this situation lasts until it has
detected the termination of replication connection and exited.
T
According to the following documentation on IterateForeignScan() in
50.2. Foreign Data Wrapper Callback Routines, I have created a patch to
support the error handling in file_fdw. Please find attached a patch.
Note that PostgreSQL's executor doesn't care whether the rows
returned violate
2012/3/11 Petr Jelinek :
> On 03/10/2012 04:36 PM, Pavel Stehule wrote:
>>
>> and there some cleaned version
>>
>>
>
>
> Reran my tests and adjusted docs a bit, tbh I considered the previous
> versions way more useful but even in this form it's nice and useful
> functionality.
>
remove two lines o
Tom Lane wrote:
> Shigeru Hanada writes:
>> Thanks for the review. Agreed to write own depraser for pgsql_fdw
>> which handles nodes which can be pushed down. Every SQL-based FDW
>> which constructs SQL statement for each local query would need such
>> module inside.
>
> Yeah. That's kind of a
On Sat, Mar 10, 2012 at 2:59 PM, Andrew Dunstan wrote:
> The devil is in the details, though, pace Mies van der Rohe.
>
> In particular, it's the "tight integration" piece I'm worried about.
>
> What is the postmaster supposed to do if the daemon start fails? What if it
> gets a flood of failures
On Thu, Mar 8, 2012 at 4:51 AM, Tom Lane wrote:
> Alexander Korotkov writes:
> > True. If (max count - min count + 1) is small, enumerating of frequencies
> > is both more compact and more precise representation. Simultaneously,
> > if (max count - min count + 1) is large, we can run out of
> >
(2012/03/12 13:04), Etsuro Fujita wrote:
> (2012/03/09 23:48), Tom Lane wrote:
>> Etsuro Fujita writes:
>>> 2. IMHO RelOptInfo.fdw_private seems confusing. How about renaming it
>>> to e.g., RelOptInfo.fdw_state?
>>
>> Why is that better? It seems just as open to confusion with another
>> fiel
65 matches
Mail list logo
