On 2017-03-18 06:37, Erik Rijkers wrote:
Studying logrep yielded some more improvements to the comments in
snapbuild.c
(to be applied to master)
Attached the actual file
thanks,
Erik Rijekrs
--- src/backend/replication/logical/snapbuild.c.orig 2017-03-18 05:02:28.627077888 +0100
+++ src/b
Studying logrep yielded some more improvements to the comments in
snapbuild.c
(to be applied to master)
thanks,
Erik Rijekrs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Mar 14, 2017 at 8:03 AM, Thomas Munro
wrote:
> On Mon, Mar 13, 2017 at 8:40 PM, Rafia Sabih
> wrote:
>> In an attempt to test v7 of this patch on TPC-H 20 scale factor I found a
>> few regressions,
>> Q21: 52 secs on HEAD and 400 secs with this patch
>
> Thanks Rafia. Robert just pointe
On Fri, Mar 17, 2017 at 9:15 AM, Ashutosh Bapat
wrote:
> This set of patches fixes both of those things.
0001 changes the purpose of a function and then 0007 renames it. It
would be better to include the renaming in 0001 so that you're not
taking multiple whacks at the same function in the same
On Fri, Mar 17, 2017 at 6:11 PM, Peter Eisentraut
wrote:
> On 3/17/17 16:56, Tom Lane wrote:
>> Tools could get the segment size out of
>> XLogLongPageHeaderData.xlp_seg_size in the first page of the segment.
>
> OK, then pg_standby would have to wait until the file is at least
> XLOG_BLCKSZ, then
On Sat, Mar 18, 2017 at 11:49 AM, Thomas Munro
wrote:
> On Sat, Mar 18, 2017 at 6:14 AM, Tom Lane wrote:
>> After a bit more thought, it seems like the bug here is that "the
>> fraction of the LHS that has a non-matching row" is not one minus
>> "the fraction of the LHS that has a matching row".
On Sat, Mar 18, 2017 at 6:14 AM, Tom Lane wrote:
> After a bit more thought, it seems like the bug here is that "the
> fraction of the LHS that has a non-matching row" is not one minus
> "the fraction of the LHS that has a matching row". In fact, in
> this example, *all* LHS rows have both matchi
Hi,
It looks we're creeping towards agreement in
http://archives.postgresql.org/message-id/20161206034955.bh33paeralxbtluv%40alap3.anarazel.de
It'd be fairly easy to add a hook in its ExecInstantiateExpr(), which'd
allow extensions to provide newer (presumably faster) ways to evaluate
expressions
Hi,
On 03/17/2017 05:23 PM, Peter Eisentraut wrote:
I'm struggling to find a good way to share code between
bt_page_items(text, int4) and bt_page_items(bytea).
If we do it via the SQL route, as I had suggested, it makes the
extension non-relocatable, and it will also create a bit of a mess
duri
On Wed, Mar 15, 2017 at 07:26:45PM -0700, Andres Freund wrote:
> On 2017-03-15 16:31:11 -0400, Robert Haas wrote:
> > On Wed, Mar 15, 2017 at 3:54 PM, Ashutosh Sharma
> > wrote:
> > > Changed as per suggestions. Attached v9 patch. Thanks.
> >
> > Wow, when do you sleep?
>
> I think that applies
On Fri, Mar 17, 2017 at 10:12 AM, Amit Khandekar wrote:
> Yeah, I was in double minds as to whether to do the
> copy-to-array-and-qsort thing, or should just write the same number of
> lines of code to manually do an insertion sort. Actually I was
> searching if we already have a linked list sort,
On 3/17/17 16:56, Tom Lane wrote:
> Tools could get the segment size out of
> XLogLongPageHeaderData.xlp_seg_size in the first page of the segment.
OK, then pg_standby would have to wait until the file is at least
XLOG_BLCKSZ, then look inside and get the expected final size. A bit
more complicat
By the way, it would be very good if you could review some patches, too.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 3/13/17 11:35, Aleksander Alekseev wrote:
> Here is a new patch. I tried to make as little changes as possible. This
> is no doubt not the most beautiful patch on Earth but it removes all
> warnings. I anyone could suggest an approach that would be significantly
> better please don't hesitate to
On Fri, Mar 17, 2017 at 5:50 PM, Michael Meskes wrote:
>> Thank you for pointing out.
>> Yeah, I agree that the twophase regression test should not be
>> performed by default as long as the default value of
>> max_prepared_transactions is 0. Similar to this, the isolation check
>> regression test
On Friday 10 March 2017 07:59 PM, Alexander Korotkov wrote:
Hi, Pritam! > > I've assigned to review this patch. > > On Thu, Feb 23, 2017 at 2:17 AM, Pritam Baral wrote: > > The topic has been previously discussed[0] on the -performance mailing list, > about four years ago. > > In tha
On Sunday 12 March 2017 01:58 AM, Jim Nasby wrote:
On 3/10/17 8:29 AM, Alexander Korotkov wrote: >> That's cool idea. But I would say more. Sometimes it's useful to >> transform "intcol between x and y" into
"intcol <@ 'x,y'::int4range". >> btree_gin supports "intcol between x and y" as over
I wrote:
> * You're not bothering to insert any inputcollid into the generated
> comparison operator nodes. I'm not sure why that fails to fall over
> for text comparisons (if indeed it does fail ...) but it's wrong.
> Use the range type's collation there.
Oh ... looking at this again, I realize
Peter Eisentraut writes:
> On 3/17/17 16:20, Peter Eisentraut wrote:
>> I think we would have to extend restore_command with an additional
>> placeholder that communicates the segment size, and add a new pg_standby
>> option to accept that size somehow. And specifying the size would have
>> to be
On 3/17/17 16:20, Peter Eisentraut wrote:
> On 3/16/17 21:10, Robert Haas wrote:
>> The changes to pg_standby seem to completely break the logic to wait
>> until the file has attained the correct size. I don't know how to
>> salvage that logic off-hand, but just breaking it isn't acceptable.
>
>
2017-03-16 22:01 GMT+01:00 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > 2017-03-15 17:21 GMT+01:00 Stephen Frost :
> > > I started looking through this to see if it might be ready to commit
> and
> > > I don't believe it is. Below are my comments about the fir
Kevin Grittner writes:
> Why do we warn of a hazard here instead of eliminating said hazard
> with a static inline function declaration in executor.h?
> /*
> * ExecEvalExpr was formerly a function containing a switch statement;
> * now it's just a macro invoking the function pointed to by an Ex
On Fri, Mar 17, 2017 at 3:23 PM, Andres Freund wrote:
> On 2017-03-17 15:17:33 -0500, Kevin Grittner wrote:
>> Why do we warn of a hazard here instead of eliminating said hazard
>> with a static inline function declaration in executor.h?
>
> Presumably because it was written long before we started
Hi Kevin,
On 2017-03-17 15:17:33 -0500, Kevin Grittner wrote:
> Why do we warn of a hazard here instead of eliminating said hazard
> with a static inline function declaration in executor.h?
Presumably because it was written long before we started relying on
inline functions :/
> /*
> * ExecEv
On 3/16/17 21:10, Robert Haas wrote:
> The changes to pg_standby seem to completely break the logic to wait
> until the file has attained the correct size. I don't know how to
> salvage that logic off-hand, but just breaking it isn't acceptable.
I think we would have to extend restore_command wit
Why do we warn of a hazard here instead of eliminating said hazard
with a static inline function declaration in executor.h?
/*
* ExecEvalExpr was formerly a function containing a switch statement;
* now it's just a macro invoking the function pointed to by an ExprState
* node. Beware of double
Ashutosh Sharma writes:
> Basically, when we started working on WAL for hash index, we found
> that WAL routine 'XLogReadBufferExtended' does not expect a page to be
> completely zero page else it returns Invalid Buffer. To fix this, we
> started initializing freed overflow page or new bucket page
On 3/17/17 13:24, Jeff Janes wrote:
> And isn't it unhelpful to have the pageinspect module throw errors,
> rather than returning a dummy value to indicate there was an error?
Even if one agreed with that premise, it would be hard to satisfy
reliably, because the user-facing pageinspect functions
Robert Haas writes:
> On Fri, Mar 17, 2017 at 1:14 PM, Tom Lane wrote:
>> It would not be too hard to convince me that neqjoinsel should
>> simply return 1.0 for any semijoin/antijoin case, perhaps with
>> some kind of discount for nullfrac. Whether or not there's an
>> equal row, there's almost
I wrote:
> Petr Jelinek writes:
>> Thanks, now that I look at it again I think we might need to do cycle
>> with the occurred_events and returned_events and not return on first
>> find since theoretically there can be multiple sockets if this gets
>> called directly and not via WaitLatchOrSocket()
Andrew Dunstan writes:
> On 03/17/2017 12:28 PM, Tom Lane wrote:
>> I'll add some comments and push this. Does everyone agree that
>> this had better get back-patched, too?
> Confirmed that this fixes the problem on jacana.
> +1 for backpatching.
I've pushed this into 9.6, but the WaitEventSet
On 03/17/2017 12:28 PM, Tom Lane wrote:
> Petr Jelinek writes:
>> Now the documentation for WSAEventSelect says "The FD_WRITE network
>> event is handled slightly differently. An FD_WRITE network event is
>> recorded when a socket is first connected with a call to the connect,
>> ConnectEx, WSAC
On 3/17/17 13:39, Alvaro Herrera wrote:
> Oh yeah, buildfarm member sitella shows that. Does the attached patch
> fix it? (pretty much the same thing Michael attached, but we also need
> to handle typeoids)
Yes, that makes the warning go away.
--
Peter Eisentraut http://www.2ndQuad
On Fri, Mar 17, 2017 at 10:54 PM, Jeff Janes wrote:
> While trying to figure out some bloating in the newly logged hash indexes,
> I'm looking into the type of each page in the index. But I get an error:
>
> psql -p 9876 -c "select hash_page_type(get_raw_page('foo_index_idx',x)) from
> generate_s
With some intensive crash-recovery testing, I've run into a situation where
I get some bad table bloat. There will be large swaths of the table which
are empty (all results from heap_page_items other than lp are either zero
or NULL), but have zero available space in the fsm, and are marked as
all-
On Fri, Mar 17, 2017 at 1:14 PM, Tom Lane wrote:
> After a bit more thought, it seems like the bug here is that "the
> fraction of the LHS that has a non-matching row" is not one minus
> "the fraction of the LHS that has a matching row". In fact, in
> this example, *all* LHS rows have both matchi
>
>
> > \set x 'arg1 arg2'
>
> > \if false
> > \cmd_that_takes_exactly_two_args :x
> > \endif
>
> Yeah, throwing errors for bad arguments would also need to be suppressed.
>
> regards, tom lane
>
Ok, barring other feedback, I'm going to take my marching orders as "make
On Fri, Mar 17, 2017 at 1:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> While reviewing Ashutosh Bapat's partitionwise join code, I noticed
>> he'd run up against the problem that adjust_relid_set() is defined as
>> static in two different source files, and he wanted to call it from a
>> third
Heikki Linnakangas writes:
> Fix and simplify check for whether we're running as Windows service.
This seems to have broken narwhal:
Creating library file: libpostgres.a
../../src/port/libpgport_srv.a(win32security_srv.o)(.text+0x109): In function
`pgwin32_is_admin':
C:/msys/1.0/local/pgbuildfa
Hi,
Currently, clients wishing to know when the server exits hot standby
have to resort to polling, which is often suboptimal.
This adds the new "in_hot_standby" GUC variable that is reported via a
ParameterStatus message. This allows the clients to:
(a) know right away that they are connect
Robert Haas writes:
> While reviewing Ashutosh Bapat's partitionwise join code, I noticed
> he'd run up against the problem that adjust_relid_set() is defined as
> static in two different source files, and he wanted to call it from a
> third file. I didn't much like his solution to that problem,
Peter Eisentraut wrote:
> cc -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
> -Wformat-security -fno-strict-aliasing -fwrapv
> -fexcess-precision=standard -g -O2 -I../../../src/include
> -D_FORTIFY_SOURCE=2 -DLINUX_OOM_ADJ -D_GN
While reviewing Ashutosh Bapat's partitionwise join code, I noticed
he'd run up against the problem that adjust_relid_set() is defined as
static in two different source files, and he wanted to call it from a
third file. I didn't much like his solution to that problem, which
was to rename one of th
Corey Huinker writes:
>> In the end, I suspect that teaching all the backslash commands to do
>> nothing after absorbing their arguments is likely to be the least messy
>> way to tackle this, even if it makes for a rather bulky patch.
> Perhaps, but just glancing at \connect makes me think that f
While trying to figure out some bloating in the newly logged hash indexes,
I'm looking into the type of each page in the index. But I get an error:
psql -p 9876 -c "select hash_page_type(get_raw_page('foo_index_idx',x))
from generate_series(1650,1650) f(x)"
ERROR: page is not a hash page
DETAIL
Petr Jelinek writes:
> On 17/03/17 17:28, Tom Lane wrote:
>> Yeah, I'm afraid we had better do something more or less like this.
>> It's interesting to speculate about whether WaitEventSet could keep
>> additional state that would avoid the need for a dummy send() every
>> time, but that seems lik
I gave this patch a quick skim. At first I was confused by the term
"catalog"; I thought it meant we stored options in a system table. But
that's not what is meant at all; instead, what we do is build these
"catalogs" in memory. Maybe a different term could have been used, but
I'm not sure it's
Andres Freund writes:
> That said, it seems this is something that has to wait for a later
> release, I'm putting back in similar logic as there was before (not a
> branch, but change the opcode to a non-checking variant).
Yeah, I was wondering if changing the opcode would be preferable to
a firs
On 16 March 2017 at 18:18, Ashutosh Bapat
wrote:
> + * Check if we are already finished plans from parallel append. This
> + * can happen if all the subplans are finished when this worker
> + * has not even started returning tuples.
> + */
> +if (node->as_pa
On 17 March 2017 at 01:37, Robert Haas wrote:
> - You've added a GUC (which is good) but not documented it (which is
> bad) or added it to postgresql.conf.sample (also bad).
>
> - You've used a loop inside a spinlock-protected critical section,
> which is against project policy. Use an LWLock; de
I wrote:
> The problem here appears to be that we don't have any MCV list for
> the "twothousand" column (because it has a perfectly flat distribution),
> and the heuristic that eqjoinsel_semi is using for the no-MCVs case
> is falling down badly.
Oh ... wait. eqjoinsel_semi's charter is to "esti
Hi,
Am Freitag, den 17.03.2017, 20:46 +0900 schrieb Michael Paquier:
> On Fri, Mar 17, 2017 at 7:18 PM, Michael Banck
> wrote:
> > Am Freitag, den 17.03.2017, 10:50 +0900 schrieb Michael Paquier:
> >> The comment block format is incorrect. I would think as well that this
> >> comment should say i
Robert Haas writes:
> The relevant code is in neqsel(). It estimates the fraction of rows
> that will be equal, and then does 1 - that number. Evidently, the
> query planner thinks that l1.l_suppkey = l2.l_suppkey would almost
> always be true, and therefore l1.l_suppkey <> l2.l_suppkey will alm
>
>
> In the end, I suspect that teaching all the backslash commands to do
> nothing after absorbing their arguments is likely to be the least messy
> way to tackle this, even if it makes for a rather bulky patch.
>
>
Perhaps, but just glancing at \connect makes me think that for some
commands (pre
Hello Tom,
I also fear that there are corner cases where the behavior would still
be inconsistent. Consider
\if ...
\set foo `echo \endif should not appear here`
In this instance, ISTM that there is no problem. On "\if true", set is
executed, all is well. On "\if false", the whole line wou
On 17/03/17 17:28, Tom Lane wrote:
> Petr Jelinek writes:
>> Now the documentation for WSAEventSelect says "The FD_WRITE network
>> event is handled slightly differently. An FD_WRITE network event is
>> recorded when a socket is first connected with a call to the connect,
>> ConnectEx, WSAConnect,
Corey Huinker writes:
> I think Fabien was arguing that inside a false block there would be no
> syntax rules beyond "is the first non-space character on this line a '\'
> and if so is it followed with a if/elif/else/endif?". If the answer is no,
> skip the line. To me that seems somewhat similar
Hi,
On 2017-03-17 11:36:30 -0400, Tom Lane wrote:
> Having said all that, I think that 0001 is contributing very little to the
> goals of this patch set. Andres stated that he wanted it so as to drop
> some of the one-time checks that execQual.c currently does for Vars, but
> I'm not really convi
Petr Jelinek writes:
> Now the documentation for WSAEventSelect says "The FD_WRITE network
> event is handled slightly differently. An FD_WRITE network event is
> recorded when a socket is first connected with a call to the connect,
> ConnectEx, WSAConnect, WSAConnectByList, or WSAConnectByName fu
On 3/17/17 11:06, Alvaro Herrera wrote:
> I don't get anything with my compiler (gcc (Debian 4.9.2-10) 4.9.2) and
> I don't see anything in the few logs I looked at (clang, 9.6) from
> buildfarm either. What are you seeing specifically?
cc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-
I'm struggling to find a good way to share code between
bt_page_items(text, int4) and bt_page_items(bytea).
If we do it via the SQL route, as I had suggested, it makes the
extension non-relocatable, and it will also create a bit of a mess
during upgrades.
If doing it in C, it will be a bit tricky
Hi John,
Thanks for your response. From my experience as a Software Developer, I
don't think QGIS can logon to my database/schema/table with a dedicated
user as they need authentication to do so. What you described about using a
dedicated user in applications is only possible because that user was
On Fri, Mar 17, 2017 at 1:54 AM, Thomas Munro
wrote:
> SELECT *
>FROM lineitem l1
> WHERE EXISTS (SELECT *
> FROM lineitem l2
> WHERE l1.l_orderkey = l2.l_orderkey);
>
> -> estimates 59986012 rows, actual rows 59,986,052 (scale 10 TPCH)
>
> SELECT *
>
Hi all,
2017-03-17 17:09 GMT+01:00 John Scalia :
> While I do not know QGIS, I'm wondering if it's similar to some of our
> applications where they always use the same system login for the database
> while each user provides a unique login to the application. Have you ever
> set log_connections i
While I do not know QGIS, I'm wondering if it's similar to some of our
applications where they always use the same system login for the database
while each user provides a unique login to the application. Have you ever
set log_connections in your postgresql.conf file? That would show you which
user
On Fri, Mar 17, 2017 at 11:42 AM, Tom Lane wrote:
> Fabien COELHO writes:
> >> I also fear that there are corner cases where the behavior would still
> >> be inconsistent. Consider
> >>
> >> \if ...
> >> \set foo `echo \endif should not appear here`
>
> > In this instance, ISTM that there is no
On Thu, Mar 16, 2017 at 10:34 PM, Craig Ringer wrote:
> On 17 March 2017 at 08:10, Stas Kelvich wrote:
>> While working on this i’ve spotted quite a nasty corner case with aborted
>> prepared
>> transaction. I have some not that great ideas how to fix it, but maybe i
>> blurred my
>> view and m
>
>
> I am sending the review of this patch
I found the following
v Use tage in documentation
v Don’t modified existing test case add new one instead
v Comment in pg_constraint.c is extended make it short
v Error message can be more guider if it tells about general rule
v Wrong result i
On 17/03/17 16:07, Tom Lane wrote:
> Andrew Dunstan writes:
>> I have confirmed on jacana Petr's observation that adding a timeout to
>> the WaitLatchOrSocket cures the problem.
>
> Does anyone have a theory as to why that cures the problem?
>
I now have theory and even PoC patch for it.
The l
Hi Giuseppe,
Thanks for the response. I have provided the GRANTS and other PostgreSQL
setup scripts below as it includes what you have suggested:
ROLE
-
CREATE ROLE WITH NOLOGIN NOSUPERUSER INHERIT NOCREATEDB
NOCREATEROLE NOREPLICATION;
USER
--
CREATE USER WITH PASSWORD ''
REV
Fabien COELHO writes:
>> I also fear that there are corner cases where the behavior would still
>> be inconsistent. Consider
>>
>> \if ...
>> \set foo `echo \endif should not appear here`
> In this instance, ISTM that there is no problem. On "\if true", set is
> executed, all is well. On "\if
>
>
> command.c:38:25: fatal error: conditional.h: No such file or directory
> #include "conditional.h"
>
Odd, it's listed as a new file in git status. Anyway, my point of posting
the WIP patch was to give people a reference point and spark discussion
about the next step, and it succeeded at that
Andres Freund writes:
> [ latest patches ]
I looked through 0001 (the composite-type-dependencies one). Although
I agree that it'd be good to tighten things up in that area, I do not
think we want this specific patch: it tightens things too much. Consider
this variant of the existing test case
Hello Tom,
ISTM that I've tried to suggest to work around that complexity by:
- document that \if-related commands should only occur at line start
(and extend to eol).
- detect and complain when this is not the case.
I think this is a lousy definition, and would never be considered if
A handful of rather surprising errors showed up in our log extract this
morning, along the lines of:
2017-03-17 05:01:55 CDT [5400]: [1-1] @ FATAL: 57P01: terminating
connection due to administrator command
After a moment of more than a little astonishment, a look at the full log
revealed
Hi Osahon,
2017-03-17 15:54 GMT+01:00 Osahon Oduware :
> Hi All,
>
> I created a "Read-only" User in PostgreSQL via a Role with "SELECT" ONLY
> privilege on all tables in a schema as shown below:
>
> GRANT SELECT ON ALL TABLES IN SCHEMA [schema_name] TO [role_name]
> GRANT [role_name] TO [user_na
Andrew Dunstan writes:
> I have confirmed on jacana Petr's observation that adding a timeout to
> the WaitLatchOrSocket cures the problem.
Does anyone have a theory as to why that cures the problem?
What length of timeout is being suggested here? Would a long timeout
perhaps create a performanc
Peter Eisentraut wrote:
> On 3/16/17 11:56, Alvaro Herrera wrote:
> > Michael Paquier wrote:
> >
> >> What are you using as CFLAGS? As both typenames should be normally
> >> set, what about initializing those fields with NULL and add an
> >> assertion like the attached?
> >
> > Actually, my compi
On Fri, Mar 17, 2017 at 6:13 PM, Amit Kapila wrote:
> On Fri, Mar 17, 2017 at 12:27 PM, Ashutosh Sharma
> wrote:
>> On Fri, Mar 17, 2017 at 8:20 AM, Amit Kapila wrote:
>>
>> As I said in my previous e-mail, I think you need
>>> to record clearing of this flag in WAL record XLOG_HASH_DELETE as y
I have committed the page_checksum function, will work on the bt stuff next.
I left in the superuser check, because I was not confident how well
pg_checksum_page() would handle messed up data.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remo
Hi All,
I created a "Read-only" User in PostgreSQL via a Role with "SELECT" ONLY
privilege on all tables in a schema as shown below:
GRANT SELECT ON ALL TABLES IN SCHEMA [schema_name] TO [role_name]
GRANT [role_name] TO [user_name]
Next, I test this by trying to UPDATE a column in a table (same
On 03/08/2017 08:29 PM, Andrew Dunstan wrote:
>
> On 03/08/2017 08:33 AM, Peter Eisentraut wrote:
>> On 3/6/17 09:38, Peter Eisentraut wrote:
>>> On 3/4/17 01:45, Petr Jelinek wrote:
If that's the case, the attached should fix it, but I have no way of
testing it on windows, I can only s
> Thank you for pointing out.
> Yeah, I agree that the twophase regression test should not be
> performed by default as long as the default value of
> max_prepared_transactions is 0. Similar to this, the isolation check
> regression test does same thing. Attached patch removes sql/twophase
> from s
Fabien COELHO writes:
> ISTM that I've tried to suggest to work around that complexity by:
> - document that \if-related commands should only occur at line start
> (and extend to eol).
> - detect and complain when this is not the case.
I think this is a lousy definition, and would never b
On 3/17/17 4:18 AM, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,
>> Takayuki
>> I made this ready for committer. The patch applied except for catversion.h,
>> the patch content looks good, and the targe
Thanks Robert for the review.
On Thu, Mar 16, 2017 at 8:05 PM, Robert Haas wrote:
> On Thu, Mar 16, 2017 at 8:28 AM, Rahila Syed
> wrote:
> > Thank you for the updated patch.
> >
> > I have applied and tested it on latest sources and the patch looks good
> to
> > me.
>
> The documentation puts
On Thu, Mar 16, 2017 at 10:21 PM, Michael Paquier
wrote:
> On Fri, Mar 17, 2017 at 11:17 AM, Robert Haas wrote:
>> I understand that the point of renaming pg_clog to pg_xact is that
>> pg_clog contains the dreaded letters l-o-g, which we hypothesize
>> causes DBAs to remove it. (Alternate hypoth
On Fri, Mar 17, 2017 at 10:58 PM, Robert Haas wrote:
> Fine! I've committed the pg_clog renaming, but I'd really like to
> draw the line here. I'm not going to commit the pg_subtrans ->
> pg_subxact naming and am -1 on anyone else doing so. I think that
> having the names of things in the code
I've found various sources that give hints about what a student
proposal should look like, but nothing I could just give as a link,
so I pulled together what I could find, tempered by my own ideas and
opinions. I suggest that we send the below, or something like it to
each student who expresses in
On 3/15/17 3:00 AM, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
>>> But it might be worth thinking about whether we want to encourage
>>> people to do manual chmod's at all; that's fairly easy to get
On 3/15/17 1:56 AM, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
>> Sure, but having the private key may allow them to get new data from the
>> server as well as the data from the backup.
>
> You are
Robert Haas writes:
> On Fri, Mar 17, 2017 at 8:32 AM, Heikki Linnakangas wrote:
>> It would make sense to have \password obey password_encryption GUC. Then
>> \password and ALTER USER would do the same thing, which would be less
>> surprising. Although it's also a bit weird for a GUC to affect c
On 3/13/17 11:15 AM, David Steele wrote:
> Hi Matheus,
>
> On 3/2/17 8:27 AM, David Steele wrote:
>> On 1/18/17 7:18 PM, Petr Jelinek wrote:
>>>
>>> The patch looks good, the only thing I am missing is tab completion
>>> support for psql.
>>
>> It looks like this patch is still waiting on an updat
On 3/17/17 3:58 AM, Kyotaro HORIGUCHI wrote:
> At Mon, 13 Mar 2017 10:42:05 -0400, David Steele wrote
> in <1e8297fd-f7f2-feab-848d-5121e45c8...@pgmasters.net>
>> It has been a while since this thread has received any comments or a new
>> patch. The general consensus seems to be that this featur
On Thu, Mar 16, 2017 at 6:30 PM, David Christensen wrote:
> The HA docs reference a “glossary” link which is no longer accessible, nor is
> it likely to be useful in general to link off-site IMHO. This simple patch
> removes this link.
Committed and back-patched.
Thanks.
--
Robert Haas
Ente
"Daniel Verite" writes:
> Tom Lane wrote:
>> OT_WHOLE_LINE is not what you want because that results in verbatim
>> copying, without variable expansion or anything
> But if we want to implement "\if defined :foo" in the future
> isn't it just what we need?
I don't think that should mean wh
On Fri, Mar 17, 2017 at 8:32 AM, Heikki Linnakangas wrote:
> It would make sense to have \password obey password_encryption GUC. Then
> \password and ALTER USER would do the same thing, which would be less
> surprising. Although it's also a bit weird for a GUC to affect client-side
> behavior, so
On Fri, Mar 17, 2017 at 12:27 PM, Ashutosh Sharma wrote:
> On Fri, Mar 17, 2017 at 8:20 AM, Amit Kapila wrote:
>
> As I said in my previous e-mail, I think you need
>> to record clearing of this flag in WAL record XLOG_HASH_DELETE as you
>> are not doing this unconditionally and then during repla
On 3/17/17 2:08 AM, Fabien COELHO wrote:
>
> Hello David,
>
>>> Repost from bugs.
>>
>> This patch does not apply at cccbdde:
>
> Indeed. It should not. The fix is for the 9.6 branch. The issue has been
> fixed by some heavy but very welcome restructuring in master.
Whoops, sorry about that!
>
On 03/17/2017 02:01 PM, Robert Haas wrote:
On Thu, Mar 16, 2017 at 11:38 PM, Michael Paquier
wrote:
At least this has the merit of making \password simpler from psql
without a kind of --method option: if the backend is 9.6 or older,
just generate a MD5-hash, and SCRAM-hash for newer versions.
P
1 - 100 of 133 matches
Mail list logo
