On Thursday, September 20, 2012 7:35 PM Kohei KaiGai wrote:
2012/9/20 Amit Kapila :
> On Thursday, September 20, 2012 1:44 AM Simon Riggs wrote:
> On 12 September 2012 04:30, Amit Kapila wrote:
>> On Tuesday, September 11, 2012 9:09 PM Alvaro Herrera wrote:
>> Excerpts from Boszormenyi Zoltan's me
On Thursday, September 20, 2012 7:13 PM Alvaro Herrera wrote:
Excerpts from Amit Kapila's message of jue sep 20 02:10:23 -0300 2012:
>> Why can't worker tasks be also permanent, which can be controlled through
>> configuration. What I mean to say is that if user has need for parallel
>> opera
2012/9/20 Tom Lane :
> Pavel Stehule writes:
>> 2012/9/20 Tom Lane :
>>> I'm not sure what the performance tradeoffs would be ---
>>> some things would get faster and others slower, probably, since field
>>> access would be more work but conversion to/from HeapTuple would get far
>>> cheaper.
>
>>
On Thu, Sep 20, 2012 at 8:33 PM, Michael Paquier
wrote:
> On Fri, Sep 21, 2012 at 12:07 PM, Josh Kupershmidt
> wrote:
>>
>> On Thu, Sep 20, 2012 at 7:05 PM, Michael Paquier
>> wrote:
> What could be also great is to move the project directly into github to
> facilitate its maintenance and deve
On Thu, Sep 20, 2012 at 7:05 PM, Michael Paquier
wrote:
> Hi all,
>
> During the last PGCon, I heard that some community members would be
> interested in having pg_reorg directly in core.
> Just to recall, pg_reorg is a functionality developped by NTT that allows to
> redistribute a table without
On Fri, Sep 21, 2012 at 12:07 PM, Josh Kupershmidt wrote:
> On Thu, Sep 20, 2012 at 7:05 PM, Michael Paquier
> wrote:
> > Hi all,
> >
> > During the last PGCon, I heard that some community members would be
> > interested in having pg_reorg directly in core.
>
> I'm actually not crazy about this i
Tatsuo Ishii writes:
> To pass 64-bit integer to PQfn, PQArgBlock is used like this: int *ptr
> is a pointer to 64-bit integer and actual data is placed somewhere
> else.
Yeah, I think we have to do it like that. Changing the size of
PQArgBlock would be a libpq ABI break, which IMO is sufficient
>> To pass 64-bit integer to PQfn, PQArgBlock is used like this: int *ptr
>> is a pointer to 64-bit integer and actual data is placed somewhere
>> else. There might be other way: add new member to union u to store
>> 64-bit integer:
>>
>> typedef struct
>> {
>> int len;
On Thu, Sep 20, 2012 at 7:05 PM, Michael Paquier
wrote:
> Hi all,
>
> During the last PGCon, I heard that some community members would be
> interested in having pg_reorg directly in core.
I'm actually not crazy about this idea, at least not given the current
state of pg_reorg. Right now, there ar
Hi all,
During the last PGCon, I heard that some community members would be
interested in having pg_reorg directly in core.
Just to recall, pg_reorg is a functionality developped by NTT that allows
to redistribute a table without taking locks on it.
The technique it uses to reorganize the table is
> > 3) Backend inv_api.c functions(Nozomi Anzai)
> >
> > No need to add new functions. Just extend them to handle 64-bit data.
> >
> > BTW , what will happen if older 32-bit libpq accesses large objects
> > over 2GB?
> >
> > lo_read and lo_write: they can read or write lobjs using 32-bit API as
> >
Andrew Dunstan writes:
> On 08/23/2012 07:39 AM, Magnus Hagander wrote:
>> It doesn't break, of course ,since it's protected by the unique index.
>> But aren't you at risk of getting the very error message you're trying
>> to avoid?
> Yeah, looking further this was probably a thinko on my part. T
Pavel Stehule writes:
> 2012/9/20 Tom Lane :
>> I'm not sure what the performance tradeoffs would be ---
>> some things would get faster and others slower, probably, since field
>> access would be more work but conversion to/from HeapTuple would get far
>> cheaper.
> when fields are fix length, t
On Monday, September 17, 2012 03:58:37 PM Tom Lane wrote:
> Andres Freund writes:
> > Btw, I played with this some more on Saturday and I think, while
> > definitely a bad bug, the actual consequences aren't as bad as at least
> > I initially feared.
> >
> > Fake relcache entries are currently se
2012/9/20 Tom Lane :
> "Kevin Grittner" writes:
>> ... This did not work for cases where the AFTER DELETE trigger performed
>> an action which was not idempotent because, while return_value was
>> NULL enough to enter that last IF clause, it was not NULL enough to
>> prevent the DELETE attempt and
"Kevin Grittner" writes:
> ... This did not work for cases where the AFTER DELETE trigger performed
> an action which was not idempotent because, while return_value was
> NULL enough to enter that last IF clause, it was not NULL enough to
> prevent the DELETE attempt and fire subsequent triggers.
Hello!
I've spent a little time with this patch and have attached revision 6.
Thanks, Noah, for a fantastically detailed review.
The only thing I didn't do that Noah suggested was run pgindent on
guc-file.l. A cursory search did not reveal source compatible with my
operating system for 'indent'.
Related to bug #6123, Wisconsin Courts are now using triggers with
the workaround to be safe with the patch put forward by Tom, even
though they are still running with the earlier patch proposal by me
(which tolerates an UPDATE or DELETE of a row being deleted). The
general structure of the BEFORE
On 3.9.2012 01:28, Jeff Janes wrote:
> On Sun, Sep 2, 2012 at 3:46 PM, Tomas Vondra wrote:
>>
>> Fixed. I've kept use_log_agg only and I've removed the default. Also
>> I've added one more check (that the total duration is a multiple of
>> the aggregation interval).
>
> Hi Tomas,
>
> In the docs
John Lumby writes:
> On Fri, 22 Jun 2012 09:55:13, Robert Haas wrote:
>> I do notice that the RETURNING clause of the INSERT can't reference
>> NEW, which seems like a restriction that we probably ought to lift,
>> but it doesn't seem to have much to do with your patch.
> The main use of my propo
On 09/20/2012 03:34 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/20/2012 09:12 AM, Peter Eisentraut wrote:
It has been proposed that the plsh handler should strip the CRs before
execution. But I don't think that is a correct solution, because that
is user data which could be relevant. I
Hello
>
>
> Basic stuff:
>
> - Patch applies OK. but offset difference in line numbers.
> - Compiles with errors in contrib [pg_stat_statements, sepgsql] modules
> - Regression failed; one test-case in COPY due to incomplete test-case
> attached patch. – same as reported by Heikki
fi
Andrew Dunstan writes:
> On 09/20/2012 09:12 AM, Peter Eisentraut wrote:
>> It has been proposed that the plsh handler should strip the CRs before
>> execution. But I don't think that is a correct solution, because that
>> is user data which could be relevant. It could be the case, for
>> exampl
On 09/20/2012 09:12 AM, Peter Eisentraut wrote:
On 9/20/12 2:01 AM, Heikki Linnakangas wrote:
Could you strip the CRs? Either at CREATE FUNCTION time, or when the
function is executed.
It has been proposed that the plsh handler should strip the CRs before
execution. But I don't think that is
Hanada-san,
I checked your patch. It can be applied to the latest master branch
without any conflicts, and regression tests were fine.
Unlike the original postgresql_fdw_validator(), the new
dblink_fdw_validator() has wise idea; that pulls list of connection
options from libpq, instead of self-de
On 20 September 2012 16:29, Heikki Linnakangas wrote:
> 1. Insert 1000 rows in each transaction. This is exactly the sort of
> workload where WALInsertLock currently becomes a bottleneck. Without the the
> patch, the test scales very badly, with about 420 TPS with a single client,
> peaking only
Hi,
I've had problems using pg_restore --data-only when
restoring individual schemas (which contain data which
has had bad things done to it). --clean does not work
well because of dependent objects in other schemas.
Patch to the docs attached (before I go and do any
real coding.)
Karl
Free S
Heikki Linnakangas writes:
> I've been slowly continuing to work that I started last winder to make
> XLogInsert scale better. I have tried quite a few different approaches
> since then, and have settled on the attached. This is similar but not
> exactly the same as what I did in the patches I
On 20.09.2012 18:37, Tom Lane wrote:
I suspect that it's not a coincidence that you're seeing
a sweet spot for #slots ~= #CPUs.
Yeah, quite possible. I did not test with any different number of slots,
so I don't know if that's the sweet spot, but I wouldn't be surprised if
it is.
If that i
On Thursday, September 20, 2012 05:37:42 PM Tom Lane wrote:
> Heikki Linnakangas writes:
> > I've been slowly continuing to work that I started last winder to make
> > XLogInsert scale better. I have tried quite a few different approaches
> > since then, and have settled on the attached. This is s
On Thu, Sep 20, 2012 at 9:24 AM, Kevin Grittner
wrote:
> Merlin Moncure wrote:
>
>> Hm, I bet it's possible (although probably not easy) to deduce
>> volatility from the function body...maybe through the validator.
>> If you could do that (perhaps warning in cases where you can't),
>> then the pe
I've been slowly continuing to work that I started last winder to make
XLogInsert scale better. I have tried quite a few different approaches
since then, and have settled on the attached. This is similar but not
exactly the same as what I did in the patches I posted earlier.
The basic idea, li
2012/9/20 Amit Kapila :
> On Thursday, September 20, 2012 1:44 AM Simon Riggs wrote:
> On 12 September 2012 04:30, Amit Kapila wrote:
>> On Tuesday, September 11, 2012 9:09 PM Alvaro Herrera wrote:
>> Excerpts from Boszormenyi Zoltan's message of vie jun 29 09:11:23 -0400
> 2012:
>>
> We have
Excerpts from Amit Kapila's message of jue sep 20 02:10:23 -0300 2012:
> Why can't worker tasks be also permanent, which can be controlled through
> configuration. What I mean to say is that if user has need for parallel
> operations
> he can configure max_worker_tasks and those many worker
On Wed, Sep 19, 2012 at 2:39 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>>> It still seems like awfully weird behavior.
>>
>> Why? The WHERE condition relates only to the output of the _stats
>> subquery, so why shouldn't it be evaluated there, rather than
>> after the j
On 9/20/12 2:01 AM, Heikki Linnakangas wrote:
> Could you strip the CRs? Either at CREATE FUNCTION time, or when the
> function is executed.
It has been proposed that the plsh handler should strip the CRs before
execution. But I don't think that is a correct solution, because that
is user data wh
On 16.08.2012 14:43, Pavel Stehule wrote:
> Hello
>
> here is updated patch
[Review of Patch]
Basic stuff:
- Patch applies OK. but offset difference in line numbers.
- Compiles with errors in contrib [pg_stat_statements, sepgsql] modules
- Regression failed; one test-ca
In commit da4efa13d801ccc179f1d2c24d8a60c4a2f8ede9, sending of keepalive
messages have been disabled in walsender.
Commit message is " Turn off WalSender keepalives by default, users can
enable if desired."
But I am not able to see how users can enable it, can you please point me if
I am missing
On Sun, 01 Jul 2012 13:02:17 +0200 Boszormenyi Zoltan wrote:
>attached is a patch that does $SUBJECT.
>It's a usability enhancement, to take a backup, write
>a minimalistic recovery.conf and start the streaming
>standby in one go.
>Comments?
[Review of Patch]
Basic stuff:
--
It doesn't look like this patch is going anywhere. I agree with Tom's
comments that we need to think how this works for all datatypes, not
just booleans. And a simple substitution of values isn't enough; an
application might want to output all integers in hex, for example. A
custom domain in th
40 matches
Mail list logo
