Hello
> Npgsql supports sending multiple SQL statements in a single packet via the
> extended protocol. This works fine, but when the second query SELECTs a value
> modified by the first's UPDATE, I'm getting a result as if the
> UPDATE hasn't yet occurred.
Looks like the first updating statem
On Mon, Sep 28, 2015 at 11:10:52AM -0400, Robert Haas wrote:
> On Fri, Sep 25, 2015 at 3:41 AM, Andreas Seltenreich
> wrote:
> > OTOH, a unit test for multixact.c that exercises the code including
> > wraparounds sounds like a desirable thing regardless of the fact that it
> > could have caught t
Attached is SortSupport for UUID type patch. This accelerates all UUID
related sort-intense operations, making them about twice as fast with
millions of tuples. I know that Heroku has plenty of tables used by
various applications with a UUID primary key, so it will be nice to
have CREATE INDEX go s
On Tue, Aug 4, 2015 at 12:41 PM, Robert Haas wrote:
> Some comments:
I attach a new version of the patch series that incorporates all your
feedback. The patch series is now made cumulative in a way that makes
it easy for someone to independently commit the unsigned integer
comparison optimization
Hi hackers, some odd behavior has been reported with Npgsql and I'm sure
you can help.
Npgsql supports sending multiple SQL statements in a single packet via the
extended protocol. This works fine, but when the second query SELECTs a
value modified by the first's UPDATE, I'm getting a result as if
On Sat, Oct 3, 2015 at 11:35 PM, Robert Haas wrote:
>
> On Fri, Oct 2, 2015 at 11:44 PM, Amit Kapila
wrote:
> > On Thu, Oct 1, 2015 at 7:41 PM, Robert Haas
wrote:
> >> Does heap_parallelscan_nextpage really need a pscan_finished output
> >> parameter, or can it just return InvalidBlockNumber to
Andres,
Thanks so much for the review!
I put all changes relative to your review here if you want a nice colorized
place to check
https://github.com/pramsey/postgres/commit/ed33e7489601e659f436d6afda3cce28304eba50
On October 3, 2015 at 8:49:04 AM, Andres Freund (and...@anarazel.de) wrote:
> +
I've prepared first-draft release notes for Monday's minor releases:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=01ef33701bf6d475deeb550c18a5c3fd698c9623
(If you don't like reading raw SGML, it should be up at
http://www.postgresql.org/docs/devel/static/release.html
a couple
Josh Berkus writes:
> On 10/02/2015 09:39 PM, Tom Lane wrote:
>> I wrote:
>>> Here's a rewritten patch that looks at postmaster.pid instead of
>>> pg_control. It should be effectively the same as the prior patch in terms
>>> of response to directory-removal cases, and it should also catch many
>>
On Sun, Oct 4, 2015 at 12:15 AM, Andres Freund wrote:
> On 2015-09-20 16:38:58 +0200, Petr Jelinek wrote:
> Michael: Why did you exclude test_extensions in Mkvcbuild.pm?
test_extensions contains nothing that should be compiled, only things
that should be installed.
--
Michael
--
Sent via pgsq
On 10/03/2015 04:49 PM, Peter Geoghegan wrote:
On Mon, Sep 21, 2015 at 2:21 PM, Andrew Dunstan wrote:
Thanks for the explanation. So, basically, it should be like this, am I
right?
postgres=# SELECT jsonb_set(
'{"name": "Joe", "vehicle_types": ["car", "van"]}'::jsonb,
'{vehicle_typ
On Mon, Sep 21, 2015 at 2:21 PM, Andrew Dunstan wrote:
>> Thanks for the explanation. So, basically, it should be like this, am I
>> right?
>>
>> postgres=# SELECT jsonb_set(
>> '{"name": "Joe", "vehicle_types": ["car", "van"]}'::jsonb,
>> '{vehicle_types, nonsense}',
>> '"motorcycle"'
On 10/02/2015 09:39 PM, Tom Lane wrote:
> I wrote:
>> Here's a rewritten patch that looks at postmaster.pid instead of
>> pg_control. It should be effectively the same as the prior patch in terms
>> of response to directory-removal cases, and it should also catch many
>> overwrite cases.
>
> BTW,
On Fri, Oct 2, 2015 at 4:27 PM, Tom Lane wrote:
> ... do you want to produce an updated patch? I'm not planning to look at
> it until tomorrow anyway.
Attached, revised patch deals with the issues around removing the
query text file when garbage collection encounters trouble. There is
no reason
On Fri, Oct 2, 2015 at 11:44 PM, Amit Kapila wrote:
> On Thu, Oct 1, 2015 at 7:41 PM, Robert Haas wrote:
>> Does heap_parallelscan_nextpage really need a pscan_finished output
>> parameter, or can it just return InvalidBlockNumber to indicate end of
>> scan? I think the latter can be done and wo
On Sat, Oct 3, 2015 at 6:38 AM, Andres Freund wrote:
> I'm not arguing against any of this - but I don't think this needs to be
> on the 9.5 open items list. I plan to remove from there.
Obviously I don't think that this is a critical fix. I do think that
it would be nice to keep the branches in
On 2015-10-03 17:56:07 +0200, Petr Jelinek wrote:
> On 2015-10-03 17:16, Andres Freund wrote:
> >On 2015-10-03 17:15:54 +0200, Andres Freund wrote:
> >>Here's an updated patch. Petr, could you please expand the test to
> >>handle a bit more complex cascading setups?
> >
>
> Okay, I changed the tes
Hi,
I quickly read through the patch, trying to understand what exactly is
happening here. To me the way the patch is split doesn't make much sense
- I don't mind incremental patches, but right now the steps don't
individually make sense.
On 2015-07-02 14:22:13 -0400, Robbie Harwood wrote:
> +#in
On 2015-10-03 17:16, Andres Freund wrote:
On 2015-10-03 17:15:54 +0200, Andres Freund wrote:
Here's an updated patch. Petr, could you please expand the test to
handle a bit more complex cascading setups?
Okay, I changed the test to make the dependencies bit more complex -
more than one depe
Hi,
On 2015-10-01 11:46:43 +0900, Michael Paquier wrote:
> diff --git a/contrib/postgres_fdw/option.c b/contrib/postgres_fdw/option.c
> index 7547ec2..864bf53 100644
> --- a/contrib/postgres_fdw/option.c
> +++ b/contrib/postgres_fdw/option.c
> @@ -19,6 +19,8 @@
> #include "catalog/pg_foreign_tabl
Hi,
this topic has seen a lot of activity/review. As development is ongoing
I'm moving the patch to the next CF.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacker
On 2015-08-27 01:12:54 +0200, Andreas Karlsson wrote:
> I think this is a real concern and one that I will look into, to see if it
> can be fixed with a reasonable amount of work.
This patch has been in waiting-for-author for a month. Marking it as
returned-with-feedback.
Greetings,
Andres Freun
On 2015-09-15 12:00:25 +0200, Franck Verrot wrote:
> diff --git a/src/backend/parser/parse_target.c
> b/src/backend/parser/parse_target.c
> index 1b3fcd6..78f82cd 100644
> --- a/src/backend/parser/parse_target.c
> +++ b/src/backend/parser/parse_target.c
> @@ -389,6 +389,17 @@ markTargetListOrigin(
On 2015-10-03 17:15:54 +0200, Andres Freund wrote:
> Here's an updated patch. Petr, could you please expand the test to
> handle a bit more complex cascading setups?
...
>From fa11dc75500eb91b68baeeb07a00a789ed0050b3 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Sat, 3 Oct 2015 17:01:32 +020
On 2015-09-20 16:38:58 +0200, Petr Jelinek wrote:
> Here it is.
I went over the patch, trying to commit it. Changed a bunch of stylistic
issues (comments, NOTICE location, ...) . But also found a bug: Namely
cascade_parent was set wrongly in a bunch of situations: When an
extension has multiple de
Michael Paquier writes:
> On Sat, Oct 3, 2015 at 1:39 PM, Tom Lane wrote:
>> BTW, my thought at the moment is to wait till after next week's releases
>> to push this in. I think it's probably solid, but it doesn't seem like
>> it's worth taking the risk of pushing shortly before a wrap date.
>
Hi!
On 2015-09-22 15:24:38 +, Syed, Rahila wrote:
> Please find attached patch with bugs reported by Thom and Sawada-san solved.
This thread has seen a bunch of reviews and new patch versions, but
doesnt yet seem to have arrived in a committable state. As the
commitfest ended and this patch h
Hi,
On 2015-09-01 00:13:07 -0400, Peter Eisentraut wrote:
> Here is a series of patches to clean up the Unicode mapping script
> business in src/backend/utils/mb/Unicode/. It overlaps with the
> perlcritic work that I recently wrote about, except that these pieces
> are not strictly related to Pe
Hi,
On 2015-08-31 23:57:25 -0400, Peter Eisentraut wrote:
> We now have 80+ Perl files in our tree, and it's growing. Some of those
> files were originally written for Perl 4, and the coding styles and
> quality are quite, uh, divergent. So I figured it's time to clean up
> that code a bit. I r
On Sat, Oct 3, 2015 at 9:50 PM, Amir Rohan wrote:
> On 10/03/2015 02:38 PM, Michael Paquier wrote:
>> On Fri, Oct 2, 2015 at 11:10 PM, Amir Rohan wrote:
>>> On 10/02/2015 03:33 PM, Michael Paquier wrote:
> 4) Port assignment relies on liveness checks on running servers.
> If a server is sh
Hi,
On 2015-06-10 16:19:27 -0700, Peter Geoghegan wrote:
> Currently, speculative insertion (the INSERT ... ON CONFLICT DO UPDATE
> executor/storage infrastructure) uses checkUnique ==
> UNIQUE_CHECK_PARTIAL for unique indexes, which is a constant
> originally only used by deferred unique constrai
Hi,
On 2015-09-25 17:39:41 +0530, Rushabh Lathia wrote:
> PFA patch to fix the hint message.
The patched missed updating the regression test output files ;)
Committed and backpatched back to 9.4. Thanks!
- Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
Hi,
> db=# INSERT INTO brokentab(id, k1,k2,k3,k4,k5,k6,k7, smallval) VALUES
> (5,0,0,0,1,0,1,0, 0) ON CONFLICT (id, k1,k2,k3,k4,k5,k6,k7) DO UPDATE SET
> smallval=EXCLUDED.smallval;
> ERROR: attribute 29 has wrong type
> DETAIL: Table has type integer, but query expects smallint.
I pushed a fix
On 10/03/2015 03:50 PM, Amir Rohan wrote:
> On 10/03/2015 02:38 PM, Michael Paquier wrote:
>> On Fri, Oct 2, 2015 at 11:10 PM, Amir Rohan wrote:
>>> On 10/02/2015 03:33 PM, Michael Paquier wrote:
>>>
>>> Granted, you have to try fairly hard to shoot yourself in the leg,
>>> but since the solution i
On 10/03/2015 02:38 PM, Michael Paquier wrote:
> On Fri, Oct 2, 2015 at 11:10 PM, Amir Rohan wrote:
>> On 10/02/2015 03:33 PM, Michael Paquier wrote:
>>> Any server instances created during the tests should never use a
>>> user-defined port for portability. Hence using those ports as keys
>>> just
On Fri, Oct 2, 2015 at 11:10 PM, Amir Rohan wrote:
> On 10/02/2015 03:33 PM, Michael Paquier wrote:
> > Any server instances created during the tests should never use a
> > user-defined port for portability. Hence using those ports as keys
> > just made sense. We could have for example custom names
On 2015-10-03 08:27, Amit Kapila wrote:
On Fri, Oct 2, 2015 at 8:14 PM, Alexander Korotkov
mailto:a.korot...@postgrespro.ru>> wrote:
>
>
> I agree about staying with one SQL-visible function.
Okay, this does not necessarily mean there should be only one validation
function in the C struct t
> My proposal in this WIP patch is to make it a bit clearer that
> 'EXCLUDED' isn't a real relation. I played around with adding a
> different rtekind, but that's too heavy a hammer. What I instead did was
> to set relkind to composite - which seems to signal pretty well that
> we're not dealing wi
38 matches
Mail list logo