On Fri, Aug 26, 2016 at 9:26 PM, Simon Riggs wrote:
>
> I think you should add this as part of the default testing for both
> check and installcheck. I can't imagine why we'd have it and not use
> it during testing.
>
The actual consistency checks are done during redo (replay), so not
sure whats
On 08/26/2016 07:04 PM, Heikki Linnakangas wrote:
On 08/26/2016 07:44 PM, Tom Lane wrote:
Peter Eisentraut writes:
On 8/26/16 5:31 AM, Heikki Linnakangas wrote:
I think now would be a good time to drop support for OpenSSL versions
older than 0.9.8. OpenSSL don't even support 0.9.8 anymore, al
2016-08-26 19:37 GMT-03:00 Tom Lane :
> =?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes:
>> Looking at this issue today, I found that we are not setting a
>> dependency for an index created inside an extension.
>
> Surely the index has a dependency on a table, which depends on the
> extension?
>
> If
On 08/26/2016 04:15 PM, Tomas Vondra wrote:
On 08/27/2016 12:37 AM, Tom Lane wrote:
=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes:
Looking at this issue today, I found that we are not setting a
dependency for an index created inside an extension.
Surely the index has a dependency on a table, w
Tomas Vondra writes:
> On 08/27/2016 12:37 AM, Tom Lane wrote:
>> If you mean that you want an extension to create an index on a table
>> that doesn't belong to it, but it's assuming pre-exists, I think
>> that's just stupid and we need not support it.
> I don't see why that would be stupid (and
On 08/27/2016 12:37 AM, Tom Lane wrote:
=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes:
Looking at this issue today, I found that we are not setting a
dependency for an index created inside an extension.
Surely the index has a dependency on a table, which depends on the
extension?
If you mean t
=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes:
> Looking at this issue today, I found that we are not setting a
> dependency for an index created inside an extension.
Surely the index has a dependency on a table, which depends on the
extension?
If you mean that you want an extension to create an i
Hi,
2016-08-26 10:53 GMT-03:00 Martín Marqués :
>
> There's still one issue, which I'll add a test for as well, which is
> that if the index was created by the extension, it will be dumped
> anyway. I'll have a look at that as well.
Looking at this issue today, I found that we are not setting a
d
On 8/26/16 12:26 PM, Euler Taveira wrote:
> initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb.
I have a concern specifically about pg_ctl. Depending on how your
PostgreSQL is packaged, not all of the pg_ctl actions are safe or
sensible to run. For example, if you are usin
On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote:
> I agree with all that. But the subject line is specifically about
> moving pg_xlog. So if your opinion is that we shouldn't move pg_xlog,
> then that is noted. But if we were to move it, we can think about a
> good place to move it to.
I t
On 8/26/16 5:20 PM, Andres Freund wrote:
> I do think there's an order of magnitude between the impact between
> moving some and moving everything. And that's going to impact
> cost/benefit calculations.
>
> Moving e.g. all ephemeral files into a (possibly configurable) directory
> is going to har
On 2016-08-26 17:11:00 -0400, Peter Eisentraut wrote:
> On 8/26/16 12:28 PM, Tom Lane wrote:
> > Also, I'd just as soon not move/rename things
> > that don't really need it.
>
> I'm just as happy with not changing anything. But if we're going to
> rename stuff, let's at least think about something
On 2016-08-26 13:26:39 -0300, Euler Taveira wrote:
> I'm bringing this $subject into discussion again. Historically, we are
> carrying binary names that have been confused newbies. createuser is the
> worst name so for. Also, names like createdb, initdb, reindexdb, and
> droplang does not suggest w
On 2016-08-26 18:46:42 +0300, Yury Zhuravlev wrote:
> Thanks all.
> Now understand LSN strongly connected with WAL.
> However how difficult put last system LSN instead 0?
> It's not so important but will allow make use LSN more consistent.
Maybe explain why you're interested in page lsns, that'd p
On 8/26/16 4:02 PM, Joshua D. Drake wrote:
> Although... wouldn't run be under var?
Traditionally yes, but things are changing in this area, if you consider
the top-level file system of a modern Linux distribution. One reason is
that "run" is/can be blown away at reboot. This wouldn't be an enti
On Fri, Aug 26, 2016 at 10:46 AM, Yury Zhuravlev
wrote:
> Now understand LSN strongly connected with WAL.
> However how difficult put last system LSN instead 0?
> It's not so important but will allow make use LSN more consistent.
There might be performance implications when flushing the index
bu
On 8/26/16 12:28 PM, Tom Lane wrote:
> Also, I'd just as soon not move/rename things
> that don't really need it.
I'm just as happy with not changing anything. But if we're going to
rename stuff, let's at least think about something slightly more
comprehensive. Any rename is going to break a bun
On 2016-08-26 11:53:21 -0400, Peter Eisentraut wrote:
> On 8/25/16 10:39 PM, Michael Paquier wrote:
> > I am relaunching $subject as 10 development will begin soon. As far as
> > I know, there is agreement that we can do something here. Among the
> > different proposals I have found:
> > - pg_clog
On 8/26/16 11:58 AM, Magnus Hagander wrote:
> $PGDATA/etc
>> $PGDATA/log
>> $PGDATA/run (lock files etc.)
>> $PGDATA/tmp
>> $PGDATA/var
>>
>> The names of all the things under "var" could still be refined, but it's
>> much less likely that users will confuse data with configuration or
>> plain logs
On Fri, Aug 26, 2016 at 04:33:47PM -0300, Euler Taveira wrote:
> On 26-08-2016 14:03, David Fetter wrote:
> > Would these make sense as pg_ctl options, or are you separating them
> > out because they're not instance-wide? If separating them is
> > important on those grounds, how about something li
On 08/26/2016 07:03 PM, David Fetter wrote:
On Fri, Aug 26, 2016 at 01:26:39PM -0300, Euler Taveira wrote:
Hi,
...
>>
initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb.
Opinions?
+1 for removing initdb.
We can't just remove it because pg_ctl actually calls initdb
Simon Riggs wrote:
> On 26 August 2016 at 18:26, Euler Taveira wrote:
>
> > I'm bringing this $subject into discussion again. Historically, we are
> > carrying binary names that have been confused newbies. createuser is the
> > worst name so for. Also, names like createdb, initdb, reindexdb, and
On 26 August 2016 at 18:28, Tom Lane wrote:
> Also, I'd just as soon not move/rename things that don't really need it.
+1
Let's leave everything exactly as it is now... but put a small README
in each directory to explain why files in it shouldn't be deleted to
make space.
That helps the few pe
On 2016-08-26 15:03, Andres Freund wrote:
On 2016-08-26 22:01:58 +0200, Simon Riggs wrote:
On 26 August 2016 at 18:26, Euler Taveira
wrote:
> I'm bringing this $subject into discussion again. Historically, we are
> carrying binary names that have been confused newbies. createuser is the
> wor
On 2016-08-26 22:01:58 +0200, Simon Riggs wrote:
> On 26 August 2016 at 18:26, Euler Taveira wrote:
>
> > I'm bringing this $subject into discussion again. Historically, we are
> > carrying binary names that have been confused newbies. createuser is the
> > worst name so for. Also, names like cre
On 08/26/2016 09:28 AM, Tom Lane wrote:
Magnus Hagander writes:
On Aug 26, 2016 5:54 PM, "Peter Eisentraut" <
peter.eisentr...@2ndquadrant.com> wrote:
If we're going to do some renaming, then I suggest we do a
mini-file-system structure under $PGDATA, like
$PGDATA/etc
$PGDATA/log
$PGDATA/run
On 26 August 2016 at 18:26, Euler Taveira wrote:
> I'm bringing this $subject into discussion again. Historically, we are
> carrying binary names that have been confused newbies. createuser is the
> worst name so for. Also, names like createdb, initdb, reindexdb, and
> droplang does not suggest w
On 26-08-2016 14:03, David Fetter wrote:
> Would these make sense as pg_ctl options, or are you separating them
> out because they're not instance-wide? If separating them is
> important on those grounds, how about something like pg_db or
> pg_db_command?
>
It doesn't make sense because pg_ctl is
I doubt the documentation for old_snapshot_threshold is going to be
understood by many ordinary users. What is a "snapshot", first of all?
Why would a snapshot be old? Why is that a problem? What can I do to
avoid it? What are the circumstances in practice where this issue would
arise, and what
Robert Haas writes:
> On Fri, Aug 26, 2016 at 11:26 AM, Tom Lane wrote:
>> I'm not quite sure what to do about this. It feels a tad wrong to use
>> ErrorContext as the active context during HandleParallelMessages, but
>> what else should we use? Maybe this needs its very own private context
>>
On Fri, Aug 26, 2016 at 11:26 AM, Tom Lane wrote:
> Or in short, this has confused edata and newedata. Valid coding would
> be
> oldcontext = MemoryContextSwitchTo(newedata->assoc_context);
> rather than what is there.
Oh, right.
>>> (Note that in the sole
>>> existing use-case, edata->
And here's a commitfest link:
https://commitfest.postgresql.org/10/743/
Also, a correction to my original message: the unreferenced [1] footnote
points back to the thread that included the patch for UUID SortSupport.
[1]
https://www.postgresql.org/message-id/CAM3SWZR4avsTwwNVUzRNbHk8v36W-QBqpoK
Hello,
I've attached a patch to add SortSupport for Postgres' macaddr which has the
effect of improving the performance of sorting operations for the type. The
strategy that I employ is very similar to that for UUID, which is to create
abbreviated keys by packing as many bytes from the MAC address
Alvaro Herrera writes:
> Tom Lane wrote:
>> Any objections? Anyone want to bikeshed the field name? I considered
>> PG_DIAG_SEVERITY_NONLOCALIZED and PG_DIAG_SEVERITY_ENGLISH before settling
>> on PG_DIAG_SEVERITY_ASCII, but I can't say I'm in love with that.
> I didn't review the patch, but +1
Heikki Linnakangas writes:
> Yeah, they want people to move to their own SSL library [1].
> [1] I couldn't find any official statement, but lots of blog posts
> saying the same thing.
As I recall, the deprecation warning messages said that in so many words.
That probably counts as an official s
Tom Lane wrote:
> So far as I can find, the attached is all we need to do to introduce a
> new message field. (This patch doesn't address the memory-context
> questions, but it does fix the localization-driven failure demonstrated
> upthread.)
>
> Any objections? Anyone want to bikeshed the fie
On 08/26/2016 07:44 PM, Tom Lane wrote:
Peter Eisentraut writes:
On 8/26/16 5:31 AM, Heikki Linnakangas wrote:
I think now would be a good time to drop support for OpenSSL versions
older than 0.9.8. OpenSSL don't even support 0.9.8 anymore, although
there are probably distributions out there t
On Fri, Aug 26, 2016 at 01:26:39PM -0300, Euler Taveira wrote:
> Hi,
>
> I'm bringing this $subject into discussion again. Historically, we are
> carrying binary names that have been confused newbies. createuser is the
> worst name so for. Also, names like createdb, initdb, reindexdb, and
> dropla
Peter Eisentraut writes:
> On 8/26/16 5:31 AM, Heikki Linnakangas wrote:
>> I think now would be a good time to drop support for OpenSSL versions
>> older than 0.9.8. OpenSSL don't even support 0.9.8 anymore, although
>> there are probably distributions out there that still provide patches
>> f
On 8/26/16 5:31 AM, Heikki Linnakangas wrote:
> I think now would be a good time to drop support for OpenSSL versions
> older than 0.9.8. OpenSSL don't even support 0.9.8 anymore, although
> there are probably distributions out there that still provide patches
> for it. But OpenSSL 0.9.7 and old
On Fri, Aug 26, 2016 at 3:13 PM, Ashutosh Bapat
wrote:
>
>
> On Fri, Aug 26, 2016 at 11:37 AM, Masahiko Sawada
> wrote:
>>
>> On Fri, Aug 26, 2016 at 3:03 PM, Ashutosh Bapat
>> wrote:
>> >
>> >
>> > On Fri, Aug 26, 2016 at 11:22 AM, Masahiko Sawada
>> >
>> > wrote:
>> >>
>> >> On Fri, Aug 26, 2
Magnus Hagander writes:
> On Aug 26, 2016 5:54 PM, "Peter Eisentraut" <
> peter.eisentr...@2ndquadrant.com> wrote:
>> If we're going to do some renaming, then I suggest we do a
>> mini-file-system structure under $PGDATA, like
>>
>> $PGDATA/etc
>> $PGDATA/log
>> $PGDATA/run (lock files etc.)
>> $
Hi,
I'm bringing this $subject into discussion again. Historically, we are
carrying binary names that have been confused newbies. createuser is the
worst name so for. Also, names like createdb, initdb, reindexdb, and
droplang does not suggest what product it is referring to. Adding a
prefix (pg_,
On 8/26/16 9:06 AM, Jürgen Purtz wrote:
> Actually we don't support the SQL feature F867 "FETCH FIRST clause: WITH
> TIES option". On the other side we support the window function "rank()"
> which acts like the "WITH TIES option". My questions are: Is it hard to
> implement the "WITH TIES option
On Aug 26, 2016 5:54 PM, "Peter Eisentraut" <
peter.eisentr...@2ndquadrant.com> wrote:
>
> On 8/25/16 10:39 PM, Michael Paquier wrote:
> > I am relaunching $subject as 10 development will begin soon. As far as
> > I know, there is agreement that we can do something here. Among the
> > different pro
I wrote:
> After sleeping on it, I think the right answer is to introduce the new
> error-message field (and not worry about 9.5). Will work on a patch
> for that, unless I hear objections pretty soon.
So far as I can find, the attached is all we need to do to introduce a
new message field. (Thi
Hi Kuntal,
Thanks for the patch.
Current patch has no docs, no tests and no explanatory comments, so
makes review quite hard.
The good news is you might discover a few bugs with it, so its worth
pursuing actively in this CF, though its not near to being
committable.
I think you should add this
On 8/25/16 10:39 PM, Michael Paquier wrote:
> I am relaunching $subject as 10 development will begin soon. As far as
> I know, there is agreement that we can do something here. Among the
> different proposals I have found:
> - pg_clog renamed to pg_commit_status, pg_xact or pg_commit
> - pg_xlog re
Amit Kapila wrote:
On Thu, Aug 25, 2016 at 7:55 PM, Yury Zhuravlev
wrote:
Hello hackers.
I have a small question. While working on an incremental
backup I noticed a
strange thing.
Newly created index is contains the invalid LSN (0/0).
Exmaple: ...
For some of the indexes like btree which a
Hello, Michael.
Your patch [1] was marked as "Needs review" so I decided to take a look.
It looks good to me. However I found dozens of places in PostgreSQL code
that seem to have similar problem you are trying to fix [2]. As far as I
understand these are only places left that don't check malloc/
Robert Haas writes:
> On Fri, Aug 26, 2016 at 10:35 AM, Tom Lane wrote:
>> BTW, while I'm looking at this: what on god's green earth is
>> ThrowErrorData doing copying the supplied data into edata->assoc_context?
>> Surely it should be putting the data into the ErrorContext, where it's not
>> goi
On Aug 26, 2016 5:13 PM, "Joshua D. Drake" wrote:
>
> On 08/25/2016 07:39 PM, Michael Paquier wrote:
>>
>> Hi all,
>>
>> I am relaunching $subject as 10 development will begin soon. As far as
>> I know, there is agreement that we can do something here. Among the
>> different proposals I have found
On 08/25/2016 07:39 PM, Michael Paquier wrote:
Hi all,
I am relaunching $subject as 10 development will begin soon. As far as
I know, there is agreement that we can do something here. Among the
different proposals I have found:
- pg_clog renamed to pg_commit_status, pg_xact or pg_commit
- pg_xlo
On 08/26/2016 03:48 AM, Magnus Hagander wrote:
Same reason I'm also +1 for Stephens suggestion to put all things that
should not be in a base backup into the same directory. That may break
things now, but it will simplify things down the road. And doing it at
the same time as renaming these thi
On Fri, Aug 26, 2016 at 10:35 AM, Tom Lane wrote:
> I wrote:
>> After sleeping on it, I think the right answer is to introduce the new
>> error-message field (and not worry about 9.5). Will work on a patch
>> for that, unless I hear objections pretty soon.
>
> BTW, while I'm looking at this: what
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Euler Taveira writes:
> > On 26-08-2016 09:25, Devrim Gündüz wrote:
> >> ...and we also have "pg_logical", that includes a "log" keyword already...
>
> > "clog" and "xlog" is almost "log"; "logical" is not. I don't imagine
> > people confusing "logical" me
Euler Taveira writes:
> On 26-08-2016 09:25, Devrim Gündüz wrote:
>> ...and we also have "pg_logical", that includes a "log" keyword already...
> "clog" and "xlog" is almost "log"; "logical" is not. I don't imagine
> people confusing "logical" meaning "log".
Well, I dunno; people with a weak g
On 26-08-2016 09:25, Devrim Gündüz wrote:
> On Fri, 2016-08-26 at 21:12 +0900, Michael Paquier wrote:
>> In short, with the current names, sometimes users think that pg_xlog
>> and pg_clog are just logs. And so it is fine to delete them to free up
>> space, corrupting their cluster, because they ar
I wrote:
> After sleeping on it, I think the right answer is to introduce the new
> error-message field (and not worry about 9.5). Will work on a patch
> for that, unless I hear objections pretty soon.
BTW, while I'm looking at this: what on god's green earth is
ThrowErrorData doing copying the s
On Tue, May 10, 2016 at 9:57 PM, Alexander Korotkov
wrote:
> Hi!
>
> On Mon, May 9, 2016 at 10:46 PM, Andres Freund wrote:
>>
>> trying to debug something I saw the following in pg_xlogdump output:
>>
>> rmgr: Gin len (rec/tot): 0/ 274, tx: 0, lsn:
>> 1C/DF28AEB0, prev 1C/
Hello Peter,
log_line_prefix = '%t [%p]: [%l] %qapp=%a '
which is modeled after the pgfouine recommendation, which is I believe a
wide-spread convention, and it also vaguely follows syslog customs.
The build farm client has
log_line_prefix = '%m [%c:%l] '
which is very similar, but the lack
Kuntal Ghosh wrote:
> Thanks a lot.
>
> I just want to mention the situation where I was getting the
> speculative token related inconsistency.
>
> ItemPointer in backup page from master:
> LOG: ItemPointer BlockNumber: 1 OffsetNumber:65534 Speculative: true
> CONTEXT: xlog redo at 0/127F4A48 f
Hi,
2016-08-25 8:10 GMT-03:00 Michael Paquier :
> On Thu, Aug 25, 2016 at 10:25 AM, Martín Marqués
> wrote:
>> 2016-08-24 21:34 GMT-03:00 Michael Paquier :
>>>
>>> Yes, you are right. If I look at the diffs this morning I am seeing
>>> the ACLs being dumped for this aggregate. So we could just f
On 04/05/2016 11:15 AM, Etsuro Fujita wrote:
On 2016/03/16 16:25, Etsuro Fujita wrote:
PG9.5 allows us to add an oid system column to foreign tables, using
ALTER FOREIGN TABLE SET WITH OIDS, but currently, that column reads as
zeroes in postgres_fdw. That seems to me like a bug. So, I'd like t
Pavel Stehule writes:
> Using footer for this purpose is little bit strange. What about following
> design?
> 1. move out source code of PL functions from \df+
> 2. allow not unique filter in \sf and allow to display multiple functions
Wasn't that proposed and rejected upthread?
Hello, Heikki.
Thank you for your attention to this patch!
> This also seems to change the API so that instead of a single
> rb_begin_iterate()+rb_iterate() pair, there is a separate begin and
> iterate function for each traversal order. That seems like an unrelated
> change. Was there a parti
Actually we don't support the SQL feature F867 "FETCH FIRST clause: WITH
TIES option". On the other side we support the window function "rank()"
which acts like the "WITH TIES option". My questions are: Is it hard to
implement the "WITH TIES option"? Are there plans for a realization /
how do w
On Wed, Mar 23, 2016 at 7:04 PM, Pavan Deolasee
wrote:
>
>
> On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier
> wrote:
>>
>>
>> + /*
>> +* Compute targetRecOff. It should typically be greater than short
>> +* page-header since a valid record can't , but can also be zero
>> w
* Venkata B Nagothi (nag1...@gmail.com) wrote:
> On Fri, Aug 26, 2016 at 12:30 PM, Stephen Frost wrote:
> > * Venkata B Nagothi (nag1...@gmail.com) wrote:
> > > This behaviour will be similar to that of recovery_target="immediate" and
> > > can be aliased.
> >
> > I don't believe we're really goin
Latest from lorikeet:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2016-08-26%2008%3A37%3A27
TRAP: FailedAssertion("!(vmq->mq_sender == ((void *)0))", File:
"/home/andrew/bf64/root/REL9_6_STABLE/pgsql.build/../pgsql/src/backend/storage/ipc/shm_mq.c",
Line: 220)
Thoughts?
On Thu, Aug 25, 2016 at 4:51 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> On Thu, Aug 25, 2016 at 2:56 PM, Alvaro Herrera
>> wrote:
>>
>> > I'm wondering about the TestForOldSnapshot call in scanPendingInsert().
>> > Why do we apply it to the metapage buffer (line 1717 in master)?
>>
>> I
Hi,
On Fri, 2016-08-26 at 21:12 +0900, Michael Paquier wrote:
> In short, with the current names, sometimes users think that pg_xlog
> and pg_clog are just logs. And so it is fine to delete them to free up
> space, corrupting their cluster, because they are just *logs*.
...and we also have "pg_l
On Fri, Aug 26, 2016 at 8:31 PM, Simon Riggs wrote:
> On 26 August 2016 at 04:39, Michael Paquier wrote:
>> Hi all,
>>
>> I am relaunching $subject as 10 development will begin soon. As far as
>> I know, there is agreement that we can do something here. Among the
>> different proposals I have fou
Robert Haas writes:
> I don't have strong feelings about this. Technically, this issue
> affects 9.5 also, because pqmq.c was introduced in that release. I
> don't think we want to add another error field in a released branch.
> However, since there's no parallel query in 9.5, only people who ar
On 08/22/2016 01:00 PM, Aleksander Alekseev wrote:
It seems clear to me that the existing arrangement is hazardous for
any RBTree that hasn't got exactly one consumer. I think
Aleksander's plan to decouple the iteration state is probably a good
one (NB: I've not read the patch, so this is not an
On Thu, Aug 25, 2016 at 6:54 PM, Alvaro Herrera
wrote:
> Amit Kapila wrote:
>> On Wed, Aug 24, 2016 at 11:46 PM, Alvaro Herrera
>> wrote:
>
>> > Can you split the new xlog-related stuff to a new file, say hash_xlog.h,
>> > instead of cramming it in hash.h? Removing the existing #include
>> > "xl
On 26 August 2016 at 04:39, Michael Paquier wrote:
> Hi all,
>
> I am relaunching $subject as 10 development will begin soon. As far as
> I know, there is agreement that we can do something here. Among the
> different proposals I have found:
> - pg_clog renamed to pg_commit_status, pg_xact or pg_c
On Fri, Aug 26, 2016 at 12:44 PM, Christoph Berg wrote:
> Re: Fujii Masao 2016-08-26 cmzgv5u6oemxr-cbjro+w...@mail.gmail.com>
> > > I agree on a hard break, unless we get pushback from users, and even
> > > then, they can create the symlinks themselves.
> >
> > I strongly prefer symlink approach
Re: Fujii Masao 2016-08-26
> > I agree on a hard break, unless we get pushback from users, and even
> > then, they can create the symlinks themselves.
>
> I strongly prefer symlink approach not to break many existing tools
> and scripts.
Symlinks might actually be worse than removing the direct
On 07/13/2016 04:25 PM, Michael Paquier wrote:
On Wed, Jul 13, 2016 at 8:27 PM, Amit Kapila wrote:
On Wed, Jul 13, 2016 at 9:19 AM, Michael Paquier
wrote:
Hence why not simplifying its interface and remove the force flag?
One point to note is that the signature and usage of
UpdateMinRecover
On 07/05/2016 04:46 PM, Andreas Karlsson wrote:
@@ -280,8 +287,9 @@ px_find_digest(const char *name, PX_MD **res)
digest = px_alloc(sizeof(*digest));
digest->algo = md;
- EVP_MD_CTX_init(&digest->ctx);
- if (EVP_DigestInit_ex(&digest->ctx, digest->algo, NULL) == 0)
+
On Wed, Aug 17, 2016 at 6:10 PM, Robert Haas wrote:
>> If you are making changes in plpgsql_validator(), then shouldn't we
>> make changes in plperl_validator() or plpython_validator()? I see
>> that you have made changes to function CheckFunctionValidatorAccess()
>> which seems to be getting cal
On Wed, 24 Aug 2016 21:31:35 -0400
Robert Haas wrote:
> Hi,
>
> I'd like to propose that we increase the default WAL segment size,
> which is currently 16MB. It was first set to that value in commit
> 47937403676d913c0e740eec6b85113865c6c8ab in October of 1999; prior to
> that, it was 64MB. Be
On 2016/08/18 5:23, Robert Haas wrote:
> On Wed, Aug 17, 2016 at 2:21 AM, Amit Langote
> wrote:
>> I am slightly tempted to eliminate the pg_partition catalog and associated
>> syscache altogether and add a column to pg_class as Robert suggested.
>> That way, all relid_is_partition() calls will be
On Fri, Aug 26, 2016 at 12:30 PM, Stephen Frost wrote:
> * Venkata B Nagothi (nag1...@gmail.com) wrote:
> > On Thu, Aug 25, 2016 at 10:59 PM, Stephen Frost
> wrote:
> > > I'm not a fan of the "recovery_target" option, particularly as it's
> only
> > > got one value even though it can mean two th
85 matches
Mail list logo
