On Friday, March 25, 2016, Andrew Dunstan wrote:
>
> On 03/25/2016 04:13 AM, Matthias Kurz wrote:
>
>>
>> Hopefully at the commitfest at least the transaction limitation
>> will/could be tackled - that would help us a lot already.
>>
>>
> I don't believe anyone knows how to do that safely. Enums
On 26 March 2016 at 15:07, David Rowley wrote:
> Ok, so on further look at this I've decided to make changes and have
> it so the serialisation function can be dumb about memory contexts in
> the same way as finalize_aggregate() allows the final function to be
> dumb... notice at the end of the fu
I just discovered something which was a little alarming to me.
In the postgis_tiger_geocoder extension, I had switched to having the schema
where user data download is stored created as part of create extension
script so I wouldn't need to check during load.
So I have a statement like this in the
On Thu, Mar 24, 2016 at 8:08 AM, Amit Kapila
wrote:
>
> On Thu, Mar 24, 2016 at 5:40 AM, Andres Freund wrote:
> >
> > Even after changing to scale 500, the performance benefits on this,
> > older 2 socket, machine were minor; even though contention on the
> > ClogControlLock was the second most s
On 03/25/2016 03:22 PM, Christophe Pettus wrote:
On Mar 25, 2016, at 11:50 AM, Andrew Dunstan wrote:
I don't believe anyone knows how to do that safely.
The core issue, for me, is that not being able to modify enum values in a
transaction breaks a very wide variety of database migration to
On Fri, Mar 25, 2016 at 1:05 PM, Dilip Kumar wrote:
> On Fri, Mar 25, 2016 at 3:04 AM, Robert Haas wrote:
>> 1. Callers who use GetPageWithFreeSpace() rather than
>> GetPageFreeSpaceExtended() will fail to find the new pages if the
>> upper map levels haven't been updated by VACUUM.
>>
>> 2. Even
Hi, Dilip!
On Fri, Mar 25, 2016 at 8:32 PM, Dilip Kumar wrote:
> On Fri, Mar 25, 2016 at 8:09 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> Could anybody run benchmarks? Feature freeze is soon, but it would be
>> *very nice* to fit it into 9.6 release cycle, because it great
Tomas Vondra writes:
> I could do that, but isn't that a bit pointless? I thought pgindent is
> run regularly on the whole codebase, not for individual patches. Sure,
> it'll tweak the formatting on a few places in the patch (including the
> code discussed above, as you pointed out), but there
On 3/25/16 3:11 PM, Tom Lane wrote:
Jim Nasby writes:
the data, we're making it unnecessarily hard. All we need is one more
field in there, and you can simplify that to
Ahh, nice.
I think actually it's a simple point: there won't ever be a case where
cursorpos is set here, because that's on
On 3/25/16 3:54 PM, Artur Zakirov wrote:
> On 25.03.2016 21:42, Dmitry Ivanov wrote:
>> Sorry for the delay, I desperately needed some time to finish a bunch of
>> dangling tasks.
>>
>> I've added some new comments and clarified the ones that were obscure.
>> Moreover, I felt an urge to recheck mos
Typo in my last subject line - meant gitattributes. So should have lines
added like below
*.sheol=lf
*.ineol=lf
*.h.in eol=lf
*.h eol=lf
Thanks,
Regina
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
Tom et. al,
Thanks for fixing the SRF function order by thing. That test now passes
now, but there is one other test failing I was going to troubleshoot.
The problem is I can't compile from git postgresql, and the issue is I think
because my git when it pulls down the files they come in as CRLF
Jim Nasby writes:
> On 3/17/16 5:46 PM, Tom Lane wrote:
>> I started to look at this patch. It seems to me that the format of the
>> errorCode output is not terribly well designed.
> Getting the errorCode into an array is as easy as
> array set errorData [lrange $errorCode 1 end]
Well, my point
On 25.03.2016 21:42, Dmitry Ivanov wrote:
Sorry for the delay, I desperately needed some time to finish a bunch of
dangling tasks.
I've added some new comments and clarified the ones that were obscure.
Moreover, I felt an urge to recheck most parts of the code since apparently
nobody (besides my
On 3/25/16 2:22 PM, Gavin Flower wrote:
I've certainly heard people avoiding ENUMs because of their
limitations, so it'd be nice if there was a way to lift them.
Well, I use Enums extensively in Java.
However, I totally avoid using ENUMs in pg, due to their inflexibility!
Possibly related to
On 3/25/16 2:42 PM, Dmitry Ivanov wrote:
> Sorry for the delay, I desperately needed some time to finish a bunch of
> dangling tasks.
>
> I've added some new comments and clarified the ones that were obscure.
> Moreover, I felt an urge to recheck most parts of the code since apparently
> nobody
Andrew Dunstan writes:
> On 03/25/2016 04:13 AM, Matthias Kurz wrote:
>>
>> Hopefully at the commitfest at least the transaction limitation
>> will/could be tackled - that would help us a lot already.
>
> I don't believe anyone knows how to do that safely. Enums pose special
> problems here exact
On Mar 25, 2016, at 11:50 AM, Andrew Dunstan wrote:
> I don't believe anyone knows how to do that safely.
The core issue, for me, is that not being able to modify enum values in a
transaction breaks a very wide variety of database migration tools. Even a
very brutal solution like marking ind
On 26/03/16 08:17, Jim Nasby wrote:
On 3/24/16 10:27 PM, Tom Lane wrote:
It's conceivable that we could do something like adding an "isdead"
column to pg_enum and making enum_in reject new values that're marked
isdead. But I can't see that we'd ever be able to support true
removal of an enum va
On 3/24/16 10:27 PM, Tom Lane wrote:
It's conceivable that we could do something like adding an "isdead"
column to pg_enum and making enum_in reject new values that're marked
isdead. But I can't see that we'd ever be able to support true
removal of an enum value at reasonable cost. And I'm not
On 03/24/2016 12:40 PM, Matt Wilmas wrote:
(I notice the btree_gin docs don't mention "numeric," but it works.)
Numeric does work - we have regression tests to prove it, do we should
fix the docs. But I'm also curious to know why apparently we don't have
distance operator support for nume
On 03/25/2016 04:13 AM, Matthias Kurz wrote:
Hopefully at the commitfest at least the transaction limitation
will/could be tackled - that would help us a lot already.
I don't believe anyone knows how to do that safely. Enums pose special
problems here exactly because unlike all other ty
Sorry for the delay, I desperately needed some time to finish a bunch of
dangling tasks.
I've added some new comments and clarified the ones that were obscure.
Moreover, I felt an urge to recheck most parts of the code since apparently
nobody (besides myself) has gone so far yet.
On 25.03.16 1
> 25 марта 2016 г., в 19:11, David Steele написал(а):
>
> Hi Vladimir,
>
> On 3/14/16 2:15 PM, Vladimir Borodin wrote:
>
>> JFYI, I’m preparing the stand to reproduce the initial problem and I
>> hope to finish testing this week.
>
> Do you know when you'll have the results from the testing y
At 2016-03-24 22:48:51 +0530, a...@2ndquadrant.com wrote:
>
> > I think I would like to see code implement both alternatives to see
> > which one is least ugly. Maybe a third idea will manifest itself
> > upon seeing those.
>
> Here's the first one. ExecAlterObjectDependsStmt() looks like this:
Here is a new version of path, I hope I didn't miss anything. Few notes:
> 4.
> or even create a new constant (there can be better name for it):
> #define JB_PATH_CREATE_OR_INSERT (JB_PATH_INSERT_BEFORE |
> JB_PATH_INSERT_AFTER | JB_PATH_CREATE)
Good idea, thanks.
> 5.
> > if (op_type != JB_PATH
On Fri, Mar 25, 2016 at 8:09 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> Could anybody run benchmarks? Feature freeze is soon, but it would be
> *very nice* to fit it into 9.6 release cycle, because it greatly improves
> scalability on large machines. Without this patch PostgreS
On Fri, Mar 25, 2016 at 3:04 AM, Robert Haas wrote:
> 1. Callers who use GetPageWithFreeSpace() rather than
> GetPageFreeSpaceExtended() will fail to find the new pages if the
> upper map levels haven't been updated by VACUUM.
>
> 2. Even callers who use GetPageFreeSpaceExtended() may fail to fin
On Fri, Mar 25, 2016 at 12:39 PM, Tom Lane wrote:
> I wrote:
>> Robert Haas writes:
>>> On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane wrote:
We could resolve both of these issues by changing the semantics of
OprUpdate so that it unconditionally does a CommandCounterIncrement
after ea
Robert Haas writes:
> On Fri, Mar 25, 2016 at 9:48 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> It's stupid that we keep spending time and energy figuring out which
>>> shared memory data structures require alignment and which ones don't.
>>> Let's just align them *all* and be done with it. T
I wrote:
> Robert Haas writes:
>> On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane wrote:
>>> We could resolve both of these issues by changing the semantics of
>>> OprUpdate so that it unconditionally does a CommandCounterIncrement
>>> after each update that it performs. IMO that would be a lot simpl
On 25.03.2016 19:15, David Steele wrote:
On 3/25/16 12:14 PM, Artur Zakirov wrote:
On 25.03.2016 18:19, David Steele wrote:
Hi Artur,
On 3/20/16 10:42 AM, Tom Lane wrote:
"Shulgin, Oleksandr" writes:
On Mar 20, 2016 01:09, "Dmitrii Golub"
wrote:
Alex, actually subdomain can start with dig
On 3/25/16 12:14 PM, Artur Zakirov wrote:
On 25.03.2016 18:19, David Steele wrote:
Hi Artur,
On 3/20/16 10:42 AM, Tom Lane wrote:
"Shulgin, Oleksandr" writes:
On Mar 20, 2016 01:09, "Dmitrii Golub" wrote:
Alex, actually subdomain can start with digit,
Not according to the RFC you have l
On 25.03.2016 18:19, David Steele wrote:
Hi Artur,
On 3/20/16 10:42 AM, Tom Lane wrote:
"Shulgin, Oleksandr" writes:
On Mar 20, 2016 01:09, "Dmitrii Golub" wrote:
Alex, actually subdomain can start with digit,
Not according to the RFC you have linked to.
The powers-that-be relaxed that
Hi Simon,
On 3/14/16 3:42 PM, Tomas Vondra wrote:
Attached is v3 of the patch, and also three SQL scripts demonstrating
the impact of the patch on simple examples.
Do you know when you'll have a chance to review Tomas' latest patch?
Thanks,
--
-David
da...@pgmasters.net
--
Sent via pgsql-h
Hi Vladimir,
On 3/14/16 2:15 PM, Vladimir Borodin wrote:
JFYI, I’m preparing the stand to reproduce the initial problem and I
hope to finish testing this week.
Do you know when you'll have the results from the testing you were going
to do? It seems this patch is currently waiting on that to
On Fri, Mar 25, 2016 at 6:42 PM, David Steele wrote:
> On 3/16/16 12:38 PM, Dmitry Ivanov wrote:
>
> I've made an attempt to fix some of the issues you've listed, although
>> there's
>> still much work to be done. I'll add some comments later.
>>
>
> Do you know when you'll have a chance to respo
On 3/14/16 10:37 AM, David Steele wrote:
On 3/14/16 10:28 AM, Konstantin Knizhnik wrote:
Rebased patch is attached.
Thanks for the quick turnaround!
Marko, you are signed up to review this patch. Do you have an idea of
when you'll be able to do that?
Bump.
Since it looks like Marko has n
Hi Thomas,
On 3/13/16 8:20 PM, Thomas Munro wrote:
<...> I will have another look at this in
a few days but for now I need to do some other things, so I'm posting
these observations in case they are in some way helpful...
It's not clear to me what state this patch should be in but the thread
Hi Dmitry,
On 3/16/16 12:38 PM, Dmitry Ivanov wrote:
I've made an attempt to fix some of the issues you've listed, although there's
still much work to be done. I'll add some comments later.
Do you know when you'll have a chance to respond to reviews and provide
a new patch?
Time is short a
> In short: the error in Aleksander's argument is the assumption that
> shared hashtables have fixed size. That's simply false.
Well this is a bit embarrassing but I have to admit that you are right.
Dynahash code is a bit non-trivial to say the least (let me guess -
there is no point of suggesti
On 03/24/2016 06:45 PM, Alvaro Herrera wrote:
Tomas Vondra wrote:
+values[Anum_pg_mv_statistic_stamcv - 1] = PointerGetDatum(data);
Why the double space (that's actually in several places in several of
the patches).
To align the whole block like this:
nulls[Anum_pg_mv_statistic
Hi Artur,
On 3/20/16 10:42 AM, Tom Lane wrote:
"Shulgin, Oleksandr" writes:
On Mar 20, 2016 01:09, "Dmitrii Golub" wrote:
Alex, actually subdomain can start with digit,
Not according to the RFC you have linked to.
The powers-that-be relaxed that some time ago; I assume there's a newer
R
On Fri, Mar 25, 2016 at 9:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> It's stupid that we keep spending time and energy figuring out which
>> shared memory data structures require alignment and which ones don't.
>> Let's just align them *all* and be done with it. The memory cost
>> shouldn't
Hi Teador,
On 3/19/16 8:44 PM, Tomas Vondra wrote:
Sadly the v4 does not work for me - I do get assertion failures.
Time is growing short and there seem to be some serious concerns with
this patch. Can you provide a new patch soon? If not, I think it might
be be time to mark this "returne
Hi hackers,
As it's documented in the source code, systable_beginscan() could be used
to on non-system tables as well. My question is that, is it possible to
write a C code with systable_beginscan(), systable_getnext() and ScanKeys
which is equivalent to the following query: (Assume that the qual_
On Tue, Mar 22, 2016 at 1:08 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Tue, Mar 22, 2016 at 7:57 AM, Dilip Kumar
> wrote:
>
>>
>> On Tue, Mar 22, 2016 at 12:31 PM, Dilip Kumar
>> wrote:
>>
>>> ! pg_atomic_write_u32(&bufHdr->state, state);
>>> } while (!StartBufferIO(bufHd
On Thu, Mar 24, 2016 at 6:19 PM, Alvaro Herrera
wrote:
> .. Oh crap. I just noticed I forgot to update a comment in pg_dump's
> getAccessMethods. And we're missing psql tab-complete support for the
> new commands.
Attached patches fix both these issues.
--
Alexander Korotkov
Postgres Pro
Michael Paquier writes:
> On Fri, Mar 25, 2016 at 9:17 PM, Robert Haas wrote:
>> On Thu, Mar 24, 2016 at 9:50 AM, Aleksander Alekseev
>> wrote:
>>> Currently this procedure has two arguments --- init_size and max_size.
>>> But since shared hash tables have fixed size there is little sense to
>>>
On March 25, 2016 2:48:00 PM GMT+01:00, Robert Haas
wrote:
>On Fri, Mar 25, 2016 at 9:11 AM, Andres Freund
>wrote:
>> On March 25, 2016 1:04:13 PM GMT+01:00, Robert Haas
> wrote:
>>>On Fri, Mar 25, 2016 at 3:05 AM, Andres Freund
>>>wrote:
On 2015-11-12 19:59:54 +, Robert Haas wrote:
On Fri, Mar 25, 2016 at 4:51 PM, Thomas Munro
wrote:
> On Thu, Mar 24, 2016 at 12:34 AM, Thomas Munro
> wrote:
>> On Wed, Mar 23, 2016 at 12:37 PM, Robert Haas wrote:
>>> +static void WalRcvUnblockSigUsr2(void)
>>>
>>> And again here.
>>
>> Fixed.
>>
>>> +WalRcvUnblockSigUsr2();
Robert Haas writes:
> It's stupid that we keep spending time and energy figuring out which
> shared memory data structures require alignment and which ones don't.
> Let's just align them *all* and be done with it. The memory cost
> shouldn't be more than a few kB.
I think such a proposal should
On Fri, Mar 25, 2016 at 9:11 AM, Andres Freund wrote:
> On March 25, 2016 1:04:13 PM GMT+01:00, Robert Haas
> wrote:
>>On Fri, Mar 25, 2016 at 3:05 AM, Andres Freund
>>wrote:
>>> On 2015-11-12 19:59:54 +, Robert Haas wrote:
Move each SLRU's lwlocks to a separate tranche.
This
On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost wrote:
> Merlin,
>
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> No one is arguing that that you should send it any every time (at
>> least -- I hope not).
>
> I'm not sure I follow how you can avoid that though?
>
> pgbouncer in transaction pooli
On Fri, Mar 25, 2016 at 10:10 PM, David Steele wrote:
> Excellent, Robbie! I've run this patch through my test cases and
> everything works.
>
> Now that it's working I'll be writing up an actual review so expect that
> by Monday.
(I haven't given up on this patch yet, sorry for the low activity
On March 25, 2016 1:04:13 PM GMT+01:00, Robert Haas
wrote:
>On Fri, Mar 25, 2016 at 3:05 AM, Andres Freund
>wrote:
>> On 2015-11-12 19:59:54 +, Robert Haas wrote:
>>> Move each SLRU's lwlocks to a separate tranche.
>>>
>>> This makes it significantly easier to identify these lwlocks in
>>>
On 3/20/16 12:09 AM, Robbie Harwood wrote:
> Hello friends,
>
> A new version of my GSSAPI encryption patchset is available, both in
> this email and on my github:
> https://github.com/frozencemetery/postgres/tree/feature/gssencrypt8
Excellent, Robbie! I've run this patch through my test cases a
On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote:
> OK, sounds good. I don't have a spare machine on which to install VS2015,
> nor time to set one up, so I'm going to have to trust the two of you
> (Michael and Petr) that this works.
With Virtual Box, you could set up an environment for dev
On Fri, Mar 25, 2016 at 9:55 PM, Robert Haas wrote:
> On Fri, Mar 25, 2016 at 8:31 AM, Michael Paquier
> wrote:
> The relationship between doc/src/sgml/install-windows.sgml, the
> section of doc/src/sgml/installation.sgml entitled "MinGW/Native
> Windows", and src/tools/msvc/README is not altoget
> I think this is a waste of time. These functions are already very
> short; making them shorter will not significantly improve readability.
> It'll just force people who think they know what that code does to
> look at it again to see if it still does the same thing.
>
> Let's spend our time arg
On Fri, Mar 25, 2016 at 8:31 AM, Michael Paquier
wrote:
> On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote:
>> On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote:
>>> On 24/03/16 17:28, Robert Haas wrote:
On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier
wrote:
>
> - 0001 fi
On 24 March 2016 at 22:20, Stas Kelvich wrote:
>
> I think all the locking already handled properly by creating dummy backend
> in PGPROC, as it done in usual postgres 2pc implementation.
>
>
On the downstream, yes. But what about the decoding, reorder buffer and
output plugin? They access the r
On 24 March 2016 at 23:13, Vladimir Sitnikov
wrote:
>
> >doesn't have any kind of capabilities negotiation
>
> Do you think capability negotiation should indeed be at the protocol level?
> What's wrong with say "select * from backend_capabilities" at the
> connection setup?
>
(Kinda a side-track
On 03/25/2016 08:31 AM, Michael Paquier wrote:
On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote:
On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote:
On 24/03/16 17:28, Robert Haas wrote:
On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier
wrote:
- 0001 fixes the global declarations of TI
On Fri, Mar 25, 2016 at 9:17 PM, Robert Haas wrote:
> On Thu, Mar 24, 2016 at 9:50 AM, Aleksander Alekseev
> wrote:
>> Currently this procedure has two arguments --- init_size and max_size.
>> But since shared hash tables have fixed size there is little sense to
>> pass two arguments. In fact cur
> No, I think we left it that way on purpose. I don't remember the
> discussion exactly, but I don't think it's hurting anything.
This was a part of original dynahash optimization patch. Since that
patch was about performance improvement and this concrete change is
about refactoring, not performa
On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote:
> On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote:
>> On 24/03/16 17:28, Robert Haas wrote:
>>> On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier
>>> wrote:
- 0001 fixes the global declarations of TIMEZONE_GLOBAL and
TZNAME_GL
On Thu, Mar 24, 2016 at 9:29 AM, Masahiko Sawada wrote:
> Also I felt a sense of discomfort regarding using [ and ] as a special
> character for priority method.
> Because (, ) and [, ] are a little similar each other, so it would
> easily make many syntax errors when nested style is supported.
>
On Thu, Mar 24, 2016 at 9:50 AM, Aleksander Alekseev
wrote:
> I would like to continue discussion regarding changing calling
> convention for ShmemInitHash procedure:
>
> http://www.postgresql.org/message-id/CA+TgmoZm=uowt8a_xasfoogwufeelj861ntadiceopyfehv...@mail.gmail.com
>
> Currently this proc
On Thu, Mar 24, 2016 at 11:35 AM, Aleksander Alekseev
wrote:
> In the same time I'm deeply convinced that this patch will make code
> more readable at least because it makes code much shorter:
I think this is a waste of time. These functions are already very
short; making them shorter will not s
On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote:
> On 24/03/16 17:28, Robert Haas wrote:
>> On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier
>> wrote:
>>>
>>> - 0001 fixes the global declarations of TIMEZONE_GLOBAL and
>>> TZNAME_GLOBAL to be WIN32-compliant. I got bitten by that in the ECPG
On Fri, Mar 25, 2016 at 3:05 AM, Andres Freund wrote:
> On 2015-11-12 19:59:54 +, Robert Haas wrote:
>> Move each SLRU's lwlocks to a separate tranche.
>>
>> This makes it significantly easier to identify these lwlocks in
>> LWLOCK_STATS or Trace_lwlocks output. It's also arguably better
>> f
>Oops. I forgot to credit you in the commit message. Sorry about that.
:-(
No problem :). Thanks for the commit.
Thank you,
Rahila Syed
On 2016/03/25 13:37, Ashutosh Bapat wrote:
A much simpler solution, that will work with postgres_fdw, might be to
just deparse these columns with whatever random values (except for
tableoid) they are expected to have in those places. Often these values
can simply be NULL or 0. For tableoid depars
>
> It's conceivable that we could do something like adding an "isdead"
> column to pg_enum and making enum_in reject new values that're marked
> isdead. But I can't see that we'd ever be able to support true
> removal of an enum value at reasonable cost. And I'm not really sure
> where the use-c
On 2016-03-25 09:29:34 +0530, Amit Kapila wrote:
> > 2. Secondly, i can see that the BufferDesc structure padding is 64 bytes
> however the PG CACHE LINE ALIGNMENT is 128 bytes. Also, after changing the
> BufferDesc structure padding size to 128 bytes along with the changes
> mentioned in above poi
On 2015-11-12 19:59:54 +, Robert Haas wrote:
> Move each SLRU's lwlocks to a separate tranche.
>
> This makes it significantly easier to identify these lwlocks in
> LWLOCK_STATS or Trace_lwlocks output. It's also arguably better
> from a modularity standpoint, since lwlock.c no longer needs t
77 matches
Mail list logo
