Re: [HACKERS] Way to access LSN (for each transaction) by directly talking to postgres?

On Wed, Aug 3, 2016 at 3:00 PM, Michael Paquier wrote: > On Wed, Aug 3, 2016 at 12:37 PM, Joshua Bay wrote: >> Could you please let me know if there is a way to get LSN of each >> transaction by directly communicating with Postgres server and NOT by >> accessing logs. > > Logical decoding is one

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Wed, Aug 3, 2016 at 2:52 PM, Masahiko Sawada wrote: > I was thinking that the syntax for quorum method would use '[ ... ]' > but it will be confused with '( ... )' priority method used. > 001 patch adds 'Any N ( ... )' style syntax but I know that we still > might need to discuss about better s

Re: [HACKERS] Way to access LSN (for each transaction) by directly talking to postgres?

On Wed, Aug 3, 2016 at 12:37 PM, Joshua Bay wrote: > Could you please let me know if there is a way to get LSN of each > transaction by directly communicating with Postgres server and NOT by > accessing logs. Logical decoding is one way. -- Michael -- Sent via pgsql-hackers mailing list (pgsq

[HACKERS] Quorum commit for multiple synchronous replication.

Hi all, In 9.6 development cycle, we had been discussed about configuration syntax for a long time while considering expanding. As a result, we had new dedicated language for multiple synchronous replication, but it supports only priority method. We know that quorum commit is very useful for many

Re: [HACKERS] Why we lost Uber as a user

On 03/08/16 02:27, Robert Haas wrote: Personally, I think that incremental surgery on our current heap format to try to fix this is not going to get very far. If you look at the history of this, 8.3 was a huge release for timely cleanup of dead tuple. There was also significant progress in 8.4

Re: [HACKERS] regression test for extended query protocol

[Sorry for a top post. For unknown reason I couldn' get mails from pgsql-hackers since this morning and I have to check the archive] >> In my understanding, we don't have any regression test for protocol >> level prepared query (we do have SQL level prepared query tests, >> though). Shouldn't we a

Re: [HACKERS] Slowness of extended protocol

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 only the ability to send parameter values out-of-line instead > of having to quote/escape them into SQL literals. Maybe an idea for the > fabled V4 pro

Re: [HACKERS] regression test for extended query protocol

On Wed, Aug 3, 2016 at 11:33 AM, Tatsuo Ishii wrote: > In my understanding, we don't have any regression test for protocol > level prepared query (we do have SQL level prepared query tests, > though). Shouldn't we add those tests to the regression test suites? I thought that ECPG was covering a p

[HACKERS] regression test for extended query protocol

In my understanding, we don't have any regression test for protocol level prepared query (we do have SQL level prepared query tests, though). Shouldn't we add those tests to the regression test suites? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php

Re: [HACKERS] Why we lost Uber as a user

On Tue, Aug 2, 2016 at 07:30:22PM -0700, Alfred Perlstein wrote: > So for instance, let's say there is a bug in the master's write to disk. > The logical replication acts as a barrier from that bad write going to the > slaves. With bad writes going to slaves then any corruption experienced on >

Re: [HACKERS] Why we lost Uber as a user

On 8/2/16 2:14 PM, Tom Lane wrote: Stephen Frost writes: With physical replication, there is the concern that a bug in *just* the physical (WAL) side of things could cause corruption. Right. But with logical replication, there's the same risk that the master's state could be fine but a repl

Re: [HACKERS] Increasing timeout of poll_query_until for TAP tests

On Wed, Aug 3, 2016 at 7:21 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> Here using pg_xlog_replay_resume() is not the correct solution because >> this would cause the node to finish recovery before we want it to, and >> so is recovery_target_action = 'promote'. If we look at the test,

Re: [HACKERS] Slowness of extended protocol

Doesn't this patch break an existing behavior of unnamed statements? That is, an unnamed statement shall exist until next parse message using unnamed statement received. It is possible to use the same unnamed statement multiple times in a transaction. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Ja

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Tue, Aug 2, 2016 at 5:05 PM, Robert Haas wrote: > I think that's just making life difficult. If nothing else, sqlsmith > hunts around for functions it can call that return internal errors, > and if we refuse to fix all of them to return user-facing errors, then > it's just crap for the people

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Tue, Aug 2, 2016 at 7:16 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Aug 2, 2016 at 6:03 AM, Dilip Kumar wrote: >>> There are many more such exposed functions, which can throw cache lookup >>> failure error if we pass wrong value. >>> >>> i.e. >>> record_in >>> domain_in >>> fmgr_c_v

Re: [HACKERS] Changed SRF in targetlist handling

On 2016-08-02 19:02:38 -0400, Tom Lane wrote: > Andres Freund writes: > > I've an implementation that > > > 1) turns all targetlist SRF (tSRF from now on) into ROWS FROM > >expressions. If there's tSRFs in the argument of a tSRF those becomes > >a separate, lateral, ROWS FROM expression. >

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

Robert Haas writes: > On Tue, Aug 2, 2016 at 6:03 AM, Dilip Kumar wrote: >> There are many more such exposed functions, which can throw cache lookup >> failure error if we pass wrong value. >> >> i.e. >> record_in >> domain_in >> fmgr_c_validator >> plpgsql_validator >> pg_procedure_is_visible >

Re: [HACKERS] Changed SRF in targetlist handling

Andres Freund writes: > I've an implementation that > 1) turns all targetlist SRF (tSRF from now on) into ROWS FROM >expressions. If there's tSRFs in the argument of a tSRF those becomes >a separate, lateral, ROWS FROM expression. > 2) If grouping/window functions are present, the entire

Re: [HACKERS] Double invocation of InitPostmasterChild in bgworker with -DEXEC_BACKEND

Thomas Munro writes: > I discovered that if you build with -DEXEC_BACKEND on a Unix system > and then try to start a background worker, it dies in > InitializeLatchSupport: > TRAP: FailedAssertion("!(selfpipe_readfd == -1)", File: "latch.c", Line: 161) > That's because InitPostmasterChild is cal

Re: [HACKERS] Increasing timeout of poll_query_until for TAP tests

Michael Paquier wrote: > Here using pg_xlog_replay_resume() is not the correct solution because > this would cause the node to finish recovery before we want it to, and > so is recovery_target_action = 'promote'. If we look at the test, it > is doing the following when getting the TXID that is use

Re: [HACKERS] Fwd: [BUGS] BUG #14247: COMMENT is restored on wrong database

Moving to -hackers since this is getting into details Bug Report # 14247 On Tue, Aug 2, 2016 at 4:58 PM, Tom Lane wrote: > "David G. Johnston" writes: > > Do you have an opinion on this following? > > I think the real problem in this area is that the division of labor > we have between pg_dump

Re: [HACKERS] Why we lost Uber as a user

Stephen Frost writes: > With physical replication, there is the concern that a bug in *just* the > physical (WAL) side of things could cause corruption. Right. But with logical replication, there's the same risk that the master's state could be fine but a replication bug creates corruption on th

Re: [HACKERS] parallel.c is not marked as test covered

On Tue, Aug 2, 2016 at 1:17 PM, Peter Eisentraut wrote: > On 6/19/16 10:00 PM, Robert Haas wrote: >>> Independent of that, it would help testing things like this if we allowed >>> > setting max_worker_processes to 0, instead of the current minimum 1. If >>> > there a reason for the minimum of 1?

Re: [HACKERS] old_snapshot_threshold allows heap:toast disagreement

On Thu, Jul 28, 2016 at 7:29 PM, Andres Freund wrote: > I think just iterating through the active snapshots would have been > fine. Afaics there's no guarantee that the first active snapshot pushed > is the relevant one - in contrast to registered one, which are ordered > by virtue of the heap. A

Re: [HACKERS] PostgreSQL 10 kick-off

Peter Eisentraut wrote: > On 8/1/16 1:08 PM, Fabrízio de Royes Mello wrote: > > What knowledge is expected for a CFM? I'm really would like to help and > > also learn more about our development. > > If you search the wiki for "commitfest" you will find several pages of > varying outdatedness that

Re: [HACKERS] HandleParallelMessages contains CHECK_FOR_INTERRUPTS?

I wrote: > Alvaro Herrera writes: >> I notice you just removed the CHECK_FOR_INTERRUPTS in >> HandleParallelMessages(). Did you notice that HandleParallelMessages >> calls shm_mq_receive(), which calls shm_mq_receive_bytes(), which >> contains a CHECK_FOR_INTERRUPTS() call? After study, I believ

Re: [HACKERS] Why we lost Uber as a user

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Aug 2, 2016 at 3:07 PM, Alfred Perlstein wrote: > > You are quite technical, my feeling is that you will understand it, however > > it will need to be a self learned lesson. > > I don't know what this is supposed to mean, but I think that Ge

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

On Mon, Aug 1, 2016 at 10:19:43AM -0400, Tom Lane wrote: > As far as I understood Andrew's use case, he was specifically *not* > interested in a complete representation of an index definition, but > rather about whether it had certain properties that would be of > interest to query-constructing ap

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On Tue, Aug 2, 2016 at 2:33 PM, Bruce Momjian wrote: > On Tue, Jul 26, 2016 at 05:42:43PM -0400, Chapman Flack wrote: >> Even so, I'd be curious whether it would break anything to have >> xlp_pageaddr simply set to InvalidXLogRecPtr in the dummy zero >> pages written to fill out a segment. At leas

Re: [HACKERS] Why we lost Uber as a user

On Tue, Aug 2, 2016 at 3:07 PM, Alfred Perlstein wrote: > You are quite technical, my feeling is that you will understand it, however > it will need to be a self learned lesson. I don't know what this is supposed to mean, but I think that Geoff's point is somewhat valid. No matter how you repli

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On 08/02/2016 02:33 PM, Bruce Momjian wrote: > My guess is that the bytes are there to detect problems where > a 512-byte disk sector is zeroed by a disk failure. Does that seem plausible? (a) there is only one such header for every 16 512-byte disk sectors, so it only affords a 6% chance of dete

Re: [HACKERS] TODO item: Implement Boyer-Moore searching in LIKE queries

Karan Sikka writes: > Just for the record, I'm leaning to the side of "not worth it". My > thoughts are, if you are at a scale where you care about this 20% > speedup, you would want to go all the way to an indexed structure, > because the gains you would realize would exceed 20%, and 20% may not

Re: [HACKERS] Slowness of extended protocol

> > I really don't get what's problematic with posting a message on a mailing > list about a potential performance issue, to try to get people's reactions, > without diving into profiling right away > "Benchmark data is a perfect substitute for benchmarking results. Data is easy to misinterpret, s

Re: [HACKERS] Why we lost Uber as a user

> On Aug 2, 2016, at 2:33 AM, Geoff Winkless wrote: > >> On 2 August 2016 at 08:11, Alfred Perlstein wrote: >>> On 7/2/16 4:39 AM, Geoff Winkless wrote: >>> I maintain that this is a nonsense argument. Especially since (as you >>> pointed out and as I missed first time around) the bug actuall

Re: [HACKERS] TODO item: Implement Boyer-Moore searching in LIKE queries

On Tue, Aug 2, 2016 at 1:56 PM, Alvaro Herrera wrote: >> > How desirable is this feature? To begin answering that question, >> > I did some initial benchmarking with an English text corpus to find how >> > much >> > faster BMH (Boyer-Moore-Horspool) would be compared to LIKE, and the >> > result

Re: [HACKERS] TODO item: Implement Boyer-Moore searching in LIKE queries

Yeah, you make a fair point. I was hoping more people would chime in with strong opinions to make the decision easier, but perhaps the lack of noise indicates this is a low-pri feature. I will ask around in my coworker circles to see what they think, could you do the same? Just for the record, I

Re: [HACKERS] PostmasterContext survives into parallel workers!?

Alvaro Herrera writes: > Tom Lane wrote: >> It looks to me like the reason for it is simply not having bothered to >> copy the rw->rw_worker data to somewhere that would survive deletion >> of the PostmasterContext. I wonder though if anyone remembers a more >> fundamental reason? Surely the bgw

Re: [HACKERS] Increasing timeout of poll_query_until for TAP tests

Michael Paquier wrote: > On Tue, Aug 2, 2016 at 10:28 AM, Michael Paquier > wrote: > > There is still an issue with pg_basebackup when testing stream mode > > and replication slots. I am digging into this one now.. > > After 5 hours running this test in a row and 30 attempts torturing > hamster w

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On Tue, Jul 26, 2016 at 05:42:43PM -0400, Chapman Flack wrote: > Even so, I'd be curious whether it would break anything to have > xlp_pageaddr simply set to InvalidXLogRecPtr in the dummy zero > pages written to fill out a segment. At least until it's felt > that archive_timeout has been so decide

Re: [HACKERS] PostmasterContext survives into parallel workers!?

Tom Lane wrote: > Robert Haas writes: > > On Mon, Aug 1, 2016 at 4:18 PM, Tom Lane wrote: > >> Now, I'm undecided whether to flush that context only in parallel workers, > >> or to try to make it go away for all bgworkers of any stripe. The latter > >> seems a little better from a security stand

Re: [HACKERS] PostgreSQL 10 kick-off

On 8/1/16 1:08 PM, Fabrízio de Royes Mello wrote: > What knowledge is expected for a CFM? I'm really would like to help and > also learn more about our development. If you search the wiki for "commitfest" you will find several pages of varying outdatedness that describe the process. Mainly, you w

Re: [HACKERS] PostmasterContext survives into parallel workers!?

Robert Haas writes: > On Mon, Aug 1, 2016 at 4:18 PM, Tom Lane wrote: >> Now, I'm undecided whether to flush that context only in parallel workers, >> or to try to make it go away for all bgworkers of any stripe. The latter >> seems a little better from a security standpoint, but I wonder if any

Re: [HACKERS] Slowness of extended protocol

On Mon, Aug 1, 2016 at 12:12 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > The attached patch passes `make check` and it gains 31221 -> 33547 improvement for "extended pgbench of SELECT 1". > > The same version gains 35682 in "simple" mode, and "prepared" mode achieves 46367 (just

Re: [HACKERS] TODO item: Implement Boyer-Moore searching in LIKE queries

Robert Haas wrote: > On Mon, Aug 1, 2016 at 1:19 PM, Karan Sikka wrote: > > Following the patch to implement strpos with Boyer-Moore-Horspool, > > it was proposed we bring BMH to LIKE as well. > > > > Original thread: > > https://www.postgresql.org/message-id/flat/27645.1220635769%40sss.pgh.pa.us#

Re: [HACKERS] MSVC pl-perl error message is not verbose enough

On Mon, Aug 1, 2016 at 9:39 PM, Michael Paquier wrote: > On Tue, Aug 2, 2016 at 2:08 AM, Robert Haas wrote: > > Did you add this to the next CommitFest? > > I have added it here: > https://commitfest.postgresql.org/10/691/ > John, it would be good if you could get a community account and add > y

Re: [HACKERS] parallel.c is not marked as test covered

On 6/19/16 10:00 PM, Robert Haas wrote: >> Independent of that, it would help testing things like this if we allowed >> > setting max_worker_processes to 0, instead of the current minimum 1. If >> > there a reason for the minimum of 1? > I believe that's pure brain fade on my part. I think the mi

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

On Tue, Aug 2, 2016 at 11:29:01AM +0200, Christoph Berg wrote: > > The issue is that we output "10 bytes", not "10bytes", but for units we > > use "977KB". That seems inconsistent, but it is the normal policy > > people use. I think this is because "977KB" is really "977K bytes", but > > we just

Re: [HACKERS] Wanting to learn about pgsql design decision

> "Tom" == Tom Lane writes: >> - Why to read from a table, both a usage permission on the schema >> and a read access permission on the table is needed? Tom> Because the SQL standard says so. You'd think, but in fact it doesn't; the spec (at least 2008 and the 2011 drafts) has no concept

[HACKERS] PATCH: two slab-like memory allocators

Hi, Back in the bug #14231 thread [1], dealing with performance issues in reorderbuffer due to excessive number of expensive free() calls, I've proposed to resolve that by a custom slab-like memory allocator, suitable for fixed-size allocations. I'd like to put this into the next CF, and it's

Re: [HACKERS] Why we lost Uber as a user

On 2 August 2016 at 15:27, Robert Haas wrote: > On Tue, Aug 2, 2016 at 5:51 AM, Amit Kapila wrote: >> Why we need to add a record in all indexes if only the key >> corresponding to one of indexes is updated? Basically, if the tuple >> can fit on same page, why can't we consider it as HOT (or HPT

Re: [HACKERS] Wanting to learn about pgsql design decision

Tal Walter writes: >- Why in the roles system, user are actually roles with login attribute >and not a separate entity. Groups and users used to be separate concepts, actually, a long time ago. We got rid of that because it was a PITA; in particular, grants to groups had to be represented

Re: [HACKERS] PostmasterContext survives into parallel workers!?

Robert Haas writes: > On Mon, Aug 1, 2016 at 7:42 PM, Tom Lane wrote: >> ... This is what makes me dubious that getting rid >> of doing work in the postmaster's signal handlers is really going >> to add any noticeable increment of safety. It might make the >> code look cleaner, but I'm afraid i

Re: [HACKERS] Reviewing freeze map code

On Tue, Aug 02, 2016 at 02:10:29PM +0530, Amit Kapila wrote: > On Tue, Aug 2, 2016 at 11:19 AM, Noah Misch wrote: > > On Sat, Jul 23, 2016 at 01:25:55PM +0530, Amit Kapila wrote: > >> On Mon, Jul 18, 2016 at 2:03 PM, Andres Freund wrote: > >> > On 2016-07-18 10:02:52 +0530, Amit Kapila wrote: > >

[HACKERS] PostgreSQL 10 Roadmaps

https://wiki.postgresql.org/wiki/PostgreSQL10_Roadmap -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Why we lost Uber as a user

On Tue, Aug 2, 2016 at 5:51 AM, Amit Kapila wrote: > Why we need to add a record in all indexes if only the key > corresponding to one of indexes is updated? Basically, if the tuple > can fit on same page, why can't we consider it as HOT (or HPT - heap > partial tuple or something like that), unl

Re: [HACKERS] New version numbering practices

Greg Stark writes: > On Tue, Aug 2, 2016 at 2:10 AM, Alvaro Herrera > wrote: >> That said, I'm not opposed to REL_10 and so on. In 89 years there will >> be a problem with sorting REL_100 but I'm sure they can find a solution >> then, if computers still need humans to write programs for them.

Re: [HACKERS] Tracking wait event for latches

On Wed, Jun 8, 2016 at 10:11 AM, Michael Paquier wrote: > Yeah, that's as well my line of thoughts on the matter since the > beginning: keep it simple and done. What is written just after those > words is purely hand-waving and I have no way to prove it, but my > instinctive guess is that more tha

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

> -Original Message- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Tuesday, August 02, 2016 9:36 PM > To: Kaigai Kouhei(海外 浩平); pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown > plans > > On 2016/08/01 20:15, Et

Re: [HACKERS] Wrong defeinition of pq_putmessage_noblock since 9.5

On Fri, Jul 29, 2016 at 11:58 AM, Tom Lane wrote: > Maybe the real problem here is that the abstraction layer is so incomplete > and apparently haphazard, so that it's not very obvious where you should > use a pq_xxx name and where you should refer to socket_xxx. For some of > the functions in pq

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/08/01 20:15, Etsuro Fujita wrote: I thought about the Relations line a bit more and noticed that there are cases where the table reference names for joining relations in the Relations line are printed incorrectly. Here is an example: postgres=# explain verbose select * from (select t1.a

Re: [HACKERS] old_snapshot_threshold allows heap:toast disagreement

On Tue, Aug 2, 2016 at 9:10 AM, Robert Haas wrote: > On Sat, Jul 30, 2016 at 8:17 AM, Amit Kapila wrote: >> On Fri, Jul 29, 2016 at 1:10 AM, Robert Haas wrote: >>> On Wed, Jul 27, 2016 at 7:26 PM, Andres Freund wrote: >>> >>> New version attached. >> >> +static inline void >> +InitToastSnapshot

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Tue, Aug 2, 2016 at 6:03 AM, Dilip Kumar wrote: > There are many more such exposed functions, which can throw cache lookup > failure error if we pass wrong value. > > i.e. > record_in > domain_in > fmgr_c_validator > plpgsql_validator > pg_procedure_is_visible > > Are we planning to change thes

Re: [HACKERS] New version numbering practices

On Tue, Aug 2, 2016 at 2:10 AM, Alvaro Herrera wrote: > That said, I'm not opposed to REL_10 and so on. In 89 years there will > be a problem with sorting REL_100 but I'm sure they can find a solution > then, if computers still need humans to write programs for them. It would be nice if there wa

Re: [HACKERS] Broken order-of-operations in parallel query latch manipulation

On Mon, Aug 1, 2016 at 8:45 PM, Tom Lane wrote: > Amit Kapila writes: >> On Mon, Aug 1, 2016 at 1:58 AM, Tom Lane wrote: >>> I believe this is wrong and the CHECK_FOR_INTERRUPTS needs to be before >>> or after the two latch operations. As-is, if the reason somebody set >>> our latch was to get

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Tue, Aug 2, 2016 at 3:33 PM, Dilip Kumar wrote: > There are many more such exposed functions, which can throw cache lookup > failure error if we pass wrong value. > > i.e. > record_in > domain_in > fmgr_c_validator > edb_get_objecttypeheaddef > plpgsql_validator > pg_procedure_is_visible > > A

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Sat, Jul 30, 2016 at 4:27 AM, Michael Paquier wrote: > OK for me. Thanks for the commit. There are many more such exposed functions, which can throw cache lookup failure error if we pass wrong value. i.e. record_in domain_in fmgr_c_validator edb_get_objecttypeheaddef plpgsql_validator pg_pr

Re: [HACKERS] Why we lost Uber as a user

On Sat, Jul 30, 2016 at 12:06 AM, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us) wrote: >> On Fri, Jul 29, 2016 at 10:44:29AM -0400, Stephen Frost wrote: >> > Another thought that was kicking around in my head related to that is if >> > we could have indexes that only provide page-level

Re: [HACKERS] Why we lost Uber as a user

On 2 August 2016 at 08:11, Alfred Perlstein wrote: > On 7/2/16 4:39 AM, Geoff Winkless wrote: > > I maintain that this is a nonsense argument. Especially since (as you > > pointed out and as I missed first time around) the bug actually occurred at > > different records on different slaves, so he

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

Re: Peter Eisentraut 2016-08-01 > > PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses > > spaces: > > > > # select pg_size_pretty((2^20)::bigint); > > pg_size_pretty > > > > 1024 kB > > because it's "pretty" :) :) > > SHOW does not: > > > > # show wor

Re: [HACKERS] Reviewing freeze map code

On Tue, Aug 2, 2016 at 11:19 AM, Noah Misch wrote: > On Sat, Jul 23, 2016 at 01:25:55PM +0530, Amit Kapila wrote: >> On Mon, Jul 18, 2016 at 2:03 PM, Andres Freund wrote: >> > On 2016-07-18 10:02:52 +0530, Amit Kapila wrote: >> >> Consider the below scenario. >> >> >> >> Vacuum >> >> a. acquires

[HACKERS] Wanting to learn about pgsql design decision

Dear list, I'm interested in pgsql, and would like to know more about the design decisions behind it's features. Where should I search in order to know more about subjects, for example: - Why in the roles system, user are actually roles with login attribute and not a separate entity. - W

Re: [HACKERS] asynchronous and vectorized execution

Thank you for the comment. At Mon, 1 Aug 2016 10:44:56 +0530, Amit Khandekar wrote in > On 21 July 2016 at 15:20, Kyotaro HORIGUCHI > wrote: > > > > > After some consideration, I found that ExecAsyncWaitForNode > > cannot be reentrant because it means that the control goes into > > async-unaw

Re: [HACKERS] Why we lost Uber as a user

On 7/26/16 9:54 AM, Joshua D. Drake wrote: Hello, The following article is a very good look at some of our limitations and highlights some of the pains many of us have been working "around" since we started using the software. https://eng.uber.com/mysql-migration/ Specifically: * Ineffic

Re: [HACKERS] Why we lost Uber as a user

On 7/28/16 7:08 AM, Merlin Moncure wrote: *) postgres may not be the ideal choice for those who want a thin and simple database This is a huge market, addressing it will bring mindshare and more jobs, code and braintrust to psql. -Alfred -- Sent via pgsql-hackers mailing list (pgsql-hacke

Re: [HACKERS] Why we lost Uber as a user

On 7/28/16 4:39 AM, Geoff Winkless wrote: On 28 Jul 2016 12:19, "Vitaly Burovoy" > wrote: > > On 7/28/16, Geoff Winkless > wrote: > > On 27 July 2016 at 17:04, Bruce Momjian > wrote: > > > >> Well, their bi