> On 26 Jan 2017, at 10:34, Michael Paquier wrote:
>
> On Thu, Jan 26, 2017 at 4:09 PM, Nikhil Sontakke
> wrote:
>>> I look at this patch from you and that's present for me:
>>> https://www.postgresql.org/message-id/CAMGcDxf8Bn9ZPBBJZba9wiyQq->Qk5uqq=vjomnrnw5s+fks...@mail.gmail.com
>>
>>> ---
>> Umm, AFAICS, CheckPointTwoPhase() does not get called in the "standby
>> promote" code path.
>
> CreateRestartPoint() calls it via CheckPointGuts() while in recovery.
May be that I am missing something.
But, I put the recovery process and the checkpointer process of the
standby under gdb with
Hello Stephen,
For my 2c, at least, while I'm definitely interested in this, it's not
nearly high enough on my plate with everything else going on to get any
attention in the next few weeks, at least.
Fine with me.
I do think that, perhaps, this patch may deserve a bit of a break, to
allow
Hi
When you have time, could you rebase the pathes?
Some patches cannot be applied to the current HEAD.
0001 patch can be applied but the following 0002 patch cannot be.
I've just started reading your patch (mainly docs and README, not yet source
code.)
Though these are minor things, I've foun
Hi Sawada-san,
On 2017/01/26 16:51, Masahiko Sawada wrote:
Thank you for reviewing!
I think this is a bug of pg_fdw_resolver contrib module. I had
forgotten to change the SQL executed by pg_fdw_resolver process.
Attached latest version 002 patch.
As previous version patch conflicts to current
Hello, Emre.
At Wed, 25 Jan 2017 12:24:18 +0100, Emre Hasegeli wrote in
> I am responding both of your emails together.
>
> > Perhaps I don't understand it. Many opclass are defined for
> > btree. But since (ordinary) btree handles only one-dimentional,
> > totally-orderable sets, geometric ty
On Thu, Jan 5, 2017 at 3:27 AM, Tomas Vondra
wrote:
> Thanks. Those plans match my experiments with the TPC-H data set, although
> I've been playing with the smallest scale (1GB).
>
> It's not very difficult to make the estimation error arbitrary large, e.g.
> by using perfectly correlated (identi
On Thu, Jan 26, 2017 at 6:04 PM, vinayak
wrote:
> Hi Sawada-san,
>
> On 2017/01/26 16:51, Masahiko Sawada wrote:
>
> Thank you for reviewing!
>
> I think this is a bug of pg_fdw_resolver contrib module. I had
> forgotten to change the SQL executed by pg_fdw_resolver process.
> Attached latest vers
On 26 Jan. 2017 18:43, "Stas Kelvich" wrote:
>>
>> Yes, that’s also possible but seems to be less flexible restricting us
to some
>> specific GID format.
>>
>> Anyway, I can measure WAL space overhead introduced by the GID’s inside
commit records
>> to know exactly what will be the cost of such a
On 1/25/17, Haribabu Kommi wrote:
> On Wed, Jan 25, 2017 at 6:43 PM, Vitaly Burovoy
> wrote:
>
>> On 1/23/17, Haribabu Kommi wrote:
>> > The patch is split into two parts.
>> > 1. Macaddr8 datatype support
>> > 2. Contrib module support.
>>
>> Hello,
>>
>> I'm sorry for the delay.
>> The patch i
> Even though I'm not sure but I don't see a "natural" (or
> agreeable by many poeple) ordering of geometric types in
> general. Anyway it's quite application (not application program
> but the relationship with the real world) specific.
We can just define it for point as "ORDER BY point.x, point.
Hello, I'll return on this since this should welcome more eyeballs.
At Thu, 26 Jan 2017 09:03:10 +, "Ideriha, Takeshi"
wrote in
<4E72940DA2BF16479384A86D54D0988A565822A9@G01JPEXMBKW04>
> Hi
>
> When you have time, could you rebase the pathes?
> Some patches cannot be applied to the curren
> On 26 Jan 2017, at 12:51, Craig Ringer wrote:
>
> * Tracking xid/gid map in memory also doesn’t help much — if server reboots
> between prepare
> and commit we’ll lose that mapping.
>
> Er what? That's why I suggested using the prepared xacts shmem state. It's
> persistent as you know from
Thank for looking at this again.
On 25 January 2017 at 06:27, Tom Lane wrote:
> David Rowley writes:
>> However, having said that, I'm not sure why we'd need outer_unique
>> available so we'd know that we could skip mark/restore. I think
>> inner_unique is enough for this purpose. Take the comme
On 26 January 2017 at 04:56, Antonin Houska wrote:
> I suspect that "inner" and "outer" relation / tuple are sometimes confused in
> comments:
>
>
> * analyzejoins.c:70
>
> "searches for subsequent matching outer tuples."
>
>
> * analyzejoins.c:972
>
> /*
> * innerrel_is_unique
> *Check
Hello,
At Thu, 26 Jan 2017 11:53:28 +0100, Emre Hasegeli wrote in
> > Even though I'm not sure but I don't see a "natural" (or
> > agreeable by many poeple) ordering of geometric types in
> > general. Anyway it's quite application (not application program
> > but the relationship with the real
At Thu, 26 Jan 2017 16:29:10 +0900, Michael Paquier
wrote in
> On Wed, Jan 25, 2017 at 7:18 PM, Ishii Ayumi wrote:
> > I patched 4 patchset and run "make", but I got failed.
> > Is this a bug or my mistake ?
> > I'm sorry if I'm wrong.
> >
> > [$(TOP)]$ patch -p1 < ../0001-Add-missing-semicolon
Currently a waiting standby doesn't allow interrupts.
Patch implements that.
Barring objection, patching today with backpatches.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
interrupt_waiting_standby.v1.patch
D
On 13 January 2017 at 10:17, Ants Aasma wrote:
> On 5 Jan 2017 2:54 a.m., "Craig Ringer" wrote:
>> Ants, do you think you'll have a chance to convert your shell script
>> test into a TAP test in src/test/recovery?
>>
>> Simon has said he would like to commit this fix. I'd personally be
>> happier
On Wed, Jan 25, 2017 at 10:31 PM, Stephen Frost wrote:
> Frankly, I get quite tired of the argument essentially being made here
> that because pg_ls_dir() wouldn't grant someone superuser rights, that
> we should remove superuser checks from everything. As long as you are
> presenting it like tha
On 01/23/2017 02:53 PM, Jesper Pedersen wrote:
I have done some more testing with this, and have moved to the patch
back to 'Needs Review' pending Amit's comments.
Moved to "Ready for Committer".
Best regards,
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Craig Ringer writes:
> One suggestion: it's currently non-obvious that ProcessUtility_hook
> gets called with the full text of all parts of a multi-statement.
OK, we can improve that ...
> The same query string may be passed to multiple invocations of
> ProcessUtility
> if a utility stateme
On 12 January 2017 at 15:24, David Rowley wrote:
> I've attached a patch which intended to assist discussions on this topic.
>
> The patch adds some notes to the docs to mention that background
> workers and prepared xacts are not counted in CONNECTION LIMIT, it
> then goes on and makes CountUserB
On Thu, Jan 26, 2017 at 4:32 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > On Wed, Jan 25, 2017 at 9:58 AM, Haribabu Kommi
> > wrote:
> >> All the ereport messages of level are LOG, because of this reason,
> because
> >> of this reason even if we use the TRY/CATCH, it doesn't work. As the
>
On 27 January 2017 at 00:37, David Rowley wrote:
> The attached has my Merge Join changes, to show what I think can be
> done to make use of unique outer. Let me know what you think, but I
> get that idea that we're both leaning towards ripping the outer unique
> stuff out, so I'll go do that now.
Thank you for looking this.
At Thu, 26 Jan 2017 16:28:16 +0900, Michael Paquier
wrote in
> On Tue, Jan 10, 2017 at 8:22 PM, Kyotaro HORIGUCHI
> wrote:
> > [...patch...]
>
> Nobody has showed up yet to review this patch, so I am giving it a shot.
>
> The patch file sizes are scary at first si
Haribabu Kommi writes:
> This patch currently doesn't have the code for reporting the two log
> messages that can occur in tokenize_file function. To support the same,
> I am thinking of changing line_nums list to line_info list that can
> contain both line number and the error message that occurr
On 01/25/2017 05:25 PM, Peter Geoghegan wrote:
On Wed, Jan 25, 2017 at 1:22 PM, Peter Geoghegan wrote:
I understand that my experience with storage devices is unusually
narrow compared to everyone else here. That's why I remain neutral on
the high level question of whether or not we ought to en
On Wed, Jan 25, 2017 at 9:37 AM, Tom Lane wrote:
> Pushed, thanks for the reviews!
I think this is a nice improvement.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On Thu, Jan 26, 2017 at 7:59 AM, David Rowley
wrote:
> On 12 January 2017 at 15:24, David Rowley
> wrote:
>> I've attached a patch which intended to assist discussions on this topic.
>>
>> The patch adds some notes to the docs to mention that background
>> workers and prepared xacts are not coun
On 1/24/17 3:26 AM, Mithun Cy wrote:
> In my code by default, we only dump at shutdown time. If we want to
> dump at regular interval then we need to set the GUC
> pg_autoprewarm.buff_dump_interval to > 0.
Just a thought with an additional use case: If I want to set up a
standby for offloading qu
On 1/24/17 10:51 AM, Robert Haas wrote:
> On Tue, Jan 24, 2017 at 10:28 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Reindent table partitioning code.
>>
>> Oh, thank you, I was starting to get annoyed with that too.
>
> Glad you like. The pgindent damage introduced by the logical
> replicati
Alvaro Herrera wrote:
> I wonder if heap_hot_search_buffer() and heap_hot_search() should return
> a tri-valued enum instead of boolean; that idea looks reasonable in
> theory but callers have to do more work afterwards, so maybe not.
>
> I think heap_hot_search() sometimes leaving the buffer pin
On Thu, Jan 26, 2017 at 10:16 AM, Peter Eisentraut
wrote:
> On 1/24/17 10:51 AM, Robert Haas wrote:
>> On Tue, Jan 24, 2017 at 10:28 AM, Tom Lane wrote:
>>> Robert Haas writes:
Reindent table partitioning code.
>>>
>>> Oh, thank you, I was starting to get annoyed with that too.
>>
>> Glad y
On Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
> Currently a waiting standby doesn't allow interrupts.
>
> Patch implements that.
>
> Barring objection, patching today with backpatches.
"today" is a little quick, but the patch looks fine. I doubt anyone's
going to screech too loud about add
On Wed, Jan 25, 2017 at 4:08 PM, Alvaro Herrera
wrote:
> I think the way WARM works has been pretty well hammered by now, other
> than the CREATE INDEX CONCURRENTLY issues, so I'm looking at the code
> from a maintainability point of view only.
Which senior hackers have previously reviewed it in
Robert Haas wrote:
> 0002 renames programs whose names contains "xlog".
There have been complaints that pg_receivexlog's name is not consistent
with pg_recvlogical, and I seem to recall there were some votes for
renaming pg_receivexlog to match. We could make it "pg_recvwal" now.
--
Álvaro Her
On Thu, Jan 26, 2017 at 12:27 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>
>> 0002 renames programs whose names contains "xlog".
>
> There have been complaints that pg_receivexlog's name is not consistent
> with pg_recvlogical, and I seem to recall there were some votes for
> renaming pg_recei
On 1/24/17 8:19 AM, Tom Lane wrote:
> What about just saying that the database owner has those privileges?
> After all, the ultimate privilege of an owner is to drop the object
> (and then remake it as she pleases), and the DB owner has that option
> w.r.t. the whole database. So I'm not sure we n
Robert Haas writes:
> On Thu, Jan 26, 2017 at 12:27 PM, Alvaro Herrera
> wrote:
>> There have been complaints that pg_receivexlog's name is not consistent
>> with pg_recvlogical, and I seem to recall there were some votes for
>> renaming pg_receivexlog to match. We could make it "pg_recvwal" now
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Thu, Jan 26, 2017 at 12:27 PM, Alvaro Herrera
> > wrote:
> >> There have been complaints that pg_receivexlog's name is not consistent
> >> with pg_recvlogical, and I seem to recall there were some votes for
> >> renaming pg_recei
On Thu, Jan 26, 2017 at 12:37:44PM -0500, Peter Eisentraut wrote:
> On 1/24/17 8:19 AM, Tom Lane wrote:
> > What about just saying that the database owner has those privileges?
> > After all, the ultimate privilege of an owner is to drop the object
> > (and then remake it as she pleases), and the D
On Thu, Jan 26, 2017 at 12:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 26, 2017 at 12:27 PM, Alvaro Herrera
>> wrote:
>>> There have been complaints that pg_receivexlog's name is not consistent
>>> with pg_recvlogical, and I seem to recall there were some votes for
>>> renaming p
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> What I think might be worth considering is inserting underscores,
>> eg "pg_receive_wal", anywhere that we are running the abbreviation
>> directly against another word. We won't get another chance.
> Wouldn't that make it 'pg_rec
On Thursday, January 26, 2017, Michael Banck
wrote:
> On Thu, Jan 26, 2017 at 12:37:44PM -0500, Peter Eisentraut wrote:
> > On 1/24/17 8:19 AM, Tom Lane wrote:
> > > What about just saying that the database owner has those privileges?
> > > After all, the ultimate privilege of an owner is to drop
On Mon, Jan 9, 2017 at 6:14 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> On 1/9/17 1:34 PM, Robert Haas wrote:
> > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut
> > wrote:
> >> On 1/3/17 11:52 PM, Ashutosh Bapat wrote:
> >>> We will need to make CURRENT_DATABASE a reserve
On Mon, Jan 23, 2017 at 2:07 PM, Tom Lane wrote:
> Can we arrange to do that differently? I'd prefer something in which the
> argument and result types are visibly connected to the actual datatypes
> at hand, for instance
> array_subscript(anyarray, internal) returns anyelement
>
On 2017-01-24 16:47:29 -0500, Robert Haas wrote:
> I'm happy to go change every last bit of it.
I quite regret not aggressively opining against the renaming of pg_xlog
to pg_wal. I think the few users deleting their data don't weigh against
renaming a bunch of tools and function for some sense of
On 26 January 2017 at 17:37, Peter Eisentraut
wrote:
> On 1/24/17 8:19 AM, Tom Lane wrote:
>> What about just saying that the database owner has those privileges?
>> After all, the ultimate privilege of an owner is to drop the object
>> (and then remake it as she pleases), and the DB owner has tha
Robert Haas writes:
> Yeah, I thought about that, too, but it doesn't really seem worth it.
> If we had pg_receive_wal and pg_receive_logical, they'd be nicely
> consistent with each other, but inconsistent with practically every
> other utility we have: pg_basebackup, pg_archivecleanup,
> pg_cont
On Tue, Jan 24, 2017 at 10:26 PM, Michael Paquier
wrote:
> On Wed, Jan 25, 2017 at 6:58 AM, Robert Haas wrote:
>> On Fri, Jan 20, 2017 at 7:00 PM, Michael Paquier
>> wrote:
No, because the output of SHOW is always of type text, regardless of
the type of the GUC.
>>>
>>> Thinking about
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-24 16:47:29 -0500, Robert Haas wrote:
> > I'm happy to go change every last bit of it.
>
> I quite regret not aggressively opining against the renaming of pg_xlog
> to pg_wal. I think the few users deleting their data don't weigh against
> r
On 2017-01-26 13:16:13 -0500, Robert Haas wrote:
> > OK, I have done this refactoring effort as attached because I think
> > that's really worth it. And here are the diff numbers:
> > 3 files changed, 113 insertions(+), 162 deletions(-)
> > That's a bit less than what I thought first because of al
Robert Haas writes:
> On Mon, Jan 23, 2017 at 2:07 PM, Tom Lane wrote:
>> Can we arrange to do that differently? I'd prefer something in which the
>> argument and result types are visibly connected to the actual datatypes
>> at hand, for instance
>> array_subscript(anyarray, internal) returns an
On Tue, Jan 24, 2017 at 3:10 PM, Amit Kapila wrote:
> 1.
> @@ -505,26 +505,22 @@ hashbulkdelete(IndexVacuumInfo *info,
> In the above flow, do we really need an updated metapage, can't we use
> the cached one? We are already taking care of bucket split down in
> that function.
Yes, we can use t
On Thu, Jan 26, 2017 at 1:21 PM, Andres Freund wrote:
> On 2017-01-24 16:47:29 -0500, Robert Haas wrote:
>> I'm happy to go change every last bit of it.
>
> I quite regret not aggressively opining against the renaming of pg_xlog
> to pg_wal. I think the few users deleting their data don't weigh ag
Hi,
On 2017-01-26 19:00:34 +, Simon Riggs wrote:
> Check interrupts during hot standby waits
>
> Branch
> --
> master
>
> Details
> ---
> http://git.postgresql.org/pg/commitdiff/e8ee3d6b859a18d7f7375ceb9e04d256eb18aaec
>
> Modified Files
> --
> src/backend/storage/ipc/stand
On Thu, Jan 26, 2017 at 1:38 PM, Tom Lane wrote:
> So I'd really prefer that the functionality
> involve a parser callout, and that would certainly need "internal"
> argument(s).
Thanks, I see now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
On Thu, Jan 26, 2017 at 1:34 PM, Andres Freund wrote:
> On 2017-01-26 13:16:13 -0500, Robert Haas wrote:
>> > OK, I have done this refactoring effort as attached because I think
>> > that's really worth it. And here are the diff numbers:
>> > 3 files changed, 113 insertions(+), 162 deletions(-)
>
Hi,
On 2017-01-23 11:35:11 +0530, Beena Emerson wrote:
> Please find attached an updated WIP patch. I have incorporated almost all
> comments. This is to be applied over Robert's patches. I will post
> performance results later on.
>
> 1. shift (>>) and AND (&) operations: The assign hook of wal_s
On 2017-01-26 14:05:43 -0500, Robert Haas wrote:
> I completely understand that position. I have always been doubtful of
> the value of renaming pg_xlog to pg_wal, and I'm not any more
> dedicated to the idea now than I was when I committed that patch. But
> there was overwhelming support for it,
Hi,
On 2017-01-25 12:26:21 +0900, Michael Paquier wrote:
> diff --git a/src/backend/access/common/tupdesc.c
> b/src/backend/access/common/tupdesc.c
> index 083c0303dc..2eb3a420ac 100644
> --- a/src/backend/access/common/tupdesc.c
> +++ b/src/backend/access/common/tupdesc.c
> @@ -629,6 +629,14 @@
On 2017-01-26 12:24:44 -0500, Robert Haas wrote:
> On Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
> > Currently a waiting standby doesn't allow interrupts.
> >
> > Patch implements that.
> >
> > Barring objection, patching today with backpatches.
>
> "today" is a little quick, but the patch
On Thu, Jan 26, 2017 at 12:13 PM, Andres Freund wrote:
> On 2017-01-26 14:05:43 -0500, Robert Haas wrote:
> > I completely understand that position. I have always been doubtful of
> > the value of renaming pg_xlog to pg_wal, and I'm not any more
> > dedicated to the idea now than I was when I co
On 2017-01-26 12:23:24 -0700, David G. Johnston wrote:
> On Thu, Jan 26, 2017 at 12:13 PM, Andres Freund wrote:
>
> > On 2017-01-26 14:05:43 -0500, Robert Haas wrote:
> > > I completely understand that position. I have always been doubtful of
> > > the value of renaming pg_xlog to pg_wal, and I'
On Thu, Jan 26, 2017 at 2:13 PM, Andres Freund wrote:
> On 2017-01-26 14:05:43 -0500, Robert Haas wrote:
>> I completely understand that position. I have always been doubtful of
>> the value of renaming pg_xlog to pg_wal, and I'm not any more
>> dedicated to the idea now than I was when I committ
On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund wrote:
>> Whether the voters recognized that fact at the time I would have to concur
>> that if we are going to change from xlog to wal we should be all-in. If
>> you want to vote to reject putting the whole camel in the tent I would say
>> its a vot
David Rowley writes:
> I've attached a version without outer unique.
I looked through this a bit, and the first thing I noticed was it doesn't
touch costsize.c at all. That seems pretty wrong; it's little help to
have a performance improvement if the planner won't pick the right plan
type. Ther
On 26 January 2017 at 19:20, Andres Freund wrote:
> On 2017-01-26 12:24:44 -0500, Robert Haas wrote:
>> On Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
>> > Currently a waiting standby doesn't allow interrupts.
>> >
>> > Patch implements that.
>> >
>> > Barring objection, patching today with
On 2017-01-26 14:28:01 -0500, Robert Haas wrote:
> On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund wrote:
> >> Whether the voters recognized that fact at the time I would have to concur
> >> that if we are going to change from xlog to wal we should be all-in. If
> >> you want to vote to reject put
On 2017-01-26 19:36:11 +, Simon Riggs wrote:
> On 26 January 2017 at 19:20, Andres Freund wrote:
> > On 2017-01-26 12:24:44 -0500, Robert Haas wrote:
> >> On Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
> >> > Currently a waiting standby doesn't allow interrupts.
> >> >
> >> > Patch imple
Robert Haas writes:
> On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund wrote:
>>> Whether the voters recognized that fact at the time I would have to concur
>>> that if we are going to change from xlog to wal we should be all-in. If
>>> you want to vote to reject putting the whole camel in the ten
Robert Haas wrote:
> On Wed, Jan 25, 2017 at 4:08 PM, Alvaro Herrera
> wrote:
> > I think the way WARM works has been pretty well hammered by now, other
> > than the CREATE INDEX CONCURRENTLY issues, so I'm looking at the code
> > from a maintainability point of view only.
>
> Which senior hacker
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-26 19:36:11 +, Simon Riggs wrote:
> > Tomorrow is too late.
>
> Huh? We're not wrapping today/tomorrow, are we? If I missed something
> and we are, then sure, it makes sense to push ahead.
I haven't seen anyone suggest that we're chang
On Thu, Jan 26, 2017 at 12:37 PM, Andres Freund wrote:
> On 2017-01-26 14:28:01 -0500, Robert Haas wrote:
> > On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund
> wrote:
> > >> Whether the voters recognized that fact at the time I would have to
> concur
> > >> that if we are going to change from xlo
-Hackers,
From the field. I do not care what you chose, I care that:
1. It is consistent
2. It is readable/understandable
3. It is documented
4. It is done wholesale (because of usability)
That's it. So whatever meets that criteria, let's go for it. That may
mean that certain commands look a l
Corey Huinker wrote:
> Revised patch
A comment about control flow and variables:
in branches that are not taken, variables are expanded
nonetheless, in a way that can be surprising.
Case in point:
\set var 'ab''cd'
-- select :var;
\if false
select :var ;
\else
select 1;
\endif
The
On 1/25/17 5:29 AM, Petr Jelinek wrote:
> On 25/01/17 03:48, Peter Eisentraut wrote:
>> We maintain a separate test output file sequence_1.out because the
>> log_cnt value can vary if there is a checkpoint happening at the right
>> time. So we have to maintain two files because of a one character
Simon Riggs wrote:
> On 26 January 2017 at 19:20, Andres Freund wrote:
> > I'm personally fine with going with a CHECK_FOR_INTERRUPTS
> > for now, but I think it'd better to replace it with a latch.
>
> I have waited, so not sure what you mean. Tomorrow is too late.
>
> Replacing with a latch w
Tom Lane wrote:
> Andrew Dunstan writes:
> > On 01/24/2017 05:17 AM, Alvaro Herrera wrote:
> >> Maybe we can drop that line and put it back once we get COMMENT ON
> >> CURRENT_DATABASE.
>
> > Works for me.
>
> If that's enough to get the "make check" cases passing in the buildfarm,
> then +1.
O
Hello Daniel,
A comment about control flow and variables: in branches that are not
taken, variables are expanded nonetheless, in a way that can be
surprising. Case in point:
\set var 'ab''cd'
-- select :var;
\if false
select :var ;
\else
select 1;
\endif
To avoid that kind of trouble, wou
On Thu, Jan 26, 2017 at 3:55 PM, Fabien COELHO wrote:
>
> Hello Daniel,
>
> A comment about control flow and variables: in branches that are not
>> taken, variables are expanded nonetheless, in a way that can be surprising.
>> Case in point:
>>
>> \set var 'ab''cd'
>> -- select :var;
>> \if false
On 27 January 2017 at 08:34, Tom Lane wrote:
> David Rowley writes:
>> I've attached a version without outer unique.
>
> I looked through this a bit, and the first thing I noticed was it doesn't
> touch costsize.c at all. That seems pretty wrong; it's little help to
> have a performance improvem
On 2017-01-25 19:21:40 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-12-31 12:08:22 -0500, Peter Eisentraut wrote:
> >> RestrictInfo *rinfo = castNode(RestrictInfo, lfirst(lc));
>
> > Are you planning to add this / update this patch? Because I really would
> > have liked this a number
Alvaro Herrera writes:
> It is really quite annoying that the buildfarm doesn't do what stock
> tests do. What about pushing a bit stronger for having these
> optimizations as part of the standard build run, instead of being only
> in the buildfarm client script?
Huh? It's just a question of "m
Tom Lane wrote:
> Alvaro Herrera writes:
> > It is really quite annoying that the buildfarm doesn't do what stock
> > tests do. What about pushing a bit stronger for having these
> > optimizations as part of the standard build run, instead of being only
> > in the buildfarm client script?
>
> Hu
Andres Freund writes:
> How about something like the attached? The first patch just contains
> castNode(), the second one a rebased version of Peter's changes (with
> some long lines broken up).
Looks generally good. A couple quibbles from a quick read-through:
* All but the first change in Pro
On Thu, Jan 26, 2017 at 2:37 PM, Andres Freund wrote:
> On 2017-01-26 14:28:01 -0500, Robert Haas wrote:
>> On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund wrote:
>> >> Whether the voters recognized that fact at the time I would have to concur
>> >> that if we are going to change from xlog to wal
* Robert Haas (robertmh...@gmail.com) wrote:
> And I think that's all pretty reasonable. I don't consider this a
> done deal yet. I don't consider your -1 irrelevant. But I don't
> think it's fair to present this as if I am somehow running roughshod
> over community process, either. If a large
On 1/26/17 5:07 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> And I think that's all pretty reasonable. I don't consider this a
>> done deal yet. I don't consider your -1 irrelevant. But I don't
>> think it's fair to present this as if I am somehow running roughshod
On 2017-01-26 16:55:37 -0500, Robert Haas wrote:
> On Thu, Jan 26, 2017 at 2:37 PM, Andres Freund wrote:
> > On 2017-01-26 14:28:01 -0500, Robert Haas wrote:
> >> On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund wrote:
> >> >> Whether the voters recognized that fact at the time I would have to
> >
On 2017-01-26 16:55:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> > How about something like the attached? The first patch just contains
> > castNode(), the second one a rebased version of Peter's changes (with
> > some long lines broken up).
>
> Looks generally good. A couple quibbles fro
Andres Freund writes:
> #if defined(USE_ASSERT_CHECKING) && defined(PG_USE_INLINE)
> is probably a better gatekeeper in the back-branches, than gcc?
Ah, yeah, that would work --- I'd already swapped out that business ;-)
regards, tom lane
--
Sent via pgsql-hackers mail
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 25, 2017 at 10:31 PM, Stephen Frost wrote:
> > Frankly, I get quite tired of the argument essentially being made here
> > that because pg_ls_dir() wouldn't grant someone superuser rights, that
> > we should remove superuser checks
On Thu, Jan 26, 2017 at 3:28 PM, Andres Freund wrote:
> I *personally* don't think it's worth
> changing all this without taking more care about backward compat than
> we're apparently willing to do. I'm ok with loosing that argument. I
> just don't think the previous concensus for a narrower c
Dear Hackers,
I have solved this problem. I just want to post my answer here for people
who want to write their own backend index access method.
When we write a backend index access method (Let's call this method ABC),
we need to implement two interfaces: ABCbuild, ABCbuildcallback.
ABCbuild is
On 2017-01-26 15:45:15 -0700, David G. Johnston wrote:
> On Thu, Jan 26, 2017 at 3:28 PM, Andres Freund wrote:
>
> > I *personally* don't think it's worth
> > changing all this without taking more care about backward compat than
> > we're apparently willing to do. I'm ok with loosing that argumen
On 26 January 2017 at 21:42, Tom Lane wrote:
> Craig Ringer writes:
>> One suggestion: it's currently non-obvious that ProcessUtility_hook
>> gets called with the full text of all parts of a multi-statement.
>
> OK, we can improve that ...
>
>> The same query string may be passed to multiple in
To re-familiarize myself with this patch, I've been re-reading the thread,
which has gotten quite long. It seemed like it would be a good idea to
stop and try to summarize what the patch ought to accomplish, because
there's been some drift over the more than 2 years the patch has been
in the works
On 26 January 2017 at 19:34, Stas Kelvich wrote:
> Imagine following scenario:
>
> 1. PREPARE happend
> 2. PREPARE decoded and sent where it should be sent
> 3. We got all responses from participating nodes and issuing COMMIT/ABORT
> 4. COMMIT/ABORT decoded and sent
>
> After step 3 there is no m
1 - 100 of 129 matches
Mail list logo
