I reviewed the patch. Overall it looks fine to me.
One comment,
>- if (index->amcanparallel &&
>- !index_only_scan &&
>+ if ((index->amcanparallel ||
>+ index_only_scan) &&
Why do we need to check for index_only_scan in the above condition. IIUC,
index->amcanpara
On 2017/02/16 15:50, Amit Khandekar wrote:
> On 15 February 2017 at 20:26, David Fetter wrote:
>> When an UPDATE can't happen, there are often ways to hint at
>> what went wrong and how to correct it. Violating a uniqueness
>> constraint would be one example.
>>
>> When an UPDATE can't happen and
On 2017/02/16 2:08, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera
> wrote:
>> I think new-style partitioning is supposed to consider each partition as
>> an implementation detail of the table; the fact that you can manipulate
>> partitions separately does not really mean th
On 15 February 2017 at 20:26, David Fetter wrote:
> When an UPDATE can't happen, there are often ways to hint at
> what went wrong and how to correct it. Violating a uniqueness
> constraint would be one example.
>
> When an UPDATE can't happen and the depth of the subtree is a
> plausible candida
On Wed, Feb 15, 2017 at 9:17 PM, Peter Eisentraut
wrote:
>> Clearly when you upgrade your system from (say) Debian 8 to Debian 9
>> and the ICU major version changes we expect to have to REINDEX, but
>> does anyone know if such data changes are ever pulled into the minor
>> version package upgrade
On 15 February 2017 at 18:40, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 4:43 AM, Amit Khandekar
> wrote:
>>> On 14 February 2017 at 22:35, Robert Haas wrote:
For example, suppose that I have a scan of two children, one
of which has parallel_workers of 4, and the other of which has
On Wed, Feb 15, 2017 at 9:17 PM, Peter Eisentraut
wrote:
> I have changed it to use ucol_nextSortKeyPart() when appropriate.
I think it would be fine if the second last argument was
"sizeof(Datum)", not "Min(sizeof(Datum), sss->buflen2)" here:
> + if (GetDatabaseEncoding() == PG_UT
"Karl O. Pinc" writes:
> On a different topic, I pulled from master and now
> I see that git finds the following untracked:
> src/bin/pg_basebackup/pg_receivexlog
> src/bin/pg_resetxlog/
> src/bin/pg_xlogdump/
Those got renamed, cf
https://git.postgresql.org/gitweb/?p=postgresql
On Wed, 15 Feb 2017 15:23:00 -0500
Robert Haas wrote:
> +ereport(WARNING,
> +(errcode(ERRCODE_INTERNAL_ERROR),
> + errmsg("corrupted data found in \"%s\"",
> +LOG_METAINFO_DATAFILE)));
>
> elog seems fine here. Ther
Joel Jacobson writes:
> Case Preservation + Case Insensitivity = A good combination
> Thoughts?
Have you read any of our innumerable previous discussions about this?
The last one was barely a month ago, cf
https://www.postgresql.org/message-id/flat/ACF85C502E55A143AB9F4ECFE960660A17282D%40mailser
Andres Freund writes:
> On 2017-02-15 22:46:38 -0300, Alvaro Herrera wrote:
>> Now that we've renamed "xlog" to "wal" in user-facing elements, I think
>> we should strive to use the name "wal" internally too in new code, not
>> "xlog" anymore. This patch introduces several variables, macros,
>> f
Simon Riggs wrote:
> Please persuade us with measurements that allowing this impact on
> ANALYZE would really improve performance at least in your case, and
> also examine the effect of this on the accuracy and usefulness of the
> gathered statistics.
I explain results of the test that Haribabu m
On 1/31/17 16:59, Thomas Munro wrote:
> I assume (but haven't checked) that ucol_nextSortKeyPart accesses only
> the start of the string via the UCharIterator passed in, unless you
> have the rare reverse-accent-sort feature enabled (maybe used only in
> fr_CA, it looks like it is required to scan
Hi hackers,
"A system that is not case-preserving is necessarily case-insensitive,
but it is possible and common for a system to be case-insensitive, yet
case-preserving" [1]
Imagine if you could turn on a GUC that would turn PostgreSQL into
such a system,
where the case would be preserved by def
On Wed, Feb 15, 2017 at 6:40 PM, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 4:43 AM, Amit Khandekar
> wrote:
>>> On 14 February 2017 at 22:35, Robert Haas wrote:
For example, suppose that I have a scan of two children, one
of which has parallel_workers of 4, and the other of which h
On Wed, Feb 15, 2017 at 8:28 PM, Heikki Linnakangas wrote:
> Ah, found it. It was because of this change:
>
> Having two error codes with the same SQLSTATE is not cool, and tripped the
> assertion in PL/python. I removed the new error code, it was only used in
> one place, and ERRCODE_PROTOCOL_VIO
On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas wrote:
>> On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila
>> wrote:>
>>> support related patch. In anycase, to avoid confusion I am attaching
>>> all the three patches with this e-mail.
>>
>> Commi
Hi,
Just to summarize what you could read between the lines in the previous
mail: From a higher level POV the design here makes sense to me, I do
however think there's a good chunk of code-level improvements needed.
Regards,
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Thu, Feb 16, 2017 at 7:52 AM, Petr Jelinek
wrote:
> On 15/02/17 06:43, Masahiko Sawada wrote:
>> On Tue, Feb 14, 2017 at 1:13 AM, Fujii Masao wrote:
>>> On Mon, Feb 13, 2017 at 4:05 PM, Masahiko Sawada
>>> wrote:
On Sat, Feb 11, 2017 at 8:18 PM, Petr Jelinek
wrote:
> On 10/02/
Hi,
On 2017-02-13 23:57:00 +1300, Thomas Munro wrote:
> Here's a new version to fix the problems reported by Rafia above. The
> patch descriptions are as before but it starts from 0002 because 0001
> was committed as 7c5d8c16 (thanks, Andres).
FWIW, I'd appreciate if you'd added a short commit m
On Thu, Feb 16, 2017 at 10:48 AM, Haribabu Kommi
wrote:
> Because of the above reason, we need a new API or some change in API
> to provide the Oldest xmin by ignoring the ANALYZE transactions, so that
> it will reduce the size of WOS and improves the VCI query performance.
A new API in core is n
On Sat, Feb 4, 2017 at 2:45 PM, Peter Geoghegan wrote:
> It might just have been that the table was too small to be an
> effective target for parallel sequential scan with so many workers,
> and so a presorted best case CREATE INDEX, which isn't that different,
> also fails to see much benefit (co
On Thu, Feb 16, 2017 at 1:08 AM, Robert Haas wrote:
> Great, thanks! This looks good to me, so committed.
Thanks.
> Is there any
> chance you can use your amazing TAP-test-creation powers to do some
> automated testing of this feature? For example, maybe we could at
> least set up a master and
On 2017-02-15 22:46:38 -0300, Alvaro Herrera wrote:
> Now that we've renamed "xlog" to "wal" in user-facing elements, I think
> we should strive to use the name "wal" internally too in new code, not
> "xlog" anymore. This patch introduces several variables, macros,
> functions that ought to change
On Wed, Feb 15, 2017 at 11:35 PM, Amit Kapila
wrote:
> On Wed, Feb 15, 2017 at 12:03 PM, Seki, Eiji
> wrote:
> > Amit Kapila wrote:
> >> How will you decide just based on oldest xmin whether the tuple is
> visible or not? How will you take decisions about tuples which have xmax
> set?
> >
> > I
On Wed, Feb 15, 2017 at 8:46 PM, Alvaro Herrera
wrote:
> Now that we've renamed "xlog" to "wal" in user-facing elements, I think
> we should strive to use the name "wal" internally too in new code, not
> "xlog" anymore. This patch introduces several variables, macros,
> functions that ought to ch
On 2017/02/15 13:31, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 5:57 AM, Amit Langote
> wrote:
>> On 2017/02/13 14:21, Amit Langote wrote:
>>> On 2017/02/10 19:19, Simon Riggs wrote:
* The OID inheritance needs work - you shouldn't need to specify a
partition needs OIDS if the parent h
Now that we've renamed "xlog" to "wal" in user-facing elements, I think
we should strive to use the name "wal" internally too in new code, not
"xlog" anymore. This patch introduces several variables, macros,
functions that ought to change names now -- XLogSegmentOffset should be
WALSegmentOffset f
On Mon, Feb 13, 2017 at 10:22 AM, Amit Kapila wrote:
> As discussed, attached are refactoring patches and a patch to enable
> WAL for the hash index on top of them.
Thanks. I think that the refactoring patches shouldn't add
START_CRIT_SECTION() and END_CRIT_SECTION() calls; let's leave that
for
On 2017-02-15 20:35:16 -0500, Stephen Frost wrote:
> Perhaps, but until we've got a system worked out for having the workers
> do the writes, we aren't getting anything. Being able to have the
> leader do the writes based on the tuples fed back from the workers is
> clearly better than nothing.
N
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-02-15 20:28:43 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On February 15, 2017 5:20:20 PM PST, Stephen Frost
> > > wrote:
> > > >In many cases, I expect this would work just as well, if not bette
On 2017-02-15 20:28:43 -0500, Stephen Frost wrote:
> Andres,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > On February 15, 2017 5:20:20 PM PST, Stephen Frost
> > wrote:
> > >In many cases, I expect this would work just as well, if not better,
> > >than trying to actually do writes in paral
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On February 15, 2017 5:20:20 PM PST, Stephen Frost wrote:
> >In many cases, I expect this would work just as well, if not better,
> >than trying to actually do writes in parallel.
>
> Why? IPCing tuples around is quite expensive. Or do you m
On February 15, 2017 5:20:20 PM PST, Stephen Frost wrote:
>In many cases, I expect this would work just as well, if not better,
>than trying to actually do writes in parallel.
Why? IPCing tuples around is quite expensive. Or do you mean because it'll be
more suitable because of the possible p
All,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-02-15 08:48:44 -0500, Robert Haas wrote:
> > The other way of fixing this problem is to have each worker generate a
> > subset of the tuples and funnel them all back to the leader through a
> > Gather node; the leader then does all the ins
Hi,
On 2017-02-15 08:48:44 -0500, Robert Haas wrote:
> We got rid of the major existing use of page locks in
> 6d46f4783efe457f74816a75173eb23ed8930020, which extirpated them from
> hash indexes, and I was kind of hoping they could go away altogether,
> but we can't do that as long as GIN is using
On Thu, Feb 16, 2017 at 12:48 AM, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 12:24 AM, Joshua Chamberlain
> wrote:
> > Hello,
> >
> > (I'm posting to hackers since I got no response on the general list.)
> >
> > I use Postgres + PostGIS quite heavily, and recently have been taking
> full
> > a
On 2017/02/15 2:37, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 2:30 AM, Amit Langote
> wrote:
>> I noticed that running ALTER TABLE table_name DETACH PARTITION crashes, if
>> table_name is not a partitioned table. That's because of an Assert in
>> ATExecDetachPartition(). We really should err
Andres Freund writes:
> On 2017-02-15 18:30:30 -0500, Tom Lane wrote:
>> If we tried to lock that down it'd be counterproductive for the reason
>> Andres mentions: sometimes you *want* to see what you get for other
>> settings.
> We could kinda address that by doing it in a separate file early in
On 13/02/17 14:51, Erik Rijkers wrote:
> On 2017-02-11 11:16, Erik Rijkers wrote:
>> On 2017-02-08 23:25, Petr Jelinek wrote:
>>
>>> 0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
>>> 0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
>>> 0003-Fix-after-trigger-executio
On 2017-02-15 18:30:30 -0500, Tom Lane wrote:
> If we tried to lock that down it'd be counterproductive for the reason
> Andres mentions: sometimes you *want* to see what you get for other
> settings.
We could kinda address that by doing it in a separate file early in the
schedule, which could jus
Andres Freund writes:
> On 2017-02-15 09:30:39 -0800, Jeff Janes wrote:
>> I don't really see the cost here.
> Because that means we essentially need to make sure that our tests pass
> with a combination of about ~20-30 behaviour changing gucs, and ~5
> different compilation settings that change
Out of archeological curiosity, I was digging around in the hash join
code and RCS history from Postgres 4.2[1], and I was astounded to
discover that it had a parallel executor for Sequent SMP systems and
was capable of parallel hash joins as of 1991. At first glance, it
seems to follow approximat
On Tue, Feb 14, 2017 at 9:06 AM, Magnus Hagander
wrote:
Yeah, that's my view as well. I'm all for including it in verbose mode.
>
> *Iff* we can get a progress indicator through the checkpoint we could
> include that in --progress mode. But that's a different patch, of course,
> but it shouldn't
Hi,
On 2017-02-15 09:30:39 -0800, Jeff Janes wrote:
> On Tue, Feb 14, 2017 at 9:17 PM, Andres Freund wrote:
> > What's your reason to get this fixed?
> >
>
> More testing is better than less testing, and a good way to get less
> testing is requiring the tester to memorize a list of false positiv
On 14/02/17 03:23, Kyotaro HORIGUCHI wrote:
> At Sat, 4 Feb 2017 21:27:32 +0100, Petr Jelinek
> wrote in
>
>> Hmm I wonder if we should just make the subscriber send the
>> client_encoding always (based on server encoding of the subscriber).
>> That should solve the issue in combination with yo
On 15/02/17 06:43, Masahiko Sawada wrote:
> On Tue, Feb 14, 2017 at 1:13 AM, Fujii Masao wrote:
>> On Mon, Feb 13, 2017 at 4:05 PM, Masahiko Sawada
>> wrote:
>>> On Sat, Feb 11, 2017 at 8:18 PM, Petr Jelinek
>>> wrote:
On 10/02/17 19:55, Masahiko Sawada wrote:
> On Thu, Feb 9, 2017 at
Agreed with Jeff, false alarms should be avoided, whenever it is easy to
put the avoiding mechanism in place.
Regards,
Neha
Andres Freund writes:
> On 2017-02-15 12:27:11 -0500, Robert Haas wrote:
>> I agree; also, many years ago a guy named Tom Lane told me that flags
>> argument should typically be declared as type "int". I've followed
>> that advice ever since.
> Why is that? I think uint makes a lot more sense f
"Karl O. Pinc" writes:
> On Wed, 15 Feb 2017 15:23:00 -0500
> Robert Haas wrote:
>> I think our preferred style is not to break strings across lines like
>> this.
> How do you do that and not exceed the 80 character line limit?
> Just ignore the line length limit?
Right. It depends on context,
On 2017-02-15 12:27:11 -0500, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 1:38 PM, Jim Nasby wrote:
> > On 2/14/17 3:13 AM, Seki, Eiji wrote:
> >> +extern TransactionId GetOldestXmin(Relation rel, uint8 ignoreFlags);
> >
> >
> > My impression is that most other places that do this sort of thing
Thomas Munro writes:
> On Wed, Feb 15, 2017 at 2:22 PM, Tom Lane wrote:
>> Adding a C.F.I. inside this loop is the most straightforward fix, but
>> I am leaning towards adding one in ExecHashJoinGetSavedTuple instead,
> Would it also make sense to put one in the loop in
> ExecHashIncreaseNumBatc
Robert Haas wrote:
> On Fri, Jan 20, 2017 at 2:09 AM, Michael Paquier
> wrote:
> > Okay I just did it. At the same time the check for ferror is not
> > necessary as fgets() returns NULL on an error as well so that's dead
> > code. I have also removed the useless call to FreeFile().
>
> diff --git
On Wed, 15 Feb 2017 15:23:00 -0500
Robert Haas wrote:
> + errhint("The supported log formats are
> \"stderr\""
> +" and \"csvlog\".")));
>
> I think our preferred style is not to break strings across lines like
> this.
How do you do that a
On Wed, Feb 15, 2017 at 12:24 PM, Robert Haas wrote:
> On Tue, Jan 24, 2017 at 4:32 AM, Peter Moser wrote:
> >> Using common terms such as ALIGN and NORMALIZE for such a specific
> >> functionality seems a bit wrong.
> >
> > Would ALIGN RANGES/RANGE ALIGN and NORMALIZE RANGES/RANGE NORMALIZE be
On Wed, Feb 15, 2017 at 11:47 AM, Tom Lane wrote:
> I wrote:
> > We could possibly prevent the difference by having exprLocation look
> > through such nodes. I'm not sure offhand if there are cases where
> > that would be worse than before. We've definitely made some other
> > hacks to hide the
On Fri, Jan 20, 2017 at 2:09 AM, Michael Paquier
wrote:
> Okay I just did it. At the same time the check for ferror is not
> necessary as fgets() returns NULL on an error as well so that's dead
> code. I have also removed the useless call to FreeFile().
diff --git a/src/backend/postmaster/postmas
On Wed, Feb 15, 2017 at 9:52 AM, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 11:45 PM, Tom Lane wrote:
>> You could perhaps make an argument that sum(float4) would have less risk
>> of overflow if it accumulated in and returned float8, but frankly that
>> seems a bit thin.
>
> I think that's mor
I wrote:
> We could possibly prevent the difference by having exprLocation look
> through such nodes. I'm not sure offhand if there are cases where
> that would be worse than before. We've definitely made some other
> hacks to hide the difference between operator_precedence_warning on
> and off.
On Wed, Feb 15, 2017 at 2:15 PM, Andres Freund wrote:
> I don't think that's true for several reasons. Separating out PGXACT
> didn't just mean reducing the stride size of the access / preventing
> sharing. It also meant that frequently changing fields in PGPROC aren't
> on the same cache-line as
> attcacheoff can only be set positive for fields preceding any varlena
> (typlen<0, but including the first such) or nullable values. I don't
> know how much faster it is with the cache; you can measure it if your
> curiosity is strong enough -- just set the first column to nullable.
>
>
Thanks!
On Thu, Jan 19, 2017 at 7:07 AM, Rafia Sabih
wrote:
> Please find the attached file rebased patch of parallel index-only
> scan on the latest Parallel index-scan patch [1].
This again needs minor rebasing but basically looks fine. It's a
pretty straightforward extension of the parallel index sca
On Tue, Jan 24, 2017 at 4:32 AM, Peter Moser wrote:
>> Using common terms such as ALIGN and NORMALIZE for such a specific
>> functionality seems a bit wrong.
>
> Would ALIGN RANGES/RANGE ALIGN and NORMALIZE RANGES/RANGE NORMALIZE be better
> options? We are also thankful for any suggestion or comm
Hi,
On 2017-02-15 12:24:44 -0500, Robert Haas wrote:
> If you pad PGXACT out to one cache line, you could likewise take a
> snapshot by touching 1 cache line per backend, and they'd be
> consecutive. Maybe that difference matters to the memory prefetching
> controller, I dunno,
Unfortunately it'
Hi,
On 2017-02-15 11:43:17 -0500, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 11:07 AM, Alvaro Herrera
> wrote:
> > It seems to me that Andres comments here were largely ignored:
> > https://www.postgresql.org/message-id/20160822021747.u5bqx2xwwjzac...@alap3.anarazel.de
> > He was suggesting to
On Tue, Jan 24, 2017 at 4:32 AM, Peter Moser wrote:
> NORMALIZE: splits all the ranges of one relation according to all the range
> boundaries of another (but possibly the same) relation whenever some equality
> condition over some given attributes is satisfied.
>
> When the two relations are the
On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila wrote:>
>> support related patch. In anycase, to avoid confusion I am attaching
>> all the three patches with this e-mail.
>
> Committed guc_parallel_index_scan_v1.patch, with changes to the
> docu
On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila wrote:>
> support related patch. In anycase, to avoid confusion I am attaching
> all the three patches with this e-mail.
Committed guc_parallel_index_scan_v1.patch, with changes to the
documentation and GUC descriptions.
--
Robert Haas
EnterpriseDB:
Ryan Murphy wrote:
> My question kind of remains though - does that mean that having any nulls
> in the tuple loses the ability to use the tupleDesc cache? and how much of
> a performance impact is this? I'm sure there's a good reason why you can't
> really use the cache if you have a null column
Jim Nasby wrote:
> ISTR previous discussion of allowing more stats files; if that happened
> I think having stats that were dedicated to (auto)vacuum would be very
> useful. That's clearly a lot more work though.
What?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Dev
On Wed, Feb 15, 2017 at 12:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... Maybe that difference matters to the memory prefetching
>> controller, I dunno, but it seems funny that we did the PGXACT work to
>> reduce the number of cache lines that had to be touched in order to
>> take a snapsho
Magnus Hagander wrote:
> printf(_(" -R, --write-recovery-conf\n"
> - " write recovery.conf after
> backup\n"));
> + " write recovery.conf for
> replication\n"));
> printf(_(" -S, --slot=SLOTNA
13.02.2017 19:34, Andrew Dunstan:
On 01/13/2017 08:36 AM, Anastasia Lubennikova wrote:
I implemented IF NOT EXISTS option for CREATE SERVER and CREATE USER
MAPPING statements
for one of our customers.
I think other users can also find it useful for scripting and
automated tasks.
The patches the
Alexander Korotkov wrote:
> Difference between master, pgxact-align-2 and pgxact-align-3 doesn't exceed
> per run variation.
FWIW this would be more visible if you added error bars to each data
point. Should be simple enough in gnuplot ...
--
Álvaro Herrerahttps://www.2ndQuadra
Robert Haas writes:
> ... Maybe that difference matters to the memory prefetching
> controller, I dunno, but it seems funny that we did the PGXACT work to
> reduce the number of cache lines that had to be touched in order to
> take a snapshot to improve performance, and now we're talking about
> i
Robert Haas writes:
> I think that's more or less the argument Konstantin is in fact making.
> Whether it's a good argument or a thin one is a value judgement.
> Personally, I find it somewhere in the middle: I think the way it
> works now is reasonable, and I think what he wants would have been
>
On Tue, Feb 14, 2017 at 9:17 PM, Andres Freund wrote:
>
>
> On February 14, 2017 9:02:14 PM PST, neha khatri
> wrote:
> >On Wed, Feb 15, 2017 at 10:04 AM, neha khatri
> > wrote:.
> >>
> >>
> >>> Attached are two options for doing that. One overrides bytea_output
> >>> locally where-ever needed
On Tue, Feb 14, 2017 at 1:38 PM, Jim Nasby wrote:
> On 2/14/17 3:13 AM, Seki, Eiji wrote:
>> +extern TransactionId GetOldestXmin(Relation rel, uint8 ignoreFlags);
>
>
> My impression is that most other places that do this sort of thing just call
> the argument 'flags', so as not to "lock in" a s
> No, that tests whether the particular tuple contains any null fields, not
> whether the whole table is declared NOT NULL.
>
> regards, tom lane
>
Ok, thanks, that makes sense.
My question kind of remains though - does that mean that having any nulls
in the tuple loses th
On Wed, Feb 15, 2017 at 12:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 13, 2017 at 11:07 AM, Alvaro Herrera
>> wrote:
>>> It seems to me that Andres comments here were largely ignored:
>>> https://www.postgresql.org/message-id/20160822021747.u5bqx2xwwjzac...@alap3.anarazel.de
>>>
Ryan Murphy writes:
> My question is this: HeapTupleNoNulls() is run first to see if there are
> any columns that can be NULL. It looks like the fetchatt() that uses the
> cache in the tupleDesc can only be used if there are no NULLable columns in
> the table. Is my understanding correct?
No,
On Wed, Feb 15, 2017 at 10:40 AM, David Christensen wrote:
> Fixes some DESCR() grammar mistakes introduced by the xlog -> wal changes.
Thanks, David!
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
Robert Haas writes:
> On Mon, Feb 13, 2017 at 11:07 AM, Alvaro Herrera
> wrote:
>> It seems to me that Andres comments here were largely ignored:
>> https://www.postgresql.org/message-id/20160822021747.u5bqx2xwwjzac...@alap3.anarazel.de
>> He was suggesting to increase the struct size to 16 bytes
Alvaro Herrera writes:
> Robert Haas wrote:
>> True. I think the question here is: do we want to view the dependency
>> between a partitioned table and a partition of that table as
>> DEPENDENCY_NORMAL or as DEPENDENCY_AUTO? With table inheritance, it's
>> always been "normal" and I'm not sure t
On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut
wrote:
> If RegisterBackgroundWorker() (the non-dynamic kind that is only
> loadable from shared_preload_libraries) fails to register the worker, it
> writes a log message and proceeds, ignoring the registration request. I
> think that is a mista
On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera
wrote:
> I think new-style partitioning is supposed to consider each partition as
> an implementation detail of the table; the fact that you can manipulate
> partitions separately does not really mean that they are their own
> independent object. Y
The current help text for pg_basebackup -R is "write recovery.conf after
backup".
This says nothing about what it actually does. I've had a number of people
ask me now why that's not default "because you need a recovery.conf to
restore from backup". The point being that it doesn't say anything abo
On Mon, Feb 13, 2017 at 11:07 AM, Alvaro Herrera
wrote:
> It seems to me that Andres comments here were largely ignored:
> https://www.postgresql.org/message-id/20160822021747.u5bqx2xwwjzac...@alap3.anarazel.de
> He was suggesting to increase the struct size to 16 bytes rather than
> going all the
Hi all,
I was looking through some of the implementation details of the
heap/tuples, specifically src/include/access/htup_details.h - and I came
across the big macro fastgetattr, and had a question about it. I've
included the code here for clarity and convenience:
#define fastgetattr(tup, at
Robert Haas wrote:
> On Wed, Feb 15, 2017 at 9:37 AM, Alvaro Herrera
> wrote:
> > Joshua D. Drake wrote:
> >> Because partitions may have data.
> >
> > So would the table, were it not partitioned.
>
> True. I think the question here is: do we want to view the dependency
> between a partitioned
If RegisterBackgroundWorker() (the non-dynamic kind that is only
loadable from shared_preload_libraries) fails to register the worker, it
writes a log message and proceeds, ignoring the registration request. I
think that is a mistake, it should be a hard error. The only way in
practice to fix the
On Wed, Feb 15, 2017 at 7:17 AM, Dilip Kumar wrote:
> This is easily doable and it will look much cleaner. While doing this
> I am facing one problem related to
> relptr_store and relptr_access. The problem is that when I call
> "relptr_store (base, rp, val)" with both base and val as a same
> ad
On Wed, Feb 15, 2017 at 11:19 AM, Peter Eisentraut
wrote:
> On 1/11/17 5:51 PM, David Rowley wrote:
>> Now, since background workers
>> don't consume anything from max_connections, then I don't really feel
>> that a background worker should count towards "CONNECTION LIMIT". I'd
>> assume any CONNE
On 1/11/17 5:51 PM, David Rowley wrote:
> Now, since background workers
> don't consume anything from max_connections, then I don't really feel
> that a background worker should count towards "CONNECTION LIMIT". I'd
> assume any CONNECTION LIMITs that are set for a user would be
> calculated based
On Wed, Feb 15, 2017 at 2:14 AM, Michael Paquier
wrote:
> This is a collection of checks on relkind == RELKIND_PARTITIONED_TABLE
> to avoid interactions with partition tables. Did you consider doing
> something in the executor instead?
That seems inferior, because the planner really ought to know
On Wed, Feb 15, 2017 at 1:31 AM, Michael Paquier
wrote:
> On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas wrote:
>> I think the patch as presented probably isn't quite what we want,
>> because it waits synchronously for the second result to be ready.
>> Note that the wait for the first result is as
On 2/14/17 11:49 AM, Magnus Hagander wrote:
> +
> +If systemd is in use, some care must be
> taken
> +that IPC resources (shared memory and semaphores) are not prematurely
> +removed by the operating system. This is especially of concern when
> +installing PostgreSQL from source
On Tue, Feb 14, 2017 at 11:36 PM, Michael Paquier
wrote:
> On Wed, Feb 15, 2017 at 2:38 AM, Robert Haas wrote:
>> On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier
>> wrote:
>>> In short, I'd like to think that we should just filter out those two
>>> parameters by name and call it a day. Or introd
On Tue, Feb 14, 2017 at 1:13 PM, Jim Nasby wrote:
> After seeing Yet Another Missing Psql Tab Completion it occurred to me...
> why not add a checklist item to the commitfest review page? I realize most
> regular contributors don't use the form, but a fair number of people do. I
> don't see how it
On Wed, Feb 15, 2017 at 9:10 AM, Simon Riggs wrote:
>>> * "ERROR: cannot create index on partitioned table
>>> "measurement_year_month""
>>> is misleading because you can create indexes on partitions
>>
>> Do you mean that this should not cause an error at all, but create the
>> specified index
1 - 100 of 136 matches
Mail list logo
