At 2013-07-08 12:16:34 +0300, hlinnakan...@vmware.com wrote:
>
> Ok, I've committed this patch now. Finally, phew!
Good.
I'd signed up to review this patch, and did spend some considerable time
on it, but although I managed to understand what was going on (which was
my objective), I didn't find a
At 2013-07-11 17:47:58 -0700, j...@agliodbs.com wrote:
>
> So, where are we with this patch, then?
It's ready for committer.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
It looks like to me exec_stmt_block creates a subtransaction if the block
has an exception handler by calling BeginInternalSubTransaction. Then
inside the PG_TRY it calls exec_stmts which runs the actual body of the
begin block. If an exception is thrown then I presume we are hitting the
PG_CATCH
It looks like to me when AtEOSubXact_SPI is called the
_SPI_current->connectSubId is always 1 (since it is only set when
SPI_connect is called, which is only once for plpgsql), but the
CurrentSubTransactionId is incremented each time a subtransaction is
started.
As a result, the memory for procCxt
On 07/10/2013 10:09 PM, Abhijit Menon-Sen wrote:
> At 2013-07-10 09:47:34 -0700, j...@agliodbs.com wrote:
>>
>> Due to the apparent lack of performance testing, I'm setting this back
>> to "needs review".
>
> The original submission (i.e. the message linked from the CF page)
> includes test result
On Thu, Jul 11, 2013 at 5:11 PM, Michael Paquier
wrote:
> I am resending the patches after Fujii-san noticed a bug allowing to
> even drop valid toast indexes with the latest code... While looking at
> that, I found a couple of other bugs:
> - two bugs, now fixed, with the code path added in table
Andres Freund writes:
> since the mvcc catalog patch has gone in we require all users of
> systable_* to be in a valid transaction since the snapshot is copied via
> CopySnapshot() in RegisterSnapshot().
It never has been, and never will be, allowed to call the catcache code
without being in a tr
On Thu, 2013-07-11 at 10:28 +0200, Andres Freund wrote:
> There doesn't seem be an explicitly stated rule that we cannot use the
> syscaches outside of a transaction - but effectively that's required
> atm.
Aren't there other things that already required that before the MVCC
catalog snapshot patch
The other option, suggested by Andres somewhere, is to have a new
parameter to pg_regress, something like --run-serially.
After looking at the source, ISTM that this option already exists under a
different signature:
--max-connections 1
So you would use the same parallel sc
On 7/11/13 5:55 AM, Magnus Hagander wrote:
> If it's safe to switch on the old ones as well, it sounds doable. If
> we need different toolchains, that's going to be a serious pain. Have
> you verified that it's fine with the old ones as well, or are you jsut
> assuming?
I tested it and it's fine.
On Fri, Jul 5, 2013 at 2:19 PM, Amit Kapila wrote:
> On Wednesday, July 03, 2013 2:58 AM Alvaro Herrera wrote:
>> Amit Kapila escribió:
>>
>> > I have changed the file name to postgresql.auto.conf and I have
>> changed the
>> > name of SetPersistentLock to AutoFileLock.
>> >
>> > Zoltan,
>> >
>> >
On 07/11/2013 09:19 AM, Alvaro Herrera wrote:
> Fabien COELHO escribió:
>
>> Note that this is really a POC. How to derive a file is under
>> discussion: it has been suggested that the unix shell approach would
>> not work on Windows. I've suggested perl or python (which version?)
>> but I'm not s
Jeevan Chalke writes:
> Following example does not work as expected:
> -- Should return TRUE but returning FALSE
> SELECT 'Programmer' ~ '(\w).*?\1' as t;
This is clearly broken, but I'm uncomfortable with the proposed patch.
As written, it changes behavior for both the shortest-match-preferred
Fabien COELHO escribió:
> Note that this is really a POC. How to derive a file is under
> discussion: it has been suggested that the unix shell approach would
> not work on Windows. I've suggested perl or python (which version?)
> but I'm not sure that it is okay either.
The other option, suggest
Hi,
this patch introduces a new configuration flag
replication_reserved_connections to reserve connection slots for
replication in the same way superuser_reserved_connections works for
superusers.
This helps in cases where the application opens connections until
max_connections is reached. A slav
On Thu, Jun 27, 2013 at 10:12 PM, Josh Berkus wrote:
> Yeah, I think that's be bigger question. Ok, I'll start working on a
> new test case. Here's my thinking on performance tests:
>
> 1. run pgbench 10 times both with and without the patch. See if there's
> any measurable difference. There s
I've attached a revised version that fixes the issues above:
> changing a reference of the form:
> OVER w
> into:
> OVER (w)
Fixed (and I've updated the tests).
> It's bad form to modify a list while iterating through it.
Fixed
> We shouldn't create an arbitrary number of duplicate windows
On Tue, Jul 9, 2013 at 11:45 PM, Sawada Masahiko wrote:
> On Sun, Jul 7, 2013 at 4:27 PM, Sawada Masahiko wrote:
> I found a bug which occurred when we do vacuum, and have fixed it.
> yesterday (8th July) "Improve scalability of WAL insertions" patch is
> committed to HEAD. so v2 patch does not a
On Thu, Jul 11, 2013 at 1:13 AM, Sean Chittenden wrote:
>> , I suppose two things can be done:
>>
>> 1. Quit the connection
>
> With my Infosec hat on, this is the correct option - force the client
> back in to compliance with whatever the stated crypto policy is through
> a reconnection.
>
>> 2.
On Thu, Jul 11, 2013 at 3:43 PM, Greg Stark wrote:
> On Wed, Jul 10, 2013 at 9:36 AM, Magnus Hagander wrote:
>> We already run this, that's what we did to make it survive at all. The
>> problem is there are so many thousands of different URLs you can get
>> to on that site, and google indexes the
On 2013-07-11 14:43:21 +0100, Greg Stark wrote:
> On Wed, Jul 10, 2013 at 9:36 AM, Magnus Hagander wrote:
> > We already run this, that's what we did to make it survive at all. The
> > problem is there are so many thousands of different URLs you can get
> > to on that site, and google indexes them
On Wed, Jul 10, 2013 at 9:36 AM, Magnus Hagander wrote:
> We already run this, that's what we did to make it survive at all. The
> problem is there are so many thousands of different URLs you can get
> to on that site, and google indexes them all by default.
There's also https://support.google.co
Hi,l
I create fsync v3 v4 v5 patches and test them.
* Changes
- Add considering about total checkpoint schedule in fsync phase (v3 v4 v5)
- Add considering about total checkpoint schedule in write phase (v4 only)
- Modify some implementations from v3 (v5 only)
I use linear combination method
On Wed, Jul 10, 2013 at 2:39 AM, Peter Eisentraut wrote:
> I would like to start using a newer version of docbook-xsl for the
> release builds. This is currently used for building the man pages. The
> latest release is 1.78.1 and fixes a few formatting errors.
>
> How do we do that?
>
> We could
On 19 June 2013 18:12, Peter Eisentraut wrote:
> On 6/19/13 11:50 AM, Dean Rasheed wrote:
>> On 19 June 2013 15:22, Peter Eisentraut wrote:
>>> We still don't have any support for this in psql, do we?
>>>
>>
>> No, but at least we now have an API that psql can use.
>>
>> There are still a number
Hi,
since the mvcc catalog patch has gone in we require all users of
systable_* to be in a valid transaction since the snapshot is copied via
CopySnapshot() in RegisterSnapshot(). Which we call in
systable_beginscan(). CopySnapshot() allocates the copied snapshot in
TopTransactionContext.
There d
While applying latest version of the patch (regress-big-v4.patch) on
latest PostgreSQL version i encountered following errors: [...]
Is that a problem ?
Yes and no:-)
My understanding is that there is a conflict because of commits between
this patch and head: a file that this patch delet
Hi Fabien,
While applying latest version of the patch (regress-big-v4.patch) on
latest PostgreSQL version i encountered following errors:
a) Using git:
$git apply --index regress-big-v4.patch
regress-big-v4.patch:10: trailing whitespace.
$(srcdir)/parallel_schedule $(srcdir)/parallel_big_sche
28 matches
Mail list logo
