Last update on the issue with deadlock in XLogInsert.
After almost one day of working, pgbench is once again not working
normally:(
There are no deadlock, there are no core files and no error messages in log.
But TPS is almost zero:
progress: 57446.0 s, 1.1 tps, lat 3840.265 ms stddev NaNQ
pro
On 02/01/2017 11:26 AM, Tom Lane wrote:
> "Daniel Verite" writes:
>> That works for me. I tested and read it and did not find anything
>> unexpected or worth objecting.
>> "\unset var" acting as "\set var off" makes sense considering
>> that its opposite "\set var" is now an accepted
>> synonym
On 02/02/2017 05:50 AM, David Rowley wrote:
On 2 February 2017 at 00:13, Heikki Linnakangas wrote:
Ok, I'll drop the second patch for now. I committed the first patch after
fixing the things you and Michael pointed out. Thanks for the review!
dbd69118 caused small compiler warning for me.
Th
On 02/01/2017 11:52 PM, Alvaro Herrera wrote:
Still looking at 0002.
pg_ndistinct_in disallows input, claiming that pg_node_tree does the
same thing. But pg_node_tree does it for security reasons: you could
crash the backend if you supplied a malicious value. I don't think
that applies to p
On 30 January 2017 at 16:43, Tom Lane wrote:
> Simon Riggs writes:
>> Agreed. Let me reiterate: all I want in this release is
>> super-ownership.
>
> While I'm not entirely convinced whether super-ownership is a good idea
> or not, I am pretty sure that rushing to get it into v10 is a bad idea.
>
On 30 January 2017 at 16:34, Peter Eisentraut
wrote:
> On 1/30/17 9:04 AM, Simon Riggs wrote:
>> all I want in this release is
>> super-ownership.
>
> What exactly is super-ownership, and what problems does it solve?
The problem is that there is no easy way for a DBA to have privs on
multiple set
Tom Lane writes:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> While playing with prepared statements in psql, I noticed that EXECUTE
>> tab-completes the list of active prepared statements, but DEALLOCATE
>> does not.
>> Attached is a patch to fix this.
>
> Good idea
>
> + ptr = (char *) itup + IndexInfoFindDataOffset(itup->t_info);
> + Assert(ptr <= uargs->page + BLCKSZ);
>
> I think this should be promoted to an ereport(); these functions can
> accept an arbitrary bytea.
I think we had added 'ptr' variable initially just to dump h
Hi,
In following case, constraint exclusion not able prune partition (even
if function is immutable), is this know behaviour?
--CASE 1 : create table & insert data
create table foo_list (a integer, b text) partition by list (abs(a));
create table foo_list1 partition of foo_list for values in (0)
Hello, I digged this topic covered by a spiderweb..
# PostGIS requires so many libraries installed :(
FIY, for the given test case, the following query hits the bug.
| SELECT edge.geom AS geom
| FROM (SELECT * FROM knn_recheck_geom) AS edge
| ORDER BY '01010014AE47E17A141FC09AA170C0'
I forgot to mention this..
At Thu, 02 Feb 2017 21:11:16 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170202.26.49572782.horiguchi.kyot...@lab.ntt.co.jp>
> Hello, I digged this topic covered by a spiderweb..
>
> # PostGIS requires so many libraries installed :(
>
> FIY, for t
On Mon, Jan 30, 2017 at 7:20 PM, Pavan Deolasee
wrote:
> Hello All,
>
> While stress testing WARM, I encountered a data consistency problem. It
> happens when index is built concurrently. What I thought to be a WARM
> induced bug and it took me significant amount of investigation to finally
> conc
Hello,
What do I need to do to get TAP tests running?
I misunderstood. You need to configure with "--enable-tap-tests".
There is a spurious empty line added at the very end of "mainloop.h":
+
#endif /* MAINLOOP_H */
Not in my diff, but that's been coming and going in your diff rev
On Thu, Feb 2, 2017 at 6:08 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 1/22/17 10:29 PM, Michael Paquier wrote:
> > As now wal_level = replica has become the default for Postgres 10,
> > could we consider as well making replication connections enabled by
> > default in pg
Hi hackers,
We have found that in parallel mode result of queries is non-deterministic
when the types of the attributes in table are double precision
(floating-point).
Our example is based on TPC-H, but some NUMERIC columns type was changed to
DOUBLE PRECISION;
When running without parallelism
Hello hackers,
The view information_schema.constraint_column_usage becomes slow when
the number of columns and constraints raise to substantial values.
This is because of a join condition that allows only join filter to
enforce. The patch is to optimize it.
See many_constraints.sql file attache
Pavan Deolasee wrote:
> Do you think we should apply the patch to remove ItemPointerCopy()? I will
> rework the HeapTupleHeaderGetNextTid() after that. Not that it depends on
> removing ItemPointerCopy(), but decided to postpone it until we make a call
> on that patch.
My inclination is not to.
On 23 January 2017 at 04:29, Michael Paquier wrote:
> Hi all,
>
> As now wal_level = replica has become the default for Postgres 10,
> could we consider as well making replication connections enabled by
> default in pg_hba.conf?
Agreed
> This requires just uncommenting a couple of
> lines in pg_
Hi Konstantin
I've discussed the "zombie/exit" issue with our expert here.
- He does not think that AIX has anything special here
- If the process is marked in ps, this is because the flag SEXIT is
set, thus the process is blocked somewhere in the kexitx() syscall, waiting for
something.
- I
On 02/02/17 14:32, Simon Riggs wrote:
> On 23 January 2017 at 04:29, Michael Paquier
> wrote:
>> Hi all,
>>
>> As now wal_level = replica has become the default for Postgres 10,
>> could we consider as well making replication connections enabled by
>> default in pg_hba.conf?
>
> Agreed
>
>> Thi
Ruben Buchatskiy writes:
> We have found that in parallel mode result of queries is non-deterministic
> when the types of the attributes in table are double precision
> (floating-point).
Yeah ...
> That is because floating-point addition is not necessarily associative.
Right, exactly.
> Is thi
On Mon, Jan 30, 2017 at 7:20 PM, Pavan Deolasee
wrote:
>
> Based on my investigation so far and the evidence that I've collected,
> what probably happens is that after a relcache invalidation arrives at the
> new transaction, it recomputes the rd_indexattr but based on the old,
> cached rd_indexl
On Thu, Feb 02, 2017 at 03:16:29PM +, Bruce Momjian wrote:
> I just don't see this patch going in. I think it needs are larger
> approach to the problems it is trying to solve. I think it then
> will be very useful.
What problems that it's trying to solve are not addressed?
Best,
David.
--
Hi Konstantin
I have an issue with pgbench. Any idea ?
# mkdir /tmp/PGS
# chown pgstbf.staff /tmp/PGS
# su pgstbf
$ /opt/freeware/bin/initdb -D /tmp/PGS
The files belonging to this database system will be owned by user "pgstbf".
This user must also own the server prcess.
The database
I just don't see this patch going in. I think it needs are larger approach to
the problems it is trying to solve. I think it then will be very useful.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On Thu, Feb 2, 2017 at 07:18:45AM -0800, David Fetter wrote:
> On Thu, Feb 02, 2017 at 03:16:29PM +, Bruce Momjian wrote:
> > I just don't see this patch going in. I think it needs are larger
> > approach to the problems it is trying to solve. I think it then
> > will be very useful.
>
> Wh
The developer meeting in Brussels ran out of topics :), so we have spent
some time going through the patches on the upcoming CF. We did manage to
assign a couple of patches to people (and we also discussed but didn't
actually assign all the patches that Robert has his hands in :P).
And we found on
On 02.02.2017 18:20, REIX, Tony wrote:
Hi Konstantin
I have an issue with pgbench. Any idea ?
Pgbench -s options specifies scale.
Scale 1000 corresponds to 1000 million rows and requires about 16Gb at disk.
# mkdir /tmp/PGS
# chown pgstbf.staff /tmp/PGS
# su pgstbf
$ /opt/freeware/bi
On Thu, Feb 2, 2017 at 2:36 PM, Michael Paquier
wrote:
> On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane wrote:
>> Kyotaro HORIGUCHI writes:
>>> Then, the reason for the TRY-CATCH cluase is that I found that
>>> some functions called from there can throw exceptions.
>>
>> Yes, but all LWLocks should be
On Thu, Feb 02, 2017 at 10:34:43AM -0500, Bruce Momjian wrote:
> On Thu, Feb 2, 2017 at 07:18:45AM -0800, David Fetter wrote:
> > On Thu, Feb 02, 2017 at 03:16:29PM +, Bruce Momjian wrote:
> > > I just don't see this patch going in. I think it needs are
> > > larger approach to the problems i
2017-02-02 16:34 GMT+01:00 Bruce Momjian :
> On Thu, Feb 2, 2017 at 07:18:45AM -0800, David Fetter wrote:
> > On Thu, Feb 02, 2017 at 03:16:29PM +, Bruce Momjian wrote:
> > > I just don't see this patch going in. I think it needs are larger
> > > approach to the problems it is trying to solv
Hi Tony,
On 02.02.2017 17:10, REIX, Tony wrote:
Hi Konstantin
I've discussed the "zombie/exit" issue with our expert here.
- He does not think that AIX has anything special here
- If the process is marked in ps, this is because the flag
SEXIT is set, thus the process is blocked somewhere i
Pavel Stehule wrote:
> Identification of unjoined tables should be very useful - but it is far to
> original proposal - so it can be solved separately.
>
> This patch is simple - and usually we prefer more simple patches than one
> bigger.
>
> Better to enhance this feature step by step.
Agreed
Pavan Deolasee wrote:
> I can reproduce this entire scenario using gdb sessions. This also explains
> why the patch I sent earlier helps to solve the problem.
Ouch. Great detective work there.
I think it's quite possible that this bug explains some index errors,
such as primary keys (or unique
Andres Freund writes:
> On 2017-02-01 23:27:36 -0500, Tom Lane wrote:
>> I think the appropriate fix is that, once split_pathtarget_at_srfs() has
>> computed a tentative list of SRFs it needs to evaluate, it has to make a
>> second pass to see if any of them match expressions that were assigned to
Alvaro Herrera writes:
> Pavel Stehule wrote:
>> Better to enhance this feature step by step.
> Agreed -- IMO this is a reasonable first step, except that I would
> rename the proposed extension so that it doesn't focus solely on the
> first step.
Quite. The patch fails to make up its mind whet
On Thu, Feb 02, 2017 at 12:14:10PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Pavel Stehule wrote:
> >> Better to enhance this feature step by step.
>
> > Agreed -- IMO this is a reasonable first step, except that I would
> > rename the proposed extension so that it doesn't focus solely
On Thu, Feb 2, 2017 at 2:48 PM, Michael Paquier
wrote:
> Hi all,
>
> While testing a bit the logical replication facility, I have bumped on
> the fast that psql's completion does not show the list of things
> already created. Attached is a patch.
+#define Query_for_list_of_subscriptions \
+" SELE
On Thu, Feb 02, 2017 at 12:14:10PM -0500, Tom Lane wrote:
> Also, somebody who wants a check like that isn't necessarily going to want
> "no WHERE clause" training wheels. So you're going to need to think about
> facilities to enable or disable different checks.
WHERE-less-ness should be somethin
On 2/2/17 8:32 AM, Simon Riggs wrote:
> I think we should remove the "replication" false database concept in
> pg_hba.conf altogether and allow any valid pg_hba rule to invoke a
> replication connection, if one is requested. Roles would still need
> the REPLICATION capability before this would be a
On 2/2/17 12:48 PM, Fujii Masao wrote:
> +#define Query_for_list_of_subscriptions \
> +" SELECT pg_catalog.quote_ident(subname) "\
> +" FROM pg_catalog.pg_subscription "\
> +" WHERE substring(pg_catalog.quote_ident(subname),1,%d)='%s'"
>
> Since non-superuser is not allowed to access to pg_subs
On 2/2/17 12:48 AM, Michael Paquier wrote:
> +#define Query_for_list_of_subscriptions \
> +" SELECT pg_catalog.quote_ident(subname) "\
> +" FROM pg_catalog.pg_subscription "\
> +" WHERE substring(pg_catalog.quote_ident(subname),1,%d)='%s'"
This query should also be qualified by current database
On Thu, Feb 2, 2017 at 6:29 AM, Ashutosh Sharma wrote:
>>
>> + ptr = (char *) itup + IndexInfoFindDataOffset(itup->t_info);
>> + Assert(ptr <= uargs->page + BLCKSZ);
>>
>> I think this should be promoted to an ereport(); these functions can
>> accept an arbitrary bytea.
On 02/02/2017 02:24 PM, Robert Haas wrote:
So, committed. Wow, I wish every patch had this many reviewers.
Thanks Robert !
Best regards,
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On Wed, Feb 1, 2017 at 2:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> Also, including the GID in the WAL for each COMMIT/ABORT PREPARED
>> doesn't seem inordinately expensive to me.
>
> I'm confused ... isn't it there already? If not, how do we handle
> reconstructing 2PC state from WAL at al
On Wed, Feb 1, 2017 at 4:35 PM, Craig Ringer wrote:
> Right. Per my comments uothread I don't see why we need to add anything more
> to WAL here.
>
> Stas was concerned about what happens in logical decoding if we crash
> between PREPSRE TRANSACTION and COMMIT PREPARED. But we'll always go back
>
On 2/1/17 4:28 PM, Andres Freund wrote:
On 2016-11-28 11:40:53 -0800, Jim Nasby wrote:
With current limits, the most bgwriter can do (with 8k pages) is 1000 pages
* 100 times/sec = 780MB/s. It's not hard to exceed that with modern
hardware. Should we increase the limit on bgwriter_lru_maxpages?
On Wed, Feb 1, 2017 at 9:47 PM, Jim Nasby wrote:
> Before doing that the first thing to look at would be why the limit is
> currently INT_MAX / 2 instead of INT_MAX.
Generally the rationale for GUCs with limits of that sort is that
there is or might be code someplace that multiplies the value by
On 2017-02-02 11:41:44 -0800, Jim Nasby wrote:
> On 2/1/17 4:28 PM, Andres Freund wrote:
> > On 2016-11-28 11:40:53 -0800, Jim Nasby wrote:
> > > With current limits, the most bgwriter can do (with 8k pages) is 1000
> > > pages
> > > * 100 times/sec = 780MB/s. It's not hard to exceed that with mod
On 2017-02-02 14:47:53 -0500, Robert Haas wrote:
> I expect that increasing the maximum value of shared_buffers beyond
> what can be stored by an integer could have a noticeable distributed
> performance cost for the entire system. It might be a pretty small
> cost, but then again maybe not; for e
On 2 February 2017 at 18:48, Peter Eisentraut
wrote:
> On 2/2/17 8:32 AM, Simon Riggs wrote:
>> I think we should remove the "replication" false database concept in
>> pg_hba.conf altogether and allow any valid pg_hba rule to invoke a
>> replication connection, if one is requested. Roles would sti
Hello,
There may possibly be a very small window for a double exit() self-deadlock
during a forked backend process's ProcessStartupPacket returns and status
is not STATUS_OK. The process will go into proc_exit and then a very well
timed SIGQUIT will call startup_die for another proc_exit. If tim
Erik Rijkers writes:
> Something is broken in HEAD:
Fixed, thanks for the report!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-02-02 22:44, Tom Lane wrote:
Erik Rijkers writes:
Something is broken in HEAD:
Fixed, thanks for the report!
Indeed, the complicated version of the script runs again as before.
Thank you very much,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Wed, Feb 1, 2017 at 4:58 PM, Jim Nasby wrote:
> I think the issue here is that the original case for this is a user
> accidentally getting into an \if and then having no clue what's going on.
> That's similar to what happens when you miss a quote or a semicolon. We
> handle those cases with %R
>
>
> All,
> As it is, I've added interactive mode psql_error notifications about the
> resulting branching state of any branching commands, and any attempt to
> send non-branching commands or queries while in an inactive branch will
> generate a psql_error saying that the command was ignored. Wait
Peter Eisentraut wrote:
> You really have (at least) three options here:
>
> 1. Rename nothing
> 2. Rename directory only
> 3. Rename everything
I vote for 1) as I believe the renaming will create more confusion
than it's worth, not even considering the renaming of functions
and views.
On Fri, Feb 3, 2017 at 8:50 AM, Daniel Verite wrote:
> What if we look at the change from the pessimistic angle?
> An example of confusion that the change would create:
> a lot of users currently choose pg_wal for the destination
> directory of their archive command.
Really? I find that surprisin
On 3 February 2017 at 03:34, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 4:35 PM, Craig Ringer wrote:
>> Right. Per my comments uothread I don't see why we need to add anything more
>> to WAL here.
>>
>> Stas was concerned about what happens in logical decoding if we crash
>> between PREPSRE TRAN
On Wed, Feb 01, 2017 at 02:39:25PM +0200, Heikki Linnakangas wrote:
> On 02/01/2017 01:07 PM, Konstantin Knizhnik wrote:
> >Attached please find my patch for XLC/AIX.
> >The most critical fix is adding __sync to pg_atomic_fetch_add_u32_impl.
> >The comment in this file says that:
> >
> > * __
On Fri, Feb 3, 2017 at 4:28 AM, Jesper Pedersen
wrote:
> On 02/02/2017 02:24 PM, Robert Haas wrote:
>>
>> So, committed. Wow, I wish every patch had this many reviewers.
>>
>
> Thanks Robert !
9 people in total per the commit message. Yes that's rare, and thanks
for doing the effort to list ever
On 2 February 2017 at 11:45, Euler Taveira wrote:
> I don't think storage without conversion is an acceptable approach. We
> should provide options to users such as ignore tuple or NULL for
> column(s) with conversion problem. I wouldn't consider storage data
> without conversion because it silen
Corey Huinker writes:
>> As it is, I've added interactive mode psql_error notifications about the
>> resulting branching state of any branching commands, and any attempt to
>> send non-branching commands or queries while in an inactive branch will
>> generate a psql_error saying that the command w
On 2017/02/02 21:09, amul sul wrote:
> Hi,
>
> In following case, constraint exclusion not able prune partition (even
> if function is immutable), is this know behaviour?
Yes. The where condition in your example query does not specify the
partition key column, so constraint exclusion won't work,
At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao wrote in
> On Thu, Feb 2, 2017 at 2:36 PM, Michael Paquier
> wrote:
> > On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane wrote:
> >> Kyotaro HORIGUCHI writes:
> >>> Then, the reason for the TRY-CATCH cluase is that I found that
> >>> some functions calle
>
>
> On reflection, it seems fairly improbable to me that people would use
> \if and friends interactively. They're certainly useful for scripting,
> but would you really type commands that you know are going to be ignored?
>
I'm thinking the one use-case is where a person is debugging a
non-int
On 2017/01/31 6:42, Peter Eisentraut wrote:
> On 1/25/17 12:54 AM, Ashutosh Bapat wrote:
>> The documentation available at
>> https://www.postgresql.org/docs/devel/static/sql-createtable.html,
>> does not make it clear that the lower bound of a range partition is
>> always inclusive and the higher
Hello,
At Fri, 3 Feb 2017 09:16:47 +0800, Craig Ringer wrote
in
> On 2 February 2017 at 11:45, Euler Taveira wrote:
>
> > I don't think storage without conversion is an acceptable approach. We
> > should provide options to users such as ignore tuple or NULL for
> > column(s) with conversion p
At Thu, 2 Feb 2017 15:34:33 +0900, Michael Paquier
wrote in
> On Thu, Feb 2, 2017 at 1:26 AM, Fujii Masao wrote:
> > I'm afraid that many WAL segments would start with a continuation record
> > when there are the workload of short transactions (e.g., by pgbench), and
> > which would make restar
>> I think it's OK to check hash_bitmap_info() or any other functions
>> with different page types at least once.
>>
>> [1]-
>> https://www.postgresql.org/message-id/CA%2BTgmoZUjrVy52TUU3b_Q5L6jcrt7w5R4qFwMXdeCuKQBmYWqQ%40mail.gmail.com
>
> Sure, I just don't know if we need to test them 4 or 5 ti
Tnanks to that Heikki have pushed the first two patches and a
part of the third, only one patch is remaining now.
# Sorry for not separating KOI8 stuffs.
At Tue, 31 Jan 2017 19:06:09 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170131.190609.254672218.horiguchi.kyot...@lab.ntt.co
On 3 Feb. 2017 15:47, "Kyotaro HORIGUCHI"
wrote:
Hello,
At Fri, 3 Feb 2017 09:16:47 +0800, Craig Ringer
wrote in
> On 2 February 2017 at 11:45, Euler Taveira wrote:
>
> > I don't think storage without conversion is an acceptable approach. We
> > should provide options to users such as ignore
2017-02-01 6:42 GMT+01:00 Pavel Stehule :
>
>
> 2017-02-01 6:05 GMT+01:00 Michael Paquier :
>
>> On Wed, Jan 11, 2017 at 10:42 PM, Craig Ringer
>> wrote:
>> > There is no code yet. Code review and testing is where things get
>> firmer.
>> >
>> > My personal stance right now is that I'd like to se
Hello Corey,
Glad you like the barking. I'm happy to let the prompt issue rest for now,
we can always add it later.
If we DID want it, however, I don't think it'll be hard to add a special
prompt (Thinking %T or %Y because they both look like branches, heh),
Ah!:-) T may stand for Tree, but
There is a link - comparation Oracle package variables and DB2 global
variables
https://www.ibm.com/developerworks/data/library/techarticle/dm-0711zubiri/
Regards
Pavel
On Fri, Feb 3, 2017 at 2:56 PM, Pavel Stehule wrote:
> My patch was marked as "returned with feedback". Personally, I had not a
> idea what can be next step and what is preferred design, if some preferred
> design exists. I don't know what I have to change on my proposal.
Perhaps this was not ad
Hello Pavel,
The @1 area is partially solved by psql session variables or by pgAdmin
scripting functionality. @2 is partially solved by GUC but without
possibility to set a access rights.
I didn't found any implementation of XA variables [...]
I did: GUCs in PostgreSQL are an implementation
2017-01-20 17:01 GMT+01:00 Joshua D. Drake :
> On 01/17/2017 09:26 AM, Robert Haas wrote:
>
>> On Fri, Jan 13, 2017 at 7:24 PM, Peter Geoghegan wrote:
>>
>>> MERGE isn't UPSERT, and isn't even in competition with UPSERT as a
>>> feature. I've written reams of text explaining why this is so in
>>>
On 3 February 2017 at 14:27, Pavel Stehule wrote:
>
>
> 2017-01-20 17:01 GMT+01:00 Joshua D. Drake :
>>
>> On 01/17/2017 09:26 AM, Robert Haas wrote:
>>>
>>> On Fri, Jan 13, 2017 at 7:24 PM, Peter Geoghegan wrote:
MERGE isn't UPSERT, and isn't even in competition with UPSERT as a
f
2017-02-03 7:25 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> The @1 area is partially solved by psql session variables or by pgAdmin
>> scripting functionality. @2 is partially solved by GUC but without
>> possibility to set a access rights.
>>
>> I didn't found any implementation of XA variable
2017-02-03 7:34 GMT+01:00 Craig Ringer :
> On 3 February 2017 at 14:27, Pavel Stehule
> wrote:
> >
> >
> > 2017-01-20 17:01 GMT+01:00 Joshua D. Drake :
> >>
> >> On 01/17/2017 09:26 AM, Robert Haas wrote:
> >>>
> >>> On Fri, Jan 13, 2017 at 7:24 PM, Peter Geoghegan
> wrote:
>
> MERGE i
On Fri, Feb 3, 2017 at 12:57 AM, Fabien COELHO wrote:
>
> Hello Corey,
>
> Glad you like the barking. I'm happy to let the prompt issue rest for now,
>> we can always add it later.
>>
>> If we DID want it, however, I don't think it'll be hard to add a special
>> prompt (Thinking %T or %Y because
On Thu, Feb 2, 2017 at 6:14 PM, Amit Kapila wrote:
>
> /*
> + * If the index list was invalidated, we better also invalidate the index
> + * attribute list (which should automatically invalidate other attributes
> + * such as primary key and replica identity)
> + */
>
> + relation->rd_indexattr
83 matches
Mail list logo
