Hi,
I noticed some errors in the comments of the patch committed. Please
find attached a patch to correct that.
Regards,
--
Michael
20130704_reltoastidxid_comments.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Wednesday, July 03, 2013 7:41 PM Robert Haas wrote:
> On Wed, Jul 3, 2013 at 9:51 AM, Amit Kapila
> wrote:
> > amit@linux:~> md test
> > amit@linux:~> cd test
> > amit@linux:~/test> ln -s ~/test link_test
> > amit@linux:~/test> ls
> > link_test
> > amit@linux:~/test> cd link_test
> > amit@linux
Hi all,
The bgworker documentation does not explicitely mention that a
bgworker using BGWORKER_BACKEND_DATABASE_CONNECTION needs to have
BGWORKER_SHMEM_ACCESS set as well.
Just to mention, a bgworker using only db connection flag and not
shmem flag will fail at atart-up with this error.
backgroun
I apologize. I guess the Travis CI integration is a little better than I
expected. I'm traveling but will turn off notifications as soon as I have a
chance to.
Per Peter's comment there is more info in the GitHub project, and I welcome
any feedback. I'll follow up with more once this is a little m
Josh Berkus wrote:
> On 07/03/2013 04:05 PM, Alvaro Herrera wrote:
> > Josh Berkus escribió:
> >> Liming,
> >>
> >> Given that this patch will not be ready for commit this week, but has
> >> gotten a review, I am marking it as "Returned with Feedback". Please
> >> keep working on it, and as soon
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Josh Berkus replied:
>> I won't go into details here because frankly why I have no time
>> for reviewing a patch is none of your business.
>
> Then just send an email saying "Sorry, I don't have any time for patch
> review this time. Maybe ne
On Mon, 2013-05-06 at 17:17 +0200, Dimitri Fontaine wrote:
> Please find attached a patch against the documentation, containing a
> full code example of what I had in mind.
Applied with some tweaks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, Jul 3, 2013 at 5:36 PM, Andrew Dunstan wrote:
> Does anyone know why I received the message below, or how to turn it off?
>
> Sending out notifications such as this (bogus in this case anyway) is
> unfriendly.
This was an oversight. I'm sorry you were affected in this way.
My colleague M
Does anyone know why I received the message below, or how to turn it off?
Sending out notifications such as this (bogus in this case anyway) is
unfriendly.
cheers
andrew
Original Message
Subject:[Still Failing] pg-quilter/postgres#111 (master - 82b0102)
Date: W
On Thu, Jul 4, 2013 at 8:05 AM, Alvaro Herrera wrote:
> Josh Berkus escribió:
>> Liming,
>>
>> Given that this patch will not be ready for commit this week, but has
>> gotten a review, I am marking it as "Returned with Feedback". Please
>> keep working on it, and as soon as you have a new versio
Heya,
I see what you are saying, the problem as I see it is that the action we
are taking here is "disable chasing ldap referrals". If the name is
ldapreferrals and we use a boolean then setting it to 1 reads in a counter
intuitive manner:
"set ldapreferals=true to disable chasing LDAP referra
On Wed, Jul 3, 2013 at 11:19 PM, Robert Haas wrote:
> On Mon, Jun 24, 2013 at 3:51 AM, Michael Paquier
> wrote:
>> 3) Why not adding an other function in worker_spi.c being the opposite
>> of worker_spi_launch to stop dynamic bgworkers for a given index
>> number? This would be only a wrapper of
First of all, I'd like to give a big Thank You to all the hackers and
slackers that make Postgres great. You've really done an amazing job.
I'll step up and take a healthy portion of the blame here. I enjoy the
awesome features & fixes that all of you put out year after year, but I
have yet to c
On Wed, Jul 3, 2013 at 03:34:06PM -0700, Josh Berkus wrote:
> On 07/03/2013 03:08 PM, Robert Haas wrote:
> > You are way out of line. You have no right to expect ANYONE to
> > participate in patch review and commit. Michael is doing us a favor
> > by maintaining ECPG even though he's not heavily
On 07/03/2013 04:05 PM, Alvaro Herrera wrote:
> Josh Berkus escribió:
>> Liming,
>>
>> Given that this patch will not be ready for commit this week, but has
>> gotten a review, I am marking it as "Returned with Feedback". Please
>> keep working on it, and as soon as you have a new version of the
Peter,
I've been playing with the new patch, and haven't been able to reproduce
the load problem created by the original patch. So that seems fixed.
I'm not comfortable with having all of the transform mappings in the
main contrib/ directory though. Can we add a subdirectory called
"transforms"
Josh Berkus escribió:
> Liming,
>
> Given that this patch will not be ready for commit this week, but has
> gotten a review, I am marking it as "Returned with Feedback". Please
> keep working on it, and as soon as you have a new version of the patch,
> add it to the September commitfest. Thanks
Liming,
Given that this patch will not be ready for commit this week, but has
gotten a review, I am marking it as "Returned with Feedback". Please
keep working on it, and as soon as you have a new version of the patch,
add it to the September commitfest. Thanks!
--
Josh Berkus
PostgreSQL Expe
On Wed, Jul 3, 2013 at 6:34 PM, Josh Berkus wrote:
> On 07/03/2013 03:08 PM, Robert Haas wrote:
>> You are way out of line. You have no right to expect ANYONE to
>> participate in patch review and commit. Michael is doing us a favor
>> by maintaining ECPG even though he's not heavily involved in
On 07/03/2013 03:08 PM, Robert Haas wrote:
> You are way out of line. You have no right to expect ANYONE to
> participate in patch review and commit. Michael is doing us a favor
> by maintaining ECPG even though he's not heavily involved in the
> project any more and has other things to do with h
Liming Hu escribió:
> I do not have a 9.3 environment. I did not change any previous existing code.
git checkout REL9_3_STABLE
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-
On Mon, Jul 1, 2013 at 8:09 AM, Alvaro Herrera wrote:
> Joe Conway escribió:
>
>> Actually, given that this change will create version 1.1 of the
>> extension, I believe the 1.0 versions of the sql scripts should
>> probably be removed entirely. Can someone with more knowledge of the
>> extension
On Sat, Jun 29, 2013 at 7:55 PM, Michael Paquier
wrote:
> On Sun, Jun 30, 2013 at 5:37 AM, Joe Conway wrote:
>> Actually, given that this change will create version 1.1 of the
>> extension, I believe the 1.0 versions of the sql scripts should
>> probably be removed entirely. Can someone with more
On Wed, Jul 3, 2013 at 5:16 PM, Josh Berkus wrote:
> I'm not going to apologize for expecting *committers* to participate in
> patch review and commit.
You are way out of line. You have no right to expect ANYONE to
participate in patch review and commit. Michael is doing us a favor
by maintaini
On 07/03/2013 05:52 PM, Robert Haas wrote:
On Mon, Jul 1, 2013 at 5:04 PM, Andrew Dunstan wrote:
These changes are fairly small and mostly non-invasive, but if I've broken
something we should find out about it fairly quickly, I hope.
Turns out you broke something. Specifically, contrib/spi n
Peter, Cedric, etc.:
Where are we on this patch? Seems like discussion died out. Should it
be bounced?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On Wed, Jul 3, 2013 at 3:04 PM, Fabien COELHO wrote:
>> The buildfarm is sad.
>
> Do you have a pointer about the issue?
>
> Is it that builds are performed in some particular locale?
Tom posted an example of the error message on the related
pgsql-hackers thread. On some systems, no locales can
On Mon, Jul 1, 2013 at 5:04 PM, Andrew Dunstan wrote:
> These changes are fairly small and mostly non-invasive, but if I've broken
> something we should find out about it fairly quickly, I hope.
Turns out you broke something. Specifically, contrib/spi now only
installs autoinc.control instead of
On 2013-07-03 14:16:09 -0700, Josh Berkus wrote:
> On 07/03/2013 02:03 PM, Michael Meskes wrote:
> > I won't go into details here because frankly why I have no time for
> > reviewing a
> > patch is none of your business.
>
> Then just send an email saying "Sorry, I don't have any time for patch
On 06/29/2013 01:37 PM, Joe Conway wrote:
> On 06/25/2013 01:37 PM, Liming Hu wrote:
>>> please remove "dameraulevenshteinnocompatible" related stuff, I
>>> just followed the template you created.
>>> "dameraulevenshteinnocompatible" was used in my first testing.
>
>>> diff -cNr
>>> /opt/src/pgsq
Hackers,
Please, oh please, won't someone review this? This patch has been 3
years in the making, so I suspect that it will NOT be a fast review.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 07/03/2013 02:03 PM, Michael Meskes wrote:
> I won't go into details here because frankly why I have no time for reviewing
> a
> patch is none of your business.
Then just send an email saying "Sorry, I don't have any time for patch
review this time. Maybe next time". It's pretty simple.
I
On Wed, Jul 03, 2013 at 12:34:50PM -0700, Josh Berkus wrote:
> If you didn't feel obligated, you wouldn't be pissed at me. You'd just
> blow it off (like Bruce did). I think you're angry with me because you
> feel guilty.
That is outrageous bullshit!
> My *personal* viewpoint is that all commit
On Wed, Jul 03, 2013 at 04:03:08PM -0400, Bruce Momjian wrote:
> I do understand Josh's frustration that something different had to be
> done.
As a matter of fact I do, too. I just think the style of blaming people in
public like this is not ideal.
As I said I didn't even notice this email in the
On Wed, Jul 03, 2013 at 09:47:13AM -0400, Robert Haas wrote:
> An attempt to prod a few more people into helping review.
>
> I can see that this pissed you off, and I'm sorry about that. But I
> don't think that was his intent.
I hoped for this kind of answer from him but ...
Michael
--
Michae
Kevin Grittner writes:
> Further testing shows that any UPDATE or DELETE statement acquires
> a RowExclusiveLock on every index on the table and holds it until
> end of transaction, whether or not any rows are affected and
> regardless of whether an index scan or a seqscan is used. In fact,
> jus
On Wed, Jul 3, 2013 at 12:34:50PM -0700, Josh Berkus wrote:
> Michael Meskes wrote:
> >> So, as an experiment, call it a mixed result. I would like to have some
> >> other way to motivate reviewers than public shame. I'd like to have
> >
> > Doesn't shame imply that people knew that were suppos
Tom Lane wrote:
> Kevin Grittner writes:
>> we acquire locks on all indexes even for a HOT UPDATE which uses
>> a seqscan, and hold those until end of transaction. Is there a
>> reason for that?
>
> Sounds dubious to me; although in the HOT code it might be that
> there's no convenient place to
On 2013-07-03 21:07:03 +0200, Fabien COELHO wrote:
>
> >>Here is a v2 which is more likely to work under VPATH.
>
> Here is a POC v4 which relies on multiple --schedule instead of creating
> concatenated schedule files.
>
> --
> Fabien.
> diff --git a/src/test/regress/GNUmakefile b/src/test/re
Le mercredi 3 juillet 2013 21:03:42, Christopher Browne a écrit :
> On Wed, Jul 3, 2013 at 2:24 PM, Cédric Villemain
wrote:
> > > Clearly I ticked off a bunch of people by publishing "the list". On
> > > the other hand, in the 5 days succeeding the post, more than a dozen
> > > additional people
Michael Meskes wrote:
>> So, as an experiment, call it a mixed result. I would like to have some
>> other way to motivate reviewers than public shame. I'd like to have
>
> Doesn't shame imply that people knew that were supposed to review patches in
> the first place? An implication that is not t
Kevin Grittner writes:
> OK. I had seen that no locks were held after the insert and wasn't
> aware that we acquired and then released them for each insert
> within a transaction. On the other hand, we acquire locks on all
> indexes even for a HOT UPDATE which uses a seqscan, and hold those
> un
On 04/07/13 01:31, Robert Haas wrote:
On Wed, Jul 3, 2013 at 4:18 AM, KONDO Mitsumasa
wrote:
I tested and changed segsize=0.25GB which is max partitioned table file size and
default setting is 1GB in configure option (./configure --with-segsize=0.25).
Because I thought that small segsize is goo
Tatsuo,
> Because I did not register the patch into CF page myself. I should
> have not posted it until I find any patch which I can take care
> of. Sorry for this.
My apologies! I did post the list of patches I'd added to the CF in my
"patch sweep" to -hackers, but I forgot to match it against
On Wed, Jul 3, 2013 at 8:07 PM, Andres Freund wrote:
> On 2013-07-02 16:29:56 -0400, Robert Haas wrote:
>> There's no possibility of getting confused here; if X is still around
>> at all, it's xmax is of the same generation as Y's xmin. Otherwise,
>> we've had an undetected XID wraparound.
>
> An
On 07/03/2013 03:00 PM, Alvaro Herrera wrote:
Robert Haas escribió:
I agree. I think it'd be a good idea to get the buildfarm to run the
existing collate.utf8.linux test regularly on platforms where it
passes,
+1
I can probably whip up a module for it. (I created the buildfarm module
sys
On 07/03/2013 02:50 PM, Josh Berkus wrote:
On 07/03/2013 07:43 AM, Robert Haas wrote:
Let's have a new schedule called minute-check with the objective to run the
common tests in 60 secs.
Note that we're below 60s even with assert and CLOBBER_CACHE_ALWAYS, at
least on my laptop.
I find that
Here is a v2 which is more likely to work under VPATH.
Here is a POC v4 which relies on multiple --schedule instead of creating
concatenated schedule files.
--
Fabien.diff --git a/src/test/regress/GNUmakefile b/src/test/regress/GNUmakefile
index d5935b6..8a39f7d 100644
--- a/src/test/regres
The buildfarm is sad.
Do you have a pointer about the issue?
Is it that builds are performed in some particular locale?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jul 3, 2013 at 2:24 PM, Cédric Villemain wrote:
> > Clearly I ticked off a bunch of people by publishing "the list". On the
> > other hand, in the 5 days succeeding the post, more than a dozen
> > additional people signed up to review patches, and we got some of the
> > "ready for committ
On Wed, Jul 3, 2013 at 1:07 PM, Andres Freund wrote:
> Well, nothing would prevent using the HeapTupleHeaderGetRawXmin() in
> those places. Exactly the number of callsites is what makes me think
> that somebody will get this wrong in the future.
Well, I guess I could go rework the whole patch tha
Robert Haas escribió:
> I agree. I think it'd be a good idea to get the buildfarm to run the
> existing collate.utf8.linux test regularly on platforms where it
> passes,
+1
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Wed, Jun 26, 2013 at 12:39 AM, Robert Haas wrote:
> On Thu, Jun 20, 2013 at 2:32 PM, Fujii Masao wrote:
>> On Thu, Jun 20, 2013 at 11:43 AM, Satoshi Nagayasu wrote:
>>> (2013/06/17 4:02), Fujii Masao wrote:
On Sat, Mar 9, 2013 at 3:23 PM, Satoshi Nagayasu wrote:
>
> It is o
Tom Lane wrote:
> Robert Haas writes:
>> Tom Lane wrote:
>>> Are we somehow not going through ExecOpenIndices?
>
>> I dunno. I just did a quick black-box test:
>>
>> [ begin; insert; without commit ]
>>
>> No foo_pkey anywhere.
>
> That proves nothing, as we don't keep such locks after the quer
On 07/03/2013 07:43 AM, Robert Haas wrote:
> Let's have a new schedule called minute-check with the objective to run the
>> common tests in 60 secs.
Note that we're below 60s even with assert and CLOBBER_CACHE_ALWAYS, at
least on my laptop.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts
On Thu, Jul 4, 2013 at 3:26 AM, Fujii Masao wrote:
> On Thu, Jul 4, 2013 at 2:41 AM, Fujii Masao wrote:
>> On Thu, Jul 4, 2013 at 2:36 AM, Andres Freund wrote:
>>> On 2013-07-04 02:32:32 +0900, Michael Paquier wrote:
> Wouldn't it make more sense to fetch the toast index oid in the query
>>
I wrote:
> So attached is a draft patch for this. It's not complete yet because
> there are various comments that are now wrong and need to be updated;
> but I think the code is functioning correctly.
Hm, spoke too soon :-(. This query causes an assertion failure, with or
without my draft patch:
On 6/6/13 4:09 PM, Heikki Linnakangas wrote:
> On 06.06.2013 20:24, Josh Berkus wrote:
>>> Yeah, something like that :-). I was thinking of letting the estimate
>>> decrease like a moving average, but react to any increases immediately.
>>> Same thing we do in bgwriter to track buffer allocations:
On Thu, Jul 4, 2013 at 2:41 AM, Fujii Masao wrote:
> On Thu, Jul 4, 2013 at 2:36 AM, Andres Freund wrote:
>> On 2013-07-04 02:32:32 +0900, Michael Paquier wrote:
>>> > Wouldn't it make more sense to fetch the toast index oid in the query
>>> > ontop instead of making a query for every relation?
>
> Clearly I ticked off a bunch of people by publishing "the list". On the
> other hand, in the 5 days succeeding the post, more than a dozen
> additional people signed up to review patches, and we got some of the
> "ready for committer" patches cleared out -- something which nothing
> else I did,
On Wed, Jul 3, 2013 at 1:38 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-07-03 13:29:18 -0400, Robert Haas wrote:
>>> I think that's a killer blow for this particular patch. I'm going to
>>> set this to rejected in the CF app.
>
>> Can't we use a alternative expected file for those?
>
Hello
> So my vote is for make_time(hour int, min int, sec float8).
>
so here is a patch
Regards
Pavel
> regards, tom lane
make_date.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
Andres Freund writes:
> On 2013-07-03 13:29:18 -0400, Robert Haas wrote:
>> I think that's a killer blow for this particular patch. I'm going to
>> set this to rejected in the CF app.
> Can't we use a alternative expected file for those?
Alternative expected files are a PITA to maintain, at lea
On 2013-07-04 02:32:32 +0900, Michael Paquier wrote:
> > Wouldn't it make more sense to fetch the toast index oid in the query
> > ontop instead of making a query for every relation?
> With something like a CASE condition in the upper query for
> reltoastrelid? This code path is not only taken by i
On Wed, Jul 3, 2013 at 11:16 PM, Andres Freund wrote:
> On 2013-07-03 10:03:26 +0900, Michael Paquier wrote:
>> index 9ee9ea2..23e0373 100644
>> --- a/src/bin/pg_dump/pg_dump.c
>> +++ b/src/bin/pg_dump/pg_dump.c
>> @@ -2778,10 +2778,9 @@ binary_upgrade_set_pg_class_oids(Archive *fout,
>> PQE
On 3 July 2013 15:43, Robert Haas wrote:
>
> > Let's have a new schedule called minute-check with the objective to run
> the
> > common tests in 60 secs.
> >
> > We can continue to expand the normal schedules from here.
> >
> > Anybody that wants short tests can run that, everyone else can run the
On 2013-07-03 13:29:18 -0400, Robert Haas wrote:
> On Wed, Jul 3, 2013 at 1:26 PM, Robert Haas wrote:
> >> Please revert.
> >
> > OK, sure, but just for my education and general enlightenment ... what
> > platform is that?
>
> Ah, never mind. I see that the buildfarm is quickly turning red -
> N
On Wed, Jul 3, 2013 at 1:26 PM, Robert Haas wrote:
>> Please revert.
>
> OK, sure, but just for my education and general enlightenment ... what
> platform is that?
Ah, never mind. I see that the buildfarm is quickly turning red -
NetBSD, OmniOS, and HP/UX are all unhappy.
I think that's a kille
On Wed, Jul 3, 2013 at 1:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> I did remove those, plus made some other cleanups, and committed this.
>> I think that there's now some duplication between this and the
>> collate.linux.utf8 test that should be cleaned up by removing the
>> duplicative st
Robert Haas writes:
> I did remove those, plus made some other cleanups, and committed this.
> I think that there's now some duplication between this and the
> collate.linux.utf8 test that should be cleaned up by removing the
> duplicative stuff from that test, assuming this holds up OK when the
2013/7/3 Tom Lane :
> Alvaro Herrera writes:
>> Peter Eisentraut escribió:
>>> On 7/1/13 3:47 AM, Pavel Stehule wrote:
CREATE OR REPLACE FUNCTION construct_time(hour int DEFAULT 0, mi int
DEFAULT 0, sec int DEFAULT 0, ms float DEFAULT 0.0);
>>>
>>> If we are using integer datetime storag
On 2013-07-02 16:29:56 -0400, Robert Haas wrote:
> On Mon, Jun 24, 2013 at 8:12 AM, Andres Freund wrote:
> > Agreed. And it also improves the status quo when debugging. I wish this
> > would have been the representation since the beginning.
> >
> > Some remarks:
> > * I don't really like that Heap
Alvaro Herrera writes:
> Peter Eisentraut escribió:
>> On 7/1/13 3:47 AM, Pavel Stehule wrote:
>>> CREATE OR REPLACE FUNCTION construct_time(hour int DEFAULT 0, mi int
>>> DEFAULT 0, sec int DEFAULT 0, ms float DEFAULT 0.0);
>>
>> If we are using integer datetime storage, we shouldn't use floats
On Thu, May 9, 2013 at 9:27 PM, Robins Tharakan wrote:
> One workaround is to use DROP COLLATION IF EXISTS, that conveys the message
> without UTF8 in the message string.
>
> But three other tests use ALTER COLLATION and I see no way but to comment /
> disable them. Currently have them disabled (w
2013/7/3 Alvaro Herrera :
> Peter Eisentraut escribió:
>> On 7/1/13 3:47 AM, Pavel Stehule wrote:
>
>> > CREATE OR REPLACE FUNCTION construct_time(hour int DEFAULT 0, mi int
>> > DEFAULT 0, sec int DEFAULT 0, ms float DEFAULT 0.0);
>>
>> If we are using integer datetime storage, we shouldn't use fl
Peter Eisentraut escribió:
> On 7/1/13 3:47 AM, Pavel Stehule wrote:
> > CREATE OR REPLACE FUNCTION construct_time(hour int DEFAULT 0, mi int
> > DEFAULT 0, sec int DEFAULT 0, ms float DEFAULT 0.0);
>
> If we are using integer datetime storage, we shouldn't use floats to
> construct them.
I thin
On Thu, May 9, 2013 at 4:29 AM, Fabien COELHO wrote:
> This updated version works for me and addresses previous comments.
>
> I think that such tests are definitely valuable, especially as many corner
> cases which must trigger errors are covered.
>
> I recommend to apply it.
I'm attaching an upd
On 3 July 2013 21:41, Pavel Stehule wrote:
> I am thinking so for these functions exists some consensus - minimally
> for function "date"(year, month, int) - I dream about this function
> ten years :)
>
> I am not sure about "datetime":
> a) we use "timestamp" name for same thing in pg
> b) we can
On 2013-07-03 11:08:32 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Jul 3, 2013 at 10:47 AM, Tom Lane wrote:
> >> Are we somehow not going through ExecOpenIndices?
>
> > I dunno. I just did a quick black-box test:
>
> > CREATE TABLE foo (a int primary key);
> > BEGIN;
> > INSERT IN
On Wed, Jul 3, 2013 at 11:14:18AM -0400, Bruce Momjian wrote:
> On Wed, Jul 3, 2013 at 10:54:48AM +0200, Willy-Bas Loos wrote:
> > Hi,
> >
> > I have some complicated query that truncates and fills a table and i get
> > this
> > message:
> > ERROR: smallint out of range
> > STATEMENT:
> > Thi
On Wed, May 8, 2013 at 9:19 PM, Robins Tharakan wrote:
> Please find attached an updated patch with the said changes.
> I'll try to update the other patches (if they pertain to this feedback) and
> update on their respective threads (as well as on Commitfest).
This patch updates the parallel sche
Andres Freund escribió:
> Just as a datapoint, if you benchmark the numbers of forks that can be
> performed by a single process (i.e. postmaster) the number is easily in
> the 10s of thousands. Now forking that much has some scalability
> implications inside the kernel, but still.
> I'd be surpri
On Wed, Jul 3, 2013 at 10:54:48AM +0200, Willy-Bas Loos wrote:
> Hi,
>
> I have some complicated query that truncates and fills a table and i get this
> message:
> ERROR: smallint out of range
> STATEMENT:
> This is in postgres 8.4
> I don't know where the error is, and the query takes rather l
On Tue, May 7, 2013 at 6:40 PM, Robins Tharakan wrote:
> Have provided an updated patch as per Fabien's recent response on Commitfest
> site.
> Any and all feedback is appreciated.
I think you should rename the roles used here to regress_rol_seq1 etc.
to match the CREATE OPERATOR patch.
And you
I noticed an instance of 'appendPQExpBuffer(query, ";");' in pg_dump.c which
seems pointless and mildly confusing. There's another seemingly
useless one in pg_dumpall.c. Attached patch removes both (if that
makes any sense).
Regards
Ian Barwick
pg_dump-cull-semicolons.patch
Description: Binary
Robert Haas writes:
> On Wed, Jul 3, 2013 at 10:47 AM, Tom Lane wrote:
>> Are we somehow not going through ExecOpenIndices?
> I dunno. I just did a quick black-box test:
> CREATE TABLE foo (a int primary key);
> BEGIN;
> INSERT INTO foo VALUES (1);
> SELECT relation::regclass, locktype, mode,
On Mon, May 13, 2013 at 8:37 PM, Robins Tharakan wrote:
> Hi,
>
> Patch to add more regression tests to ASYNC (/src/backend/commands/async).
> Take code-coverage from 39% to 75%.
>
> Any and all feedback is obviously welcome.
>
> p.s.: Please let me know whether these tests are useless or would no
On Wed, Jul 3, 2013 at 10:47 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jul 3, 2013 at 10:25 AM, Tom Lane wrote:
>>> I don't believe that that happens. If it does, it's a bug. Either the
>>> planner or the executor should be taking a lock on each index touched
>>> by a query.
>
>> It
Robert Haas writes:
> On Wed, Jul 3, 2013 at 10:25 AM, Tom Lane wrote:
>> I don't believe that that happens. If it does, it's a bug. Either the
>> planner or the executor should be taking a lock on each index touched
>> by a query.
> It seems Kevin's right. Not sure why that doesn't break.
A
On Wed, Jul 3, 2013 at 2:28 AM, Simon Riggs wrote:
>> It's sad to simply reject meaningful automated tests on the basis of doubt
>> that they're important enough to belong in every human-in-the-loop test
>> run.
>> I share the broader vision for automated testing represented by these
>> patches.
>
On Wed, Jul 3, 2013 at 10:25 AM, Tom Lane wrote:
> Kevin Grittner writes:
>> Robert Haas wrote:
>>> I doubt very much that this is safe. And even if it is safe
>>> today, I think it's a bad idea, because we're likely to try to
>>> reduce lock levels in the future. Taking no lock on a relation
Kevin Grittner writes:
> Robert Haas wrote:
>> I doubt very much that this is safe. And even if it is safe
>> today, I think it's a bad idea, because we're likely to try to
>> reduce lock levels in the future. Taking no lock on a relation
>> we're opening, even an index, seems certain to be a b
On Mon, Jun 24, 2013 at 3:51 AM, Michael Paquier
wrote:
> 3) Why not adding an other function in worker_spi.c being the opposite
> of worker_spi_launch to stop dynamic bgworkers for a given index
> number? This would be only a wrapper of pg_terminate_backend, OK, but
> at least it would give the u
Robert Haas wrote:
> Hitoshi Harada wrote:
>> Other than these, I've found index is opened with NoLock,
>> relying on ExclusiveLock of parent matview, and ALTER INDEX SET
>> TABLESPACE or something similar can run concurrently, but it is
>> presumably safe. DROP INDEX, REINDEX would be blocked b
On 2013-07-03 10:03:26 +0900, Michael Paquier wrote:
> +static int
> +toast_open_indexes(Relation toastrel,
> +LOCKMODE lock,
> +Relation **toastidxs,
> +int *num_indexes)
> + /*
> + * Free inde
On Wed, Jul 3, 2013 at 9:51 AM, Amit Kapila wrote:
> amit@linux:~> md test
> amit@linux:~> cd test
> amit@linux:~/test> ln -s ~/test link_test
> amit@linux:~/test> ls
> link_test
> amit@linux:~/test> cd link_test
> amit@linux:~/test/link_test> ls
> link_test
> amit@linux:~/test/link_test> cd link_
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Wednesday, July 03, 2013 6:40 PM
> To: Amit Kapila
> Cc: Andres Freund; Josh Berkus; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages
>
> On Wed, Jul 3, 201
On Wed, Jul 3, 2013 at 9:21 AM, Michael Meskes wrote:
> On Tue, Jul 02, 2013 at 04:00:22PM -0400, Robert Haas wrote:
>> make you review patches against your will. Don't take it for more
>> than what Josh meant it as.
>
> And that was what?
An attempt to prod a few more people into helping review
On 2013-07-03 17:18:29 +0900, KONDO Mitsumasa wrote:
> Hi,
>
> I tested and changed segsize=0.25GB which is max partitioned table file size
> and
> default setting is 1GB in configure option (./configure --with-segsize=0.25).
> Because I thought that small segsize is good for fsync phase and back
On Wednesday, July 03, 2013 6:29 PM Simon Riggs wrote:
On 3 July 2013 07:45, Amit Kapila wrote:
>>> postgresql.auto.conf is similar enough to postgresql.conf that it will
prevent tab completion from working as it does now. As a result it will
cause
>>> people to bring that file up for editing wh
1 - 100 of 124 matches
Mail list logo
