>
> BTW, after experimenting with this, I did not find any way to get perltidy
> to overwrite the original files without making a backup file.
Yep, that's why --backup-and-modify-in-place had to be used. I have a
local script to remove file with specified extentions, but didn't
document that
On Fri, Aug 19, 2016 at 09:22:32AM -0700, Jeff Janes wrote:
> On Sat, Jul 30, 2016 at 11:18 AM, Bruce Momjian <br...@momjian.us> wrote:
>
> On Fri, Jul 29, 2016 at 11:27:06AM -0400, Peter Eisentraut wrote:
> > On 7/29/16 11:13 AM, Bruce Momjian wrote:
>
k-branches so we can backpatch things. The ideal time would probably
be right after we have done minor releases. The problem is that this is
going to break queued-up patches, so maybe it has to be done right
before 10.0 beta, and again, to all back branches too.
--
Bruce Momjian <br...@momjian.us&
On Thu, Aug 18, 2016 at 04:49:04PM -0400, Bruce Momjian wrote:
> On Thu, Aug 18, 2016 at 03:01:48PM -0400, Peter Eisentraut wrote:
> > On 8/18/16 1:59 PM, Bruce Momjian wrote:
> > > o compares words in columns that can only support keywords as
> > > case
On Sat, Aug 20, 2016 at 01:43:42PM +0900, Michael Paquier wrote:
> On Sat, Aug 20, 2016 at 1:39 PM, Bruce Momjian <br...@momjian.us> wrote:
> > Someone reported that a replication slot that existed at the time a base
> > backup was done on the master was copied to
Someone reported that a replication slot that existed at the time a base
backup was done on the master was copied to the standby. Because they
didn't realize it, their WAL was not being recycled on the standby.
Is that possible? Is it a known behavior? I don't see it documented.
--
Bruce
/Todo
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Sent via pgsql-hackers mailing list
On Thu, Aug 18, 2016 at 03:01:48PM -0400, Peter Eisentraut wrote:
> On 8/18/16 1:59 PM, Bruce Momjian wrote:
> > o compares words in columns that can only support keywords as
> > case-insensitive, double-quoted or not
> >
> > o compares words in columns tha
On Thu, Aug 18, 2016 at 02:06:39PM -0400, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > I was looking at this TODO item from 2009:
> > https://www.postgresql.org/message-id/4AA7B197.70002%40usit.uio.no
> > I have implemented this in the attached
d in PG 10 as:
local "Test" all trust
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
t concurrent transactions
> committed before a new statement's transaction snapshot is taken, and
> doesn't record lock order for row updates blocked by concurrent activity
> --- both of which affect the final result from the query.
I assume they can do SQL-level replication whe
On Wed, Aug 10, 2016 at 10:35:44PM -0400, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > It sounds like you are saying that the branch is to happen before the
> > pgindent run. Am I missing something?
>
> I read it as pgindent then branch.
OK, good
On Wed, Aug 10, 2016 at 10:31:35PM -0400, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > I am confused --- are you pgindenting just HEAD and not 9.6? Why?
>
> The point is to pgindent while they're still the same.
So I read this:
> >> +1, I
> > If so, it probably
> > makes sense for you to do this just beforehand.
>
> OK.
I am confused --- are you pgindenting just HEAD and not 9.6? Why?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.
n as clean a state as possible.
>
> Current results of this attached.
Sure, seems like a good idea.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are,
ot.
>
> That's one of the realities according to my experiences.
Yes. Many people are arguing for specific defaults based on what _they_
would want, not what the average user would want. Sophisticated users
will know about this and turn it on when desired.
--
Bruce Momjian <br...
On Wed, Aug 10, 2016 at 05:14:52PM +0300, Alexander Korotkov wrote:
> On Tue, Aug 9, 2016 at 5:37 AM, Bruce Momjian <br...@momjian.us> wrote:
>
> On Tue, Aug 9, 2016 at 02:06:40AM +, Tsunakawa, Takayuki wrote:
> > I hope wait event monitoring will
On Tue, Aug 9, 2016 at 06:19:57PM -0500, Jim Nasby wrote:
> On 8/8/16 3:19 PM, Bruce Momjian wrote:
> >>What will help, and something I haven't yet applied any thoughts, is when we
> >>> can turn WARM chains back to HOT by removing stale index entries.
> >
On Tue, Aug 9, 2016 at 01:58:25PM -0400, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > Does anyone know why the phrase distance "<3>" was changed from "at most
> > three tokens away" to "exactly three tokens away"?
>
I assume if you are looking for "<3>" you
would want "<2>" matches and "<1>" matches as well.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so on
ome internal tracking can be enabled by
default and some internal or external tool can be turned on and off to
get more fine-grained statistics about the event durations.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterpr
if we are not willing to
be realistic in how much performance penalty the _average_ user is
willing to lose to have this monitoring, I fear we will make little
progress on this feature.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Mon, Aug 8, 2016 at 11:47:11PM +0200, Ilya Kosmodemiansky wrote:
> On Mon, Aug 8, 2016 at 7:03 PM, Bruce Momjian <br...@momjian.us> wrote:
> > It seems asking users to run pg_test_timing before deploying to check
> > the overhead would be sufficient.
>
> I'am
cient key-ctid searches, you handle all cases, and not
> just a few common ones.
True. I am worried about page spills caused by having to insert a rows
into an existing page and and index entry having to be pushed to an
adjacent page to maintain ctid index order.
--
Bruce Momjian &
or
its limited value. What we could do is to use the LP_REDIRECT lp_len to
store information of two more changed column numbers, with directions.
However, once you store one bit that records the direction of all other
columns, you can't go back and record the changes, unless you do a c
On Sun, Aug 7, 2016 at 12:55:01PM -0400, Bruce Momjian wrote:
> On Sun, Aug 7, 2016 at 10:49:45AM -0400, Bruce Momjian wrote:
> > OK, crazy idea time --- what if we only do WARM chain additions when all
> > indexed values are increasing (with NULLs higher than all values)?
_test_timing before deploying to check
the overhead would be sufficient.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave
ut each time traversing the WARM chain would be an additional
> effort. For cases, where there are just two index entries and one
> them is being updated, it might regress as compare to what we do now.
Yes, I think the all-increment or all-decrement WARM chain is going to
be the right appr
On Sun, Aug 7, 2016 at 10:49:45AM -0400, Bruce Momjian wrote:
> OK, crazy idea time --- what if we only do WARM chain additions when all
> indexed values are increasing (with NULLs higher than all values)? (If
> a key is always-increasing, it can't match a previous value in th
On Sat, Aug 6, 2016 at 10:51:21AM -0400, Bruce Momjian wrote:
> > If we need to find an efficient way to convert WARM chains back to HOT,
> > which
> > will happen soon when the old index tuple retires, the system can attain a
> > stable state, not for all but many use
On Sat, Aug 6, 2016 at 04:04:41PM +0100, Andrew Gierth wrote:
> >>>>> "Bruce" == Bruce Momjian <br...@momjian.us> writes:
>
> Bruce> Would it be helpful to output an array of strings representing
> Bruce> the index definition?
>
On Sat, Aug 6, 2016 at 01:00:15PM +0100, Andrew Gierth wrote:
> >>>>> "Bruce" == Bruce Momjian <br...@momjian.us> writes:
>
> >> As far as I understood Andrew's use case, he was specifically *not*
> >> interested in a complete repres
ns back to HOT, which
> will happen soon when the old index tuple retires, the system can attain a
> stable state, not for all but many use cases.
I don't see how that is possible, except perhaps by vacuum.
OK, now I am less certain.
--
Bruce Momjian <br.
On Fri, Aug 5, 2016 at 09:40:35PM -0400, Bruce Momjian wrote:
> So to summarize again:
>
> o chains start out as HOT
> o they become WARM when some indexes change and others don't
> o for multiple index changes, we have to check all indexes
>for key/ctid matches
>
On Fri, Aug 5, 2016 at 09:02:39PM -0400, Bruce Momjian wrote:
> Yes, it seems we either find the entry fast and avoid the index
> addition, or don't find it quickly and use a non-HOT, non-WARM update.
> The problem is that you have to do this for multiple indexes, and if you
> quic
On Fri, Aug 5, 2016 at 09:21:49PM -0300, Claudio Freire wrote:
> On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian <br...@momjian.us> wrote:
> > On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote:
> >> > This does create more HOT chains where the
--- I can't see how this would be a win over
doing the index check on writes.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
On Fri, Aug 5, 2016 at 03:26:15PM -0400, Bruce Momjian wrote:
> > I just don't know how would you do that without delaying/not-doing HOT chain
> > prune. As soon as root and intermediate HOT tuples are gone, all
> > information is
> > lost. You may delay that, but th
On Fri, Aug 5, 2016 at 11:30:26PM +0530, Pavan Deolasee wrote:
> On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian <br...@momjian.us> wrote:
>
> On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote:
> > But doing the WARM chain backtracking and
On Fri, Aug 5, 2016 at 02:07:18PM -0400, Robert Haas wrote:
> On Fri, Aug 5, 2016 at 11:06 AM, Bruce Momjian <br...@momjian.us> wrote:
> > On Fri, Aug 5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote:
> >> On 8/2/16 12:51 PM, Bruce Momjian wrote:
> >> > Yes
performance on the average case.
Yes, that was an idea I had to --- if the in-page HOT chain already has
the key, we know it is already in the index and we can skip the index
addition.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http:
ou point to in a HOT chain, the fewer ctids you can
remove --- that's why we want to point only to the head of the HOT/WARM
chain.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I.
On Fri, Aug 5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote:
> On 8/2/16 12:51 PM, Bruce Momjian wrote:
> > Yes, that's a strong argument for using a space. I have adjusted the
> > patch to use spaces in all reasonable places. Patch attached, which I
> > have gzipped
>
> + The default is off on Windows
> + because the overhead is significant, and on on other platforms.
I think "on on" is odd. I think you want "and on for other platforms."
--
Bruce Momjian <br...@momjian.us>http://momjian.us
En
what we have
> currently.
I don't see why it is hard. Trying to find the index entry for the old
update row seems odd, and updating an index row seems odd, but skipping
an index addition for the new row seems simple. Is the problem
concurrent activity? I assumed already h
visible rows. #2 doesn't match the value in
the WHERE clause, so we don't even check the heap. The scan of #3
returns one row.
Remember, we don't scan past the end of the HOT chain, which is what we
do now.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
averse the
HOT chain on a single page just fine with no complaints about speed so I
don't see a value to optimizing that traversal, and I think the key
rechecks and ctid bloat will make it all much slower.
It also seems much more complicated.
--
Bruce Momjian <br...@momjian.us>
>On Thu, Aug 4, 2016 at 06:21:48PM -0400, Bruce Momjian wrote:
> Another approach would be to keep updates on the same page in a single
> WARM chain, even if all indexes have changed columns. We will already
> have code to walk the HOT chain looking for matches, and at most
ver possible and desired.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Sent via pgs
multiple update chains on the same page for
different rows with identical indexed values, so I don't see how
checking just for the page number helps here. Are we going to check the
entire page?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
; I know. I just mentioned it just in case there was a transient time
> during cleanup when it isn't true, but thinking it a little bit more,
> if it weren't, HOT would also cause duplicates during index scans, so
> it's probably not the case (or protected with a lock).
I am looking for clarifica
code needs to check the index's root HOT tid for a
non-match.
> This is maintained by:
>
> * No item pointer will be created for row versions whose immediately
> previous version is already on the index with the same key
You really only have the ctid HOT head stored in the
On Thu, Aug 4, 2016 at 01:05:53PM -0400, Bruce Momjian wrote:
> > Approach 2 seems more reasonable and simple.
> >
> > There are only 2 bits for lp_flags and all combinations are already used.
> > But
> > for LP_REDIRECT root line pointer, we could
s to replace it with a
> LP_REDIRECT line pointer, the information is moved to lp_len (which is
> currently set to 0 for LP_REDIRECT items). Does that answer your question?
Ah, brilliant!
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://en
; work. I'll dig up the details, some problem in VACUUM, IIRC.
I think the problem is that HOT chain pruning becomes almost impossible
except via VACUUM.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Thu, Aug 4, 2016 at 06:03:34PM +0100, Simon Riggs wrote:
> On 4 August 2016 at 02:13, Bruce Momjian <br...@momjian.us> wrote:
>
> > How do plan to clear the bitmask so it, over time, doesn't end up being
> > all-set?
>
> I don't have a plan, though thoughts w
On Thu, Aug 4, 2016 at 06:16:02PM +0100, Simon Riggs wrote:
> On 4 August 2016 at 18:05, Bruce Momjian <br...@momjian.us> wrote:
>
> >> Approach 2 seems more reasonable and simple.
> >>
> >> There are only 2 bits for lp_flags and all combinations are alrea
On Thu, Aug 4, 2016 at 09:58:29AM -0700, Andres Freund wrote:
> On 2016-08-04 12:55:25 -0400, Bruce Momjian wrote:
> > On Thu, Aug 4, 2016 at 09:31:18AM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wr
On Thu, Aug 4, 2016 at 09:58:29AM -0700, Andres Freund wrote:
> On 2016-08-04 12:55:25 -0400, Bruce Momjian wrote:
> > On Thu, Aug 4, 2016 at 09:31:18AM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wr
f line pointer flag with that WAL record.
>
> Flag clearing need not be WAL logged, unless we can piggyback that to some
> existing WAL logging.
Agreed, good point.
Very nice!
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
rt way to
> figure that out?
The index points to the head of the HOT chain, and you just walk the
chain on the page --- on need to look at other chains on the page.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.c
On Wed, Aug 3, 2016 at 08:34:02PM -0400, Bruce Momjian wrote:
> On Thu, Aug 4, 2016 at 01:16:20AM +0100, Simon Riggs wrote:
> > > Would you only add a LITE index entry when there isn't an
> > > existing index entry for the same values and heap page? That seems
&g
https://www.postgresql.org/message-id/2b833706-1133-1e11-39d9-4fa228892...@2ndquadrant.com
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
just means it matches the existing
range. I was unclear that was the entire page.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
On Thu, Aug 4, 2016 at 01:16:20AM +0100, Simon Riggs wrote:
> On 4 August 2016 at 00:56, Bruce Momjian <br...@momjian.us> wrote:
> > On Wed, Aug 3, 2016 at 07:28:52PM -0400, Bruce Momjian wrote:
> >> With LITE, you can avoid the creation of duplicate-value index entries
On Wed, Aug 3, 2016 at 07:28:52PM -0400, Bruce Momjian wrote:
> With LITE, you can avoid the creation of duplicate-value index entries
> for indexes without changed column values by using a bitmap in place of
> the tid item number (16 bits). It can't remove dead tids.
How would y
On Wed, Aug 3, 2016 at 10:02:39AM -0400, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > On Sun, Jul 31, 2016 at 05:57:12PM -0400, Tom Lane wrote:
> >> In hindsight it seems clear that what a lot of apps want out of extended
> >> protocol is o
r
sequentially-grouped values to be useful? It kind of feels like a
single-page BRIN index.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
On Tue, Aug 2, 2016 at 01:56:27PM +0900, Amit Langote wrote:
> Attached patch fixes a minor typo in tuplesort.c
>
> s/child content/child context/g
Thanks, patch applied.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Tue, Aug 2, 2016 at 10:33:15PM -0400, Bruce Momjian wrote:
> I saw from the Uber article that they weren't going to per-row logical
> replication but _statement_ replication, which is very hard to do
> because typical SQL doesn't record what concurrent transactions
> committed
gt; parameter data types.
Do you want this on the TODO list?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grav
tion of whether the code
has bugs, but that the replay is not 100% possible in all cases, unless
you switch to some statement-row-lock hybrid ability.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://en
constructing applications.
Would it be helpful to output an array of strings representing the index
definition?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was
re there to detect problems where a 512-byte
disk sector is zeroed by a disk failure. I don't see use changing that
for the use-case you have described.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterpr
hat I did there?) :-)
I am thinking of leaving the 9.6 docs alone as I have already made them
consistent (no space) with minimal changes. We can make it consistent
the other way in PG 10.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Mon, Aug 1, 2016 at 02:48:55PM -0400, Peter Eisentraut wrote:
> On 7/30/16 2:16 PM, Bruce Momjian wrote:
> > The second patch does what Tom suggests above by outputting only "KB",
> > and it supports "kB" for backward compatibility. What it doesn't do is
&
gt; that are just as dangerous, for example ye olde unintentionally-correlated
> subselect:
> https://www.postgresql.org/message-id/20160714135233.1410.92538%40wrigleys.postgresql.org
I am hoping for a "novice" mode that issues warnings about possible
bugs, e.g. unintentionally-correlated s
On Mon, Aug 1, 2016 at 01:35:53PM +0200, Christoph Berg wrote:
> Re: Bruce Momjian 2016-07-30 <20160730181643.gd22...@momjian.us>
> > I also just applied a doc patch that increases case and spacing
> > consistency in the use of kB/MB/GB/TB.
>
> Hi,
>
> PostgreS
On Fri, Jul 29, 2016 at 11:27:06AM -0400, Peter Eisentraut wrote:
> On 7/29/16 11:13 AM, Bruce Momjian wrote:
> > Yes, I am thinking of a case where Postgres is down but a malevolent
> > user starts a Postgres server on 5432 to gather passwords. Verifying
> > against an
ing only "KB",
and it supports "kB" for backward compatibility. What it doesn't do is
to allow arbitrary case, which I think would be a step backward. The
second patch actually does match the JEDEC standard, except for allowing
"kB".
I also just applied a doc pat
On Fri, Jul 29, 2016 at 08:18:38PM -0400, Bruce Momjian wrote:
> However, that is not the end of the story. Things have moved forward
> since 2006 and there is now firm support for either KB or KiB to be
> 1024-based units. This blog post explains the current state of prefix
> s
e we never used mB, so in JEDEC and Metric,
MB is ambiguous as 1000-based or 1024-based.
IEC does give us a unique specification for 'mega', MiB, and GiB, which
might be what we want to use, but that might be too big a change, and I
rarely see those.
--
Bruce Momjian <br...@momjian.us>
f
> mergejoin recheck (or just pull out whatever the lowest-not-seen each
> time we sort the tuples on the page).
So allow HOT updates if the updated row is on the same page, even if the
indexed column was changed, by scanning the page --- got it.
--
Bruce Momjian <br...@momjia
king of a case where Postgres is down but a malevolent
user starts a Postgres server on 5432 to gather passwords. Verifying
against an SSL certificate would avoid this problem, so there is some
value in using SSL on localhost. (There is no such security available
for Unix-domain socket
and come up with another tool that does those bullets. Heck, people
already can't find --link.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
ws, but what does
this gain us that pg_dump/pg_restore doesn't? Wouldn't you just create
the standby using logical replication and just switch-over? Why use
pg_upgrade at all? Am I missing something?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
have seen, not the bugs
they haven't seen.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Sent
re-test everything when the RC1 arrives --- we
assume the testing is cumulative from when we started beta.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are,
ly bad).
>
> This is a common problem case we don't have an answer for yet.
Or, basically, we don't have an answer to without making something else
worse.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
olumn by name or number. Enforce by checking that
> * transformSortClause doesn't add any items to tlist.
>
> Perhaps sometime we ought to make an effort to relax that.
Oh, I didn't see that above the error block.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Wed, Jul 20, 2016 at 10:55:38PM +0100, Greg Stark wrote:
> On Wed, Jul 20, 2016 at 10:38 PM, Bruce Momjian <br...@momjian.us> wrote:
> > SELECT 'a-c' AS x UNION ALL SELECT 'ab' AS x ORDER BY x COLLATE "C";
>
>
> ::***> select 'a-c' COLLATE "C" A
=> WITH d AS (SELECT 'a-c' AS x UNION ALL SELECT 'ab' AS x) SELECT * FROM
d ORDER BY x COLLATE "C";
x
-
a-c
ab
(2 rows)
I think the 'ORDER BY x COLLATE "C"' is being parsed as an a_expr, and
we don't allow a_expr in a UNION. Perhaps we are too strict here, but
safe.
My simplistic idea would be to tell people to run a checkpoint right
before all the snapshots are taken, but even that doesn't seem 100%
safe. This needs someone who understands the WAL and how to tell people
a totally safe procedure.
--
Bruce Momjian <br...@momjian.us>ht
m.
>
> The button was supposed to be removed until we get an updated build -
> apologies for the inconvenience.
Yes, and I reported it to EDB a few days ago too.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
; certainly I've never seen
> >> any place in our docs that draws a distinction between those terms.
> >> If you think there is a difference, maybe we need to define those
> >> terms somewhere.
> >
> > Uh, I think Unicode is a character set, and UTF8 is an e
On Wed, Jun 22, 2016 at 04:51:46PM -0400, Bruce Momjian wrote:
> On Mon, Jun 6, 2016 at 03:53:41PM +1200, Thomas Munro wrote:
> > Hi
> >
> > The manual[1] says "Technically,PostgreSQL uses UT1 rather than UTC
> > because leap seconds are not handled." I'm
allelism. Also, I think
> it's very much complementary to parallelism.
Agreed. I did put out a blog entry about this in April that has links
to some external projects trying to address this issue:
http://momjian.us/main/blogs/pgblog/2016.html#April_1_2016
--
Bruce Momjian <br...@
that are similar to those caller routines (in that they
> at least call puttuple_common()) that do not call COPYTUP()
> (tuplesort_putdatum(), and now tuplesort_putindextuplevalues()).
>
> I believe that this has value. All the extra boilerplate code misleads.
At a minimum we can
ow how to fix it.
If you are not going to backpatch this for compatibility reasons, I
don't think changing it during beta makes sense either because you open
the chance of breaking applications that have already been tested on
earlier 9.6 betas. This would only make sense if the to_timestamp
07
> (1 row)
>
> We should have same treatment for format string too.
>
> Thoughts? Comments?
Well, the user specifies the format string, while the input string comes
from the data, so I don't see having them behave the same as necessary.
--
Bruce Momjian <br...@momjian.us>
401 - 500 of 16619 matches
Mail list logo
