On 26 September 2014 12:24, Amit Kapila Wrote,
>I don't think this can handle cancel requests properly because
>you are just setting it in GetIdleSlot() what if the cancel
>request came during GetQueryResult() after sending sql for
>all connections (probably thats the reason why Jeff is not able
>
On 26 September 2014 01:24, Jeff Janes Wrote,
>I think you have an off-by-one error in the index into the array of file
>handles.
>Actually the problem is that the socket for the master connection was not
>getting initialized, see my one line addition here.
> connSlot = (ParallelSlot*)pg_ma
On 10/07/2014 03:58 AM, Arcadiy Ivanov wrote:
> Hi folks,
>
> My corp (CSC) OSS division requires CLAs to be signed for OSS project
> participation to begin. I need to fix a few problems in PGJDBC driver
> and am unable to start without them.
Would you mind enumerating those problems?
Ideally, i
On 10/07/2014 04:10 AM, Arcadiy Ivanov wrote:
> Thank you Magnus.
> The absence of legal entity and therefore of CLAs will make for an
> awesome discussion with legal. :D
They want a piece of paper to sign. So print out the PostgreSQL license.
Sign it. Hand it to them. That might satisfy them.
Th
On Mon, Oct 6, 2014 at 7:03 PM, Jim Nasby wrote:
> On 10/4/14, 8:12 PM, Robert Haas wrote:
>>> >It's just not sane to try to parse such text strings.
>>
>> But this is a pretty ridiculous argument. We have an existing parser
>> that does it just fine, and a special-purpose parser that does just
>
Robert Haas writes:
> On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut wrote:
>> The TAP tests
>> are arguably already much easier to debug than pg_regress ever was.
> Well, maybe. I wasn't able, after about 5 minutes of searching, to
> locate either a log file with details of the failure or th
On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut wrote:
> On Thu, 2014-10-02 at 21:18 -0400, Robert Haas wrote:
>> > If none of this gets us closer to an answer, I can try to produce a
>> > patch that produces more details for such failures.
>>
>> A test that fails for no reason that can be gleane
On Mon, Oct 6, 2014 at 10:23 PM, Sawada Masahiko
wrote:
>
> Hi all,
>
> pg_receivexlog always handles argument of -d option as connstr formatted
value.
> We can doubly specify host name, port number.
> The other client tools handles -d option as connstr value only if
> argument has "=" character.
On Mon, Oct 6, 2014 at 5:33 PM, Simon Riggs wrote:
> Lets look at a real world example
>
> CREATE TABLE citizen
> (ssninteger not null primary key
> ,email text not null unique
> ,tax_amount decimal);
>
> Transaction 1:
> INSERT INTO citizen VALUES (555123456, 'si...@2ndquadrant.com',
> 1000.
While reviewing the patch myself, i spotted some formatting problems in the
code. Fixed in this v5 patch.
Also, this patch uses context patch format (in first versions, because of
the small modification, context patch format obfucates the changes. After
reimplementation this isn't the case anymore
2014-10-03 23:14 GMT+07:00 Heikki Linnakangas :
> Fix xpath() to return namespace definitions (fixes the issue with nested
> or repeated xpath())
>
> Peter, you've done some XML stuff before; could you have a look at this
> too?
>
I am the author of the patch. I've sent Peter off-the-list revie
On Tue, Oct 7, 2014 at 9:57 AM, Tom Lane wrote:
> Michael Paquier writes:
> > Hm... I have tried changing the system locales (to en_US for example) and
> > time format but I can still trigger the issue all the time. I'll try to
> > have a closer look.. It looks like this test does not like some
Michael Paquier writes:
> Hm... I have tried changing the system locales (to en_US for example) and
> time format but I can still trigger the issue all the time. I'll try to
> have a closer look.. It looks like this test does not like some settings at
> the OS level.
I eventually realized that th
On 6 October 2014 15:04, Heikki Linnakangas wrote:
> On 10/06/2014 04:44 PM, Simon Riggs wrote:
>>
>> On 6 October 2014 13:21, Heikki Linnakangas
>> wrote:
>>
My understanding of what you're saying is that if
* we have a table with >1 unique index
* and we update the values of
On Thu, 2014-10-02 at 21:18 -0400, Robert Haas wrote:
> > If none of this gets us closer to an answer, I can try to produce a
> > patch that produces more details for such failures.
>
> A test that fails for no reason that can be gleaned from the output is
> not an improvement over not having a te
On Tue, Oct 7, 2014 at 8:14 AM, Michael Paquier
wrote:
> The system locales have nothing really special...
> $ locale
> LANG=
> LC_COLLATE="C"
> LC_CTYPE="UTF-8"
> LC_MESSAGES="C"
> LC_MONETARY="C"
> LC_NUMERIC="C"
> LC_TIME="C"
> LC_ALL=
> But now that you mention it I have as well that:
> $ def
On Mon, Oct 6, 2014 at 10:53 PM, Tom Lane wrote:
> The levenshtein-distance thingy seems to still be a topic of debate
> as well, both as to how we're going to refactor the code and as to
> what the exact hinting rules ought to be. If some committer wants
> to take charge of it and resolve those
On 10/6/14, 9:59 AM, Feike Steenbergen wrote:
It would test that when setting AUTOCOMMIT to off that you will not run into:
ERROR: [...] cannot run inside a transaction block
when issuing one of these PreventTransactionChain commands. In
src/bin/psql/common.c
Yes, but what happens when a new
2014-10-06 22:51 GMT+07:00 Marti Raudsepp :
> That's fine I think, it's just for tracking who made the changes in
> the CommitFest app. What actually matters is what you write in the
> "Author" field, which could contain all 3 names separated by commas.
>
Ok. Added to commitfest:
https://commitfe
On 10/5/14, 5:42 PM, Tom Lane wrote:
Gavin Flower writes:
The use of an /as_at_date/ is far more problematic. The idea relates to
how existing date/times should be treated with respect to the date/time
that a pg database is updated with new time zone data files. In the
simplest form: there w
On Mon, Oct 6, 2014 at 10:45 PM, Tom Lane wrote:
> Michael Paquier writes:
> > On Mon, Oct 6, 2014 at 1:15 PM, Tom Lane wrote:
> >> That looks about like mine too, though I'm not using --disable-rpath
> >> ... what's the reason for that?
>
> > No real reason. That was only some old remnant in a
On Tue, Oct 7, 2014 at 12:51 AM, Marti Raudsepp wrote:
> On Mon, Oct 6, 2014 at 6:12 PM, Ali Akbar wrote:
> > User apaan is me. When i added to the commitfest, the patch is listed
> there
> > by me (apaan).
> That's fine I think, it's just for tracking who made the changes in
> the CommitFest ap
On 10/4/14, 8:12 PM, Robert Haas wrote:
>It's just not sane to try to parse such text strings.
But this is a pretty ridiculous argument. We have an existing parser
that does it just fine, and a special-purpose parser that does just
that (and not all of the other stuff that the main parser does)
On Mon, Oct 06, 2014 at 07:24:32PM +0300, Heikki Linnakangas wrote:
> On 10/06/2014 07:00 PM, Gabriele Bartolini wrote:
> >Hello,
> >
> >2014-10-06 17:51 GMT+02:00 Marco Nenciarini >>:
> >
> >>I agree that a full backup does not need to include a profile.
> >>
> >>I've added the option to require
David,
On Monday, October 6, 2014, David Fetter wrote:
> On Mon, Oct 06, 2014 at 03:15:25PM -0400, Stephen Frost wrote:
>
> > > As far as I can see, the previous code only looked up any given name
> > > once. If you got a relation name, DoCopy() looked it up, and then
> > > BeginCopy() referenc
On Mon, Oct 06, 2014 at 03:15:25PM -0400, Stephen Frost wrote:
> > As far as I can see, the previous code only looked up any given name
> > once. If you got a relation name, DoCopy() looked it up, and then
> > BeginCopy() references it only by the passed-down Relation descriptor;
> > if you got a
Thanks Tom.
On 2014-10-06 16:06, Tom Lane wrote:
Arcadiy Ivanov writes:
My corp (CSC) OSS division requires CLAs to be signed for OSS project
participation to begin. I need to fix a few problems in PGJDBC driver
and am unable to start without them. Neither Google nor PG Wiki contain
CLA licens
Thank you Magnus.
The absence of legal entity and therefore of CLAs will make for an
awesome discussion with legal. :D
On 2014-10-06 16:04, Magnus Hagander wrote:
On Mon, Oct 6, 2014 at 9:58 PM, Arcadiy Ivanov wrote:
Hi folks,
My corp (CSC) OSS division requires CLAs to be signed for OSS pr
Arcadiy Ivanov writes:
> My corp (CSC) OSS division requires CLAs to be signed for OSS project
> participation to begin. I need to fix a few problems in PGJDBC driver
> and am unable to start without them. Neither Google nor PG Wiki contain
> CLA licenses and I have no idea where else to look.
On Mon, Oct 6, 2014 at 9:58 PM, Arcadiy Ivanov wrote:
> Hi folks,
>
> My corp (CSC) OSS division requires CLAs to be signed for OSS project
> participation to begin. I need to fix a few problems in PGJDBC driver and am
> unable to start without them. Neither Google nor PG Wiki contain CLA
> licens
Hi folks,
My corp (CSC) OSS division requires CLAs to be signed for OSS project
participation to begin. I need to fix a few problems in PGJDBC driver
and am unable to start without them. Neither Google nor PG Wiki contain
CLA licenses and I have no idea where else to look.
PostgreSQL Global De
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Oct 6, 2014 at 2:49 PM, Stephen Frost wrote:
> > Argh. That's certainly no good. It should just be using the RangeVar
> > relation passed in from CopyStmt, no?
>
> I don't think that's adequate. You can't do a RangeVar-to-OID
> translation
I left out a few words there.
On Mon, Oct 6, 2014 at 3:07 PM, Robert Haas wrote:
>> Hmm, that's certainly an interesting point, but I'm trying to work out
>> how this is different from normal COPY..? pg_analyze_and_rewrite()
>> happens for both cases down in BeginCopy().
>
> As far as I can see,
On Mon, Oct 6, 2014 at 2:49 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> In DoCopy, some RLS-specific code constructs a SelectStmt to handle
>> the case where COPY TO is invoked on an RLS-protected relation. But I
>> think this step is bogus in two ways:
>>
>>
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> First, because relations are schema objects, there could be multiple
>> relations with the same name. The RangeVar might end up referring to
>> a different one of those objects than the user originally specified.
> Argh. Th
On Mon, Oct 6, 2014 at 11:27 AM, Robert Haas wrote:
> Well, really, I was just suggesting that I can spend more time on the
> patch, but not immediately.
We haven't really talked about the idea of the HyperLogLog-based abort
mechanism - the actual cost model - even though I thought we'd have
disc
* Robert Haas (robertmh...@gmail.com) wrote:
> In DoCopy, some RLS-specific code constructs a SelectStmt to handle
> the case where COPY TO is invoked on an RLS-protected relation. But I
> think this step is bogus in two ways:
>
> /* Build FROM clause */
> from = makeRange
On Mon, Oct 6, 2014 at 1:58 PM, Peter Geoghegan wrote:
> On Mon, Oct 6, 2014 at 7:57 AM, Robert Haas wrote:
>> I haven't had time to look at it yet. Can we move it to the next
>> CommitFest? I spent a lot of time on this one, but I can't keep doing
>> that forever, because, you know, other work
On Mon, Oct 6, 2014 at 8:35 AM, Robert Haas wrote:
> I think the problem is that it's not possible to respect the "usual
> guarantees" even at READ COMMITTED level when performing an INSERT OR
> UPDATE operation (however spelled).
That's definitely the main problem. Also, there could be garden
va
In DoCopy, some RLS-specific code constructs a SelectStmt to handle
the case where COPY TO is invoked on an RLS-protected relation. But I
think this step is bogus in two ways:
/* Build FROM clause */
from = makeRangeVar(NULL, RelationGetRelationName(rel), 1);
First, becau
On Mon, Oct 6, 2014 at 7:57 AM, Robert Haas wrote:
> I haven't had time to look at it yet. Can we move it to the next
> CommitFest? I spent a lot of time on this one, but I can't keep doing
> that forever, because, you know, other work.
Are you suggesting that it would be useful to have input f
On Wed, Aug 27, 2014 at 9:02 AM, Michael Paquier
wrote:
>
> Hi all,
>
> In a couple of code paths we do the following to check permissions on an
object:
> if (pg_class_aclcheck(relid, userid, ACL_USAGE) != ACLCHECK_OK &&
> pg_class_aclcheck(relid, userid, ACL_UPDATE) != ACLCHECK_OK)
> erep
On Mon, Oct 6, 2014 at 11:13 AM, Marti Raudsepp wrote:
>
> On Mon, Oct 6, 2014 at 4:27 PM, Fabrízio de Royes Mello
> wrote:
> > create_index_if_not_exists_v7.patch
>
> Looks good to me. Marking ready for committer.
>
Thanks.
> If you have any feedback about my reviews, I would gladly hear it.
Hi all,
pg_receivexlog always handles argument of -d option as connstr formatted value.
We can doubly specify host name, port number.
The other client tools handles -d option as connstr value only if
argument has "=" character.
The document says that pg_receivexlog ignores database name, and this
On 10/06/2014 07:00 PM, Gabriele Bartolini wrote:
Hello,
2014-10-06 17:51 GMT+02:00 Marco Nenciarini
:
I agree that a full backup does not need to include a profile.
I've added the option to require the profile even for a full backup, as
it can be useful for backup softwares. We could remov
On Mon, Oct 6, 2014 at 12:18 PM, Marco Nenciarini
wrote:
>> - Ship a table-of-contents file with a list relation files currently
>> present and the length of each in blocks.
>
> Having the size in bytes allow you to use the same format for non-block
> files. Am I missing any advantage of having th
On Mon, Oct 6, 2014 at 12:06 PM, Marco Nenciarini
wrote:
> Il 06/10/14 17:55, Robert Haas ha scritto:
>> On Mon, Oct 6, 2014 at 11:51 AM, Marco Nenciarini
>> wrote:
>>> I agree that a full backup does not need to include a profile.
>>>
>>> I've added the option to require the profile even for a f
On 10/06/2014 07:06 PM, Marco Nenciarini wrote:
Il 06/10/14 17:55, Robert Haas ha scritto:
On Mon, Oct 6, 2014 at 11:51 AM, Marco Nenciarini
wrote:
I agree that a full backup does not need to include a profile.
I've added the option to require the profile even for a full backup, as
it can be
Il 06/10/14 17:50, Robert Haas ha scritto:
> On Mon, Oct 6, 2014 at 11:33 AM, Marco Nenciarini
> wrote:
>>> 2. Take a differential backup. In the backup label file, note the LSN
>>> of the fullback to which the differential backup is relative, and the
>>> newest LSN guaranteed to be present in th
On 10/06/2014 06:33 PM, Marco Nenciarini wrote:
Il 03/10/14 22:47, Robert Haas ha scritto:
2. Take a differential backup. In the backup label file, note the LSN
of the fullback to which the differential backup is relative, and the
newest LSN guaranteed to be present in the differential backup.
Il 06/10/14 17:55, Robert Haas ha scritto:
> On Mon, Oct 6, 2014 at 11:51 AM, Marco Nenciarini
> wrote:
>> I agree that a full backup does not need to include a profile.
>>
>> I've added the option to require the profile even for a full backup, as
>> it can be useful for backup softwares. We could
Hello,
2014-10-06 17:51 GMT+02:00 Marco Nenciarini :
> I agree that a full backup does not need to include a profile.
>
> I've added the option to require the profile even for a full backup, as
> it can be useful for backup softwares. We could remove the option and
> build the profile only during
On Mon, Oct 6, 2014 at 11:51 AM, Marco Nenciarini
wrote:
> I agree that a full backup does not need to include a profile.
>
> I've added the option to require the profile even for a full backup, as
> it can be useful for backup softwares. We could remove the option and
> build the profile only dur
On Mon, Oct 6, 2014 at 6:12 PM, Ali Akbar wrote:
> User apaan is me. When i added to the commitfest, the patch is listed there
> by me (apaan).
That's fine I think, it's just for tracking who made the changes in
the CommitFest app. What actually matters is what you write in the
"Author" field, wh
Il 06/10/14 16:51, Robert Haas ha scritto:
> On Mon, Oct 6, 2014 at 8:59 AM, Marco Nenciarini
> wrote:
>> Il 04/10/14 08:35, Michael Paquier ha scritto:
>>> On Sat, Oct 4, 2014 at 12:31 AM, Marco Nenciarini
>>> wrote:
Compared to first version, we switched from a timestamp+checksum based
>>>
On Mon, Oct 6, 2014 at 11:33 AM, Marco Nenciarini
wrote:
>> 1. Take a full backup. Basically, we already have this. In the
>> backup label file, make sure to note the newest LSN guaranteed to be
>> present in the backup.
>
> Don't we already have it in "START WAL LOCATION"?
Yeah, probably. I w
On 2014-10-06 11:38:47 -0400, Robert Haas wrote:
> On Thu, Oct 2, 2014 at 2:06 PM, Andres Freund wrote:
> >> Also, I pretty much designed those definitions to match what Linux
> >> does. And it doesn't require that either, though it says that in most
> >> cases it will work out that way.
> >
> >
On Thu, Oct 2, 2014 at 2:06 PM, Andres Freund wrote:
>> Also, I pretty much designed those definitions to match what Linux
>> does. And it doesn't require that either, though it says that in most
>> cases it will work out that way.
>
> My point is that that read barriers aren't particularly meani
On Fri, Oct 3, 2014 at 4:16 PM, Kevin Grittner wrote:
>> ... the SQL standard does not require that MERGE be atomic in the
>> sense of atomically providing either an INSERT or UPDATE, ...
>
> My understanding is that the standard logically requires (without
> concern for implementation details) th
Il 03/10/14 22:47, Robert Haas ha scritto:
> On Fri, Oct 3, 2014 at 12:08 PM, Marco Nenciarini
> wrote:
>> Il 03/10/14 17:53, Heikki Linnakangas ha scritto:
>>> If we're going to need a profile file - and I'm not convinced of that -
>>> is there any reason to not always include it in the backup?
>
> + select * from generate_series(0.1::numeric, 10.0::numeric, 0.1::numeric);
> + generate_series
> + -
> + 0.1
> ...
> + 10.0
> + (100 rows)
>
> Unless there is a good reason, can you please keep individual test
> output fewer than 100 lines? I think the 4
On Mon, Oct 6, 2014 at 10:59 AM, Andres Freund wrote:
> On 2014-10-06 10:46:09 -0400, Robert Haas wrote:
>> This seems messy, though. Can't the deferred trigger queue become
>> non-empty at pretty much any point in time? At exactly what point are
>> we making this decision, and how do we know th
On Tue, Sep 16, 2014 at 6:49 AM, Heikki Linnakangas
wrote:
As it happens, I also wrote an implementation of Slice-by-4 the other
day
>>>
>> If Heikki's version works I see little need to use my/Abhijit's
>> patch. That version has part of it under the zlib license. If Heikki's
>> version
On 2014-10-06 10:46:09 -0400, Robert Haas wrote:
> This seems messy, though. Can't the deferred trigger queue become
> non-empty at pretty much any point in time? At exactly what point are
> we making this decision, and how do we know the correct answer can't
> change after that point?
What we'v
It would test that when setting AUTOCOMMIT to off that you will not run into:
ERROR: [...] cannot run inside a transaction block
when issuing one of these PreventTransactionChain commands. In
src/bin/psql/common.c
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Fri, Oct 3, 2014 at 12:14 PM, Heikki Linnakangas
wrote:
> Sort support for text with strxfrm() poor man's keys
>
> Robert? What do you think of Peter's latest patch?
I haven't had time to look at it yet. Can we move it to the next
CommitFest? I spent a lot of time on this one, but I can't
On Mon, Oct 6, 2014 at 8:59 AM, Marco Nenciarini
wrote:
> Il 04/10/14 08:35, Michael Paquier ha scritto:
>> On Sat, Oct 4, 2014 at 12:31 AM, Marco Nenciarini
>> wrote:
>>> Compared to first version, we switched from a timestamp+checksum based
>>> approach to one based on LSN.
>> Cool.
>>
>>> This
On Mon, Oct 6, 2014 at 5:57 AM, David Rowley wrote:
>> Hm, right. But that doesn't seem like a fatal problem to me. The planner
>> knows about t1/t2 and Seq(t1), Seq(t2), not just Hash(Seq(t2)). So it
>> can tell the HashJoin node that when the 'shortcut' qualifier is true,
>> it should source eve
I'm a bit confused about who I should be replying to, but since you
were the last one with a patch...
On Mon, Oct 6, 2014 at 11:44 AM, Ali Akbar wrote:
> Thanks for the review. Attached the formatted patch according to your
> suggestion.
+ select * from generate_series(0.1::numeric, 10.0::numeri
On Mon, Oct 6, 2014 at 4:27 PM, Fabrízio de Royes Mello
wrote:
> create_index_if_not_exists_v7.patch
Looks good to me. Marking ready for committer.
If you have any feedback about my reviews, I would gladly hear it. I'm
quite new to this.
PS: You seem to be submitting many patches, but have you
On 10/06/2014 04:44 PM, Simon Riggs wrote:
On 6 October 2014 13:21, Heikki Linnakangas wrote:
My understanding of what you're saying is that if
* we have a table with >1 unique index
* and we update the values of the uniquely index columns (e.g. PK update)
* on both of the uniquely indexed co
Feike Steenbergen writes:
> I would like to propose to add a regression test for all statements
> that call PreventTransactionChain in autocommit-off mode.
What class of bug would that prevent exactly? It seems to me like
something that would normally get forgotten when we add any new
such state
On 6 October 2014 14:09, Michael Paquier wrote:
> That's a good catch and it should be a separate patch. This could even be
> considered for a back-patch down to 9.2. Thoughts?
If I isolate "DROP INDEX concurrently", this patch would do the trick.
20141006_drop_index_concurrently.patch
Descript
Heikki Linnakangas writes:
> Committers: Could you please pick a patch, and commit if appropriate? Or
> if there's a patch there that you think should *not* be committed,
> please speak up.
The "custom plan API" thing may be marked ready for committer, but that
doesn't mean it's committable, or
Michael Paquier writes:
> On Mon, Oct 6, 2014 at 1:15 PM, Tom Lane wrote:
>> That looks about like mine too, though I'm not using --disable-rpath
>> ... what's the reason for that?
> No real reason. That was only some old remnant in a build script that was
> here for ages :)
Hm. Grasping at st
On 6 October 2014 13:21, Heikki Linnakangas wrote:
>> My understanding of what you're saying is that if
>>
>> * we have a table with >1 unique index
>> * and we update the values of the uniquely index columns (e.g. PK update)
>> * on both of the uniquely indexed column sets
>> then we get occaiso
On Mon, Oct 6, 2014 at 4:49 AM, Marti Raudsepp wrote:
>
> On Mon, Oct 6, 2014 at 5:12 AM, Marti Raudsepp wrote:
> > On Mon, Oct 6, 2014 at 4:17 AM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> >> CREATE INDEX ... [ IF NOT EXISTS [ name ] ] ON ...
>
> > I think this one is wrong now
On 08/12/2014 03:53 PM, Heikki Linnakangas wrote:
On 08/12/2014 02:28 PM, Andres Freund wrote:
On 2014-08-12 14:01:18 +0300, Heikki Linnakangas wrote:
Also, to test sslmode=verify-full, where the client checks that the server
certificate's hostname matches the hostname that it connected to, you
Il 04/10/14 08:35, Michael Paquier ha scritto:
> On Sat, Oct 4, 2014 at 12:31 AM, Marco Nenciarini
> wrote:
>> Compared to first version, we switched from a timestamp+checksum based
>> approach to one based on LSN.
> Cool.
>
>> This patch adds an option to pg_basebackup and to replication protoco
On Mon, Oct 6, 2014 at 8:19 PM, Heikki Linnakangas
wrote:
> On 10/06/2014 04:42 AM, Michael Paquier wrote:
>
>> On Fri, Oct 3, 2014 at 9:51 PM, Heikki Linnakangas <
>> hlinnakan...@vmware.com>
>> wrote:
>>
>>> So I now have a refactoring patch ready that I'd like to commit (the
>>>
>> attached tw
On 10/06/2014 03:21 PM, Heikki Linnakangas wrote:
On 10/06/2014 03:05 PM, Simon Riggs wrote:
My understanding of what you're saying is that if
* we have a table with >1 unique index
* and we update the values of the uniquely index columns (e.g. PK update)
* on both of the uniquely indexed colum
On 10/06/2014 03:05 PM, Simon Riggs wrote:
On 3 October 2014 11:54, Heikki Linnakangas wrote:
Simon's approach would actually pass that test case just fine. It inserts
the (promise) index tuple first, and heap tuple only after that. It will
fail the test case with more than one unique index, h
On Mon, Oct 6, 2014 at 7:36 PM, Feike Steenbergen <
feikesteenber...@gmail.com> wrote:
> I would like to propose to add a regression test for all statements
> that call PreventTransactionChain in autocommit-off mode. I propose to
> add these tests to src/test/regress/sql/psql.sql as this is a
> ps
On 09/29/2014 01:13 PM, furu...@pm.nttdata.co.jp wrote:
I don't understand what this patch does. When would you want to use
the new --reply-fsync option? Is there any reason *not* to use it?
In other words, do we need an option for this, couldn't you just
always send the feedback message after fs
On 3 October 2014 11:54, Heikki Linnakangas wrote:
> Simon's approach would actually pass that test case just fine. It inserts
> the (promise) index tuple first, and heap tuple only after that. It will
> fail the test case with more than one unique index, however.
Please explain what you mean by
On Mon, Oct 6, 2014 at 8:01 PM, Andres Freund
wrote:
> Pushed with these adjustments.
>
Thanks. The portions changed look fine to me.
--
Michael
Il 03/10/14 23:12, Andres Freund ha scritto:
> On 2014-10-03 17:31:45 +0200, Marco Nenciarini wrote:
>> I've updated the wiki page
>> https://wiki.postgresql.org/wiki/Incremental_backup following the result
>> of discussion on hackers.
>>
>> Compared to first version, we switched from a timestamp+c
On 2014-10-06 14:19:39 +0300, Heikki Linnakangas wrote:
> On 10/06/2014 04:42 AM, Michael Paquier wrote:
> >On Fri, Oct 3, 2014 at 9:51 PM, Heikki Linnakangas
> >wrote:
> >>So I now have a refactoring patch ready that I'd like to commit (the
> >attached two patches together), but to be honest, I h
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane said:
...
> Craig Ringer writes:
>> While looking at an unrelated issue in PgJDBC I noticed that it's
>> difficult for users and the driver to tell in advance if a given
>> statement will support bind parameters.
>
> It's not that hard
Hi,
On 2014-10-04 15:01:03 +0900, Michael Paquier wrote:
> On Fri, Oct 3, 2014 at 8:57 PM, Andres Freund wrote:
> > >
> > > +pg_receivexlog can run in one of two
> > > following
> > > +modes, which control physical replication slot:
> >
> > I don't think that's good enough. There's
On Mon, Oct 6, 2014 at 7:14 PM, Andres Freund
wrote:
> On 2014-10-04 14:25:27 +0900, Michael Paquier wrote:
> > And as I am on it, attached is a patch that can be applied to master and
> > REL9_4_STABLE to rename the --create and --drop to --create-slot and
> > --drop-slot.
>
> Thanks.
>
> > diff
Hi all,
Lately I have come across two inconveniences/bugs related to running
the autocommit-off mode in psql.
These are:
- BUG #11524: Unable to add value to ENUM when having AUTOCOMMIT
disabled in psql
- BUG #10822: "ALTER SYSTEM cannot run inside a transaction block"
when having autocommit disa
On 2014-10-04 14:25:27 +0900, Michael Paquier wrote:
> And as I am on it, attached is a patch that can be applied to master and
> REL9_4_STABLE to rename the --create and --drop to --create-slot and
> --drop-slot.
Thanks.
> diff --git a/src/bin/pg_basebackup/pg_recvlogical.c
> b/src/bin/pg_baseb
I noticed that analyze messages shown by autovacuum don't discriminate
between non-inherited cases and inherited cases, as shown in the below
example:
LOG: automatic analyze of table "postgres.public.pt" system usage: CPU
0.00s/0.01u sec elapsed 0.06 sec
LOG: automatic analyze of table "postgres
On Wed, Oct 1, 2014 at 1:34 AM, Andres Freund
wrote:
> On 2014-10-01 01:03:35 +1300, David Rowley wrote:
> > On Wed, Oct 1, 2014 at 12:01 AM, Andres Freund
> > wrote:
> >
> > > On 2014-09-30 23:25:45 +1300, David Rowley wrote:
> > > >
> > > > I've not quite gotten my head around how we might sto
> Thanks. The main question now is design of this patch. Currently, it does
> all the work inside access method. We already have some discussion of pro
> and cons of this method. I would like to clarify alternatives now. I can
> see following way:
>
>1. Implement new executor node which perfor
Thanks for the review. Attached the formatted patch according to your
suggestion.
- numeric datatype is large, but there are limitations. According to doc,
>> the limit is: up to 131072 digits before the decimal point; up to 16383
>> digits after the decimal point. How can we check if the next ste
On Mon, Oct 6, 2014 at 5:12 AM, Marti Raudsepp wrote:
> On Mon, Oct 6, 2014 at 4:17 AM, Fabrízio de Royes Mello
> wrote:
>> CREATE INDEX ... [ IF NOT EXISTS [ name ] ] ON ...
> I think this one is wrong now.
I see now, I think you meant:
CREATE INDEX ... [ [ IF NOT EXISTS ] name ] ON ...
If
On Sun, Oct 5, 2014 at 7:39 PM, Ali Akbar wrote:
>
> 2014-10-05 15:21 GMT+07:00 Ali Akbar :
>
>> - i think you can use the fctx->current variable without temporary
>> variable (there's comment in the add_var function: Full version of add
>> functionality on variable level (handling signs). result
On 07/18/2014 10:47 AM, Michael Paquier wrote:
On Fri, Jul 18, 2014 at 3:54 AM, Peter Geoghegan wrote:
I am not opposed to moving the contrib code into core in the manner
that you oppose. I don't feel strongly either way.
I noticed in passing that your revision says this *within* levenshtein.c
100 matches
Mail list logo
