Re: [HACKERS] Tracking wait event for latches

On Tue, Aug 2, 2016 at 10:31 PM, Michael Paquier wrote: > Attached is an updated patch. Updated version for 2 minor issues: 1) s/stram/stream/ 2) Docs used incorrect number -- Michael diff --git a/contrib/postgres_fdw/connection.c b/contrib/postgres_fdw/connection.c

[HACKERS] Optimization for lazy_scan_heap

Hi all, While reviewing freeze map code, Andres pointed out[1] that lazy_scan_heap could accesses visibility map twice and its logic is seems a bit tricky. As discussed before, it's not nice especially when large relation is entirely frozen. I posted the patch for that before but since this is

Re: [HACKERS] max_parallel_degree > 0 for 9.6 beta

Noah Misch writes: > On Wed, Apr 20, 2016 at 02:28:15PM -0400, Tom Lane wrote: >> +1, but let's put an entry on the 9.6 open-items page to remind us to >> make that decision at the right time. > It's that time. Do we restore the max_parallel_workers_per_gather=0 default, > or

Re: [HACKERS] New version numbering practices

Craig Ringer writes: > On 4 August 2016 at 02:15, Tom Lane wrote: >> So it seems like fixing libpq's parsing of server_version_num is >> something we definitely want to fix ASAP in all back branches. > Well, this seems like a good time to make

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

On Wed, Aug 3, 2016 at 3:05 PM, Michael Paquier wrote: > 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

Re: [HACKERS] max_parallel_degree > 0 for 9.6 beta

On Wed, Apr 20, 2016 at 02:28:15PM -0400, Tom Lane wrote: > Andres Freund writes: > > max_parallel_degree currently defaults to 0. I think we should enable > > it by default for at least the beta period. Otherwise we're primarily > > going to get reports back after the

Re: [HACKERS] New version numbering practices

On 4 August 2016 at 02:15, Tom Lane wrote: > Robert Haas writes: > > On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut > > wrote: > >> One hiccup I found is that server_version_num is not sent to clients. > >>

[HACKERS] Re: [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)

On Wed, Aug 03, 2016 at 05:52:44PM -0400, Tom Lane wrote: > I wrote: > > I'm thinking there are two distinct bugs here. > > Actually, make that three bugs. I was so focused on the crashing > that I failed to notice that ts_delete wasn't producing sane answers > even when it didn't crash:

Re: [HACKERS] Lossy Index Tuple Enhancement (LITE)

On Wed, Aug 3, 2016 at 4:37 PM, Claudio Freire wrote: > On Wed, Aug 3, 2016 at 4:20 AM, Simon Riggs wrote: >> == IndexScan == >> >> Note that the executor code for IndexScan appears identical between >> the two optimizations. The difference between

Re: [HACKERS] Lossy Index Tuple Enhancement (LITE)

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 > > > quite complicated. > > > >

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On Thu, Aug 4, 2016 at 08:22:25AM +0800, Craig Ringer wrote: > Yep, it does. But we've made little to no progress on integration of ICU > support and AFAIK nobody's working on it right now.  Uh, this email from July says Peter Eisentraut will submit it in September :-)

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

On Thu, Aug 4, 2016 at 3:02 AM, Joshua Bay wrote: > Could you please tell me how I can get LSN of each transaction at decoder > plugin? Craig already gave you hints, but here are more. You will need to hack your own plugin. You could just use the one in

Re: [HACKERS] Lossy Index Tuple Enhancement (LITE)

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 > > quite complicated. > > The insertion algorithm is described. Doesn't seem complicated to me. Ah,

Re: [HACKERS] Lossy Index Tuple Enhancement (LITE)

On Thu, Aug 4, 2016 at 01:16:20AM +0100, Simon Riggs wrote: > On 4 August 2016 at 00:56, Bruce Momjian 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 > >> for indexes without

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

On 4 August 2016 at 01:35, Joshua Bay wrote: > Thanks for responses! > > The problem I wanted to solve was to find the (global) order of commits > across the postgres cluster. So, my attempt was to use the LSN. > Have a look at how logical decoding does it. Check out

Re: [HACKERS] PostgreSQL 10 kick-off

On Thu, Aug 4, 2016 at 12:09 AM, Fabrízio de Royes Mello wrote: > If there are no complains about my lack of experience in this field I would > like do become the next CFM (am I the first brazilian??) That would be great. I am not sending more patches for the 1st CF and

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 4 August 2016 at 05:00, Thomas Munro wrote: > On Thu, Aug 4, 2016 at 5:16 AM, Craig Ringer > wrote: > > On 3 August 2016 at 22:54, Álvaro Hernández Tortosa > wrote: > >> What would it take to support it? Isn't the

Re: [HACKERS] Lossy Index Tuple Enhancement (LITE)

On 4 August 2016 at 00:56, Bruce Momjian 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 >> for indexes without changed column values by using a bitmap in place of >> the tid item

Re: [HACKERS] Possible duplicate release of buffer lock.

Sorry. That's partially wrong. At Wed, 03 Aug 2016 17:31:16 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160803.173116.111915228.horiguchi.kyot...@lab.ntt.co.jp> > I had an inquiry about the following log messages. > > 2016-07-20 10:16:58.294

Re: [HACKERS] Lossy Index Tuple Enhancement (LITE)

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 you handle the

Re: [HACKERS] regression test for extended query protocol

On Thu, Aug 4, 2016 at 12:14 AM, Dave Cramer wrote: > We currently run tests every time a PR is created on github, but I don't > think there are any animals running the JDBC test suite > > We can add tests, what exactly do we want to test. Then setting up an animal > to run

Re: [HACKERS] Slowness of extended protocol

On Wed, Aug 3, 2016 at 10:02:39AM -0400, Tom Lane wrote: > Bruce Momjian 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 only the ability to send parameter

Re: [HACKERS] Lossy Index Tuple Enhancement (LITE)

On Wed, Aug 3, 2016 at 08:20:49AM +0100, Simon Riggs wrote: > == Update Duplicate Removal == > > We want an optimization that reduces the effects of multiple UPDATEs > on the same block that have duplicate values caused because another > index column has been updated and a non-HOT index insert

Re: [HACKERS] Small fix: avoid passing null pointers to memcpy()

On 4/16/16 8:48 AM, Piotr Stefaniak wrote: > On 2016-04-03 09:24, Piotr Stefaniak wrote: >> > from running the regression test suite (including TAP tests) and also >> > sqlsmith, I've got a couple of places where UBSan reported calls to >> > memcpy() with null pointer passed as either source or

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 21:42, Geoff Winkless wrote: On 3 August 2016 at 20:36, Álvaro Hernández Tortosa wrote: Isn't the correct syntax something like: select E'\uc080', U&'\c080'; ? It is a single character, 16 bit unicode sequence (see

Re: [HACKERS] Cache Hash Index meta page.

Jeff Janes writes: > On Fri, Jul 22, 2016 at 3:02 AM, Mithun Cy wrote: >> I have created a patch to cache the meta page of Hash index in >> backend-private memory. This is to save reading the meta page buffer every >> time when we want to find

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

On Thu, Aug 4, 2016 at 2:34 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Wed, Aug 3, 2016 at 7:21 AM, Alvaro Herrera >> wrote: > >> > Why not capture both items in a single select, such as in the attached >> > patch? >> >> Let me

Re: [HACKERS] [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)

On Thu, Aug 4, 2016 at 9:39 AM, Tom Lane wrote: > Andreas Seltenreich writes: >> the following statement triggers an assertion in tsearch: > >> select ts_delete(array_to_tsvector('{smith,smith,smith}'::text[]), >> '{smith,smith}'::text[]); >> -- TRAP:

Re: [HACKERS] [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)

I wrote: > I'm thinking there are two distinct bugs here. Actually, make that three bugs. I was so focused on the crashing that I failed to notice that ts_delete wasn't producing sane answers even when it didn't crash: regression=# select ts_delete(array_to_tsvector('{smith,foo,bar}'::text[]),

Re: [HACKERS] [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)

Andreas Seltenreich writes: > the following statement triggers an assertion in tsearch: > select ts_delete(array_to_tsvector('{smith,smith,smith}'::text[]), > '{smith,smith}'::text[]); > -- TRAP: FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", > Line: 511)

Re: [HACKERS] Cache Hash Index meta page.

On Fri, Jul 22, 2016 at 3:02 AM, Mithun Cy wrote: > I have created a patch to cache the meta page of Hash index in > backend-private memory. This is to save reading the meta page buffer every > time when we want to find the bucket page. In “_hash_first” call, we try to

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Aug 3, 2016 at 11:42 AM, Robert Haas wrote: > I'm not going to say it's bad to be able to do things 2-2.5x faster, > but linear scalability this ain't - particularly because your 2.58x > faster case is using up to 7 or 8 times as much memory. The > single-process

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On Thu, Aug 4, 2016 at 5:16 AM, Craig Ringer wrote: > On 3 August 2016 at 22:54, Álvaro Hernández Tortosa wrote: >> What would it take to support it? Isn't the varlena header propagated >> everywhere, which could help infer the real length of the

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

On Wed, Aug 3, 2016 at 2:15 PM, Tom Lane wrote: > "Joshua D. Drake" writes: >> On 08/03/2016 11:23 AM, Tom Lane wrote: >>> I think the realistic answer if you suffer replication-induced corruption >>> is usually going to be "re-clone that slave", and

Re: [HACKERS] Optimizing numeric SUM() aggregate

On 2016-08-03 17:47:20 +, Andrey Borodin wrote: > I suppose this proves performance impact of a patch. I don't think > that sum calculation was a common bottleneck, but certainly patch will > slightly improve performance of a very huge number of queries. They commonly are in OLAP style

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 3 August 2016 at 20:36, Álvaro Hernández Tortosa wrote: > Isn't the correct syntax something like: > > select E'\uc080', U&'\c080'; > > ? > > It is a single character, 16 bit unicode sequence (see >

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

=?UTF-8?Q?=c3=81lvaro_Hern=c3=a1ndez_Tortosa?= writes: > According to https://en.wikipedia.org/wiki/UTF-8#Codepage_layout > the encoding used in Modified UTF-8 is an (otherwise) invalid UTF-8 code > point. In short, the \u00 nul is represented (overlong encoding) by the >

Re: [HACKERS] Lossy Index Tuple Enhancement (LITE)

On Wed, Aug 3, 2016 at 4:20 AM, Simon Riggs wrote: > == IndexScan == > > Note that the executor code for IndexScan appears identical between > the two optimizations. The difference between duplicate and range LITE > tuples is needed only at INSERT time (or UPDATE indexed

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 21:31, Geoff Winkless wrote: On 3 August 2016 at 20:13, Álvaro Hernández Tortosa wrote: Yet they are accepted by Postgres (like if Postgres would support Modified UTF-8 intentionally). The caracter in psql does not render as a nul but as this symbol: "삀". Not

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 3 August 2016 at 20:13, Álvaro Hernández Tortosa wrote: > Yet they are accepted by Postgres > (like if Postgres would support Modified UTF-8 intentionally). The caracter > in psql does not render as a nul but as this symbol: "삀". Not accepted as valid utf8: # select

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

"Joshua D. Drake" writes: > On 08/03/2016 11:23 AM, Tom Lane wrote: >> I think the realistic answer if you suffer replication-induced corruption >> is usually going to be "re-clone that slave", and logical rep doesn't >> really offer much gain in that. > Yes, it actually

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 20:14, Álvaro Hernández Tortosa wrote: On 03/08/16 17:47, Kevin Grittner wrote: On Wed, Aug 3, 2016 at 9:54 AM, Álvaro Hernández Tortosa wrote: What would it take to support it? Would it be of any value to support "Modified UTF-8"?

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

On Wed, Aug 3, 2016 at 2:23 PM, Tom Lane wrote: > Robert Haas writes: >> I don't think they are saying that logical replication is more >> reliable than physical replication, nor do I believe that to be true. >> I think they are saying that if logical

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

On 08/03/2016 11:23 AM, Tom Lane wrote: Robert Haas writes: I don't think they are saying that logical replication is more reliable than physical replication, nor do I believe that to be true. I think they are saying that if logical corruption happens, you can fix it by

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, Aug 1, 2016 at 6:18 PM, Peter Geoghegan wrote: > As some of you know, I've been working on parallel sort. I think I've > gone as long as I can without feedback on the design (and I see that > we're accepting stuff for September CF now), so I'd like to share what > I came

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

Robert Haas writes: > I don't think they are saying that logical replication is more > reliable than physical replication, nor do I believe that to be true. > I think they are saying that if logical corruption happens, you can > fix it by typing SQL statements to UPDATE,

Re: [HACKERS] Optimizing numeric SUM() aggregate

> 3 авг. 2016 г., в 22:47, Andrey Borodin написал(а): > > make installcheck-world: tested, failed > Implements feature: tested, failed > Spec compliant: tested, failed > Documentation:tested, failed > > This is a review of a patch "Optimizing

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 18:35, Geoff Winkless wrote: On 3 August 2016 at 15:54, Álvaro Hernández Tortosa wrote: Given that 0x00 is a perfectly legal UTF-8 character, I conclude we're strictly non-compliant. It's perhaps worth mentioning that 0x00 is valid ASCII too, and PostgreSQL

Re: [HACKERS] New version numbering practices

Robert Haas writes: > On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut > wrote: >> One hiccup I found is that server_version_num is not sent to clients. >> Instead, libpq assembles the numeric version number itself from the >> string

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 17:47, Kevin Grittner wrote: On Wed, Aug 3, 2016 at 9:54 AM, Álvaro Hernández Tortosa wrote: What would it take to support it? Would it be of any value to support "Modified UTF-8"? https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8 That's nice,

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

On Tue, Aug 2, 2016 at 5: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

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 17:23, Tom Lane wrote: =?UTF-8?Q?=c3=81lvaro_Hern=c3=a1ndez_Tortosa?= writes: As has been previously discussed (see https://www.postgresql.org/message-id/BAY7-F17FFE0E324AB3B642C547E96890%40phx.gbl for instance) varlena fields cannot accept the literal 0x00

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

Alvaro Herrera writes: > Tom Lane wrote: >> The attached patch passes "make check-world" for me. Can you check it >> against BDR? > Just checked. It works fine. Thanks! I'll push it shortly. regards, tom lane -- Sent via pgsql-hackers

Re: [HACKERS] New version numbering practices

On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut wrote: > One hiccup I found is that server_version_num is not sent to clients. > Instead, libpq assembles the numeric version number itself from the > string version, and it will fail if it sees only one number

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

Thanks Michael, Could you please tell me how I can get LSN of each transaction at decoder plugin? On Wed, Aug 3, 2016 at 2:08 AM, Michael Paquier wrote: > On Wed, Aug 3, 2016 at 3:00 PM, Michael Paquier > wrote: > > On Wed, Aug 3, 2016 at

Re: [HACKERS] New version numbering practices

On Wed, Aug 3, 2016 at 1:20 PM, Tom Lane wrote: > Greg Stark writes: > > Right now git-describe --tags on a random revision between 9.4 > > and 9.5 will print something like REL9_4_BETA1-1973-g85c25fd or > > something like REL9_5_BETA2-33-g55a2cc8 if it

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

Tom Lane wrote: > 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

Re: [HACKERS] Optimizing numeric SUM() aggregate

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed This is a review of a patch "Optimizing numeric SUM()

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

Thanks for responses! The problem I wanted to solve was to find the (global) order of commits across the postgres cluster. So, my attempt was to use the LSN. On Wed, Aug 3, 2016 at 9:47 AM, Craig Ringer wrote: > > > On 3 August 2016 at 11:37, Joshua Bay

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

Michael Paquier wrote: > On Wed, Aug 3, 2016 at 7:21 AM, Alvaro Herrera > wrote: > > Why not capture both items in a single select, such as in the attached > > patch? > > Let me test this > [... A while after ...] > This looks to work properly. 12 runs in a row

[HACKERS] [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)

Hi, the following statement triggers an assertion in tsearch: select ts_delete(array_to_tsvector('{smith,smith,smith}'::text[]), '{smith,smith}'::text[]); -- TRAP: FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511) regards, Andreas -- Sent via pgsql-hackers mailing

Re: [HACKERS] New version numbering practices

Greg Stark writes: > It would also be nice to have a tag or branch name for the development > branch. Uh, the branch name is "master". I doubt we want to change that. And you can't really have a tag on a branch, AFAIK --- a tag names a specific commit and can't ever be moved. I

[HACKERS] [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

Hi, testing with sqlsmith shows that the following assertion doesn't hold: FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200) The triggering statements always contain a call to pg_start_backup with the third argument 'true', i.e. it's trying to start an

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 3 August 2016 at 22:54, Álvaro Hernández Tortosa wrote: > > Hi list. > > As has been previously discussed (see > https://www.postgresql.org/message-id/BAY7-F17FFE0E324AB3B642C547E96890%40phx.gbl > for instance) varlena fields cannot accept the literal 0x00 value.

Re: [HACKERS] New version numbering practices

On Wed, Aug 3, 2016 at 5:27 PM, Tom Lane wrote: > Well, the rule would be that "REL_xx" is a branch, "REL_xx_yy" is a > release tag. Neither of these is confusable with old-style > branch or tag names. The alternative seems to be saying that > "REL_xx_STABLE" is a branch

Re: [HACKERS] Detecting skipped data from logical slots (data silently skipped)

On 3 August 2016 at 21:55, Greg Stark wrote: > I didn't follow all of that but I wonder if it isn't just that when you > restore from backup you should be creating a new slot? > Yes, you should. But when you restore a Pg instance from a disk snapshot or similar it can't tell it

Re: [HACKERS] New version numbering practices

On Wed, Aug 3, 2016 at 12:51 PM, Greg Stark wrote: > On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane wrote: > > I thought we'd pretty much done that cleanup during the cvs->git > > conversion? > > I guess I'm talking about tags. I'm not clear on the distinction >

Re: [HACKERS] New version numbering practices

Greg Stark writes: > On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane wrote: >> I thought we'd pretty much done that cleanup during the cvs->git >> conversion? > I guess I'm talking about tags. I'm not clear on the distinction > between tags and branches names in git.

Re: [HACKERS] New version numbering practices

On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane wrote: > I thought we'd pretty much done that cleanup during the cvs->git > conversion? I guess I'm talking about tags. I'm not clear on the distinction between tags and branches names in git. Prior to 8.0.0 we seem to have tagged the

Re: [HACKERS] OldSnapshotTimemapLock information is missing in monitoring.sgml file

> Pushed with minor fixes (white space and bumping the count for the tranche). > Thanks. I just missed to increase the LWLock count by one. With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 3 August 2016 at 15:54, Álvaro Hernández Tortosa wrote: > Given that 0x00 is a perfectly legal UTF-8 character, I conclude we're > strictly non-compliant. It's perhaps worth mentioning that 0x00 is valid ASCII too, and PostgreSQL has never stored that either. If you want

Re: [HACKERS] New version numbering practices

Peter Eisentraut writes: > On 8/1/16 9:10 PM, Alvaro Herrera wrote: >> I don't see any value to the _STABLE >> suffix, given the way we treat branches. > It would be nice to be able to tell easily from convention whether > something is a branch or a tag. Well,

Re: [HACKERS] Slowness of extended protocol

Tatsuo Ishii : > 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.

Re: [HACKERS] New version numbering practices

On 8/1/16 11:49 AM, Tom Lane wrote: > Somebody needs to come up with a patch implementing this changeover. Here is such a patch. It does not yet implement: > (External code will need some cue as > to how to format displays from PG_VERSION_NUM, so we should have a hard > and fast rule that major

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 8/3/16 11:47 AM, Kevin Grittner wrote: > On Wed, Aug 3, 2016 at 9:54 AM, Álvaro Hernández Tortosa > wrote: > >> What would it take to support it? > > Would it be of any value to support "Modified UTF-8"? > > https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8 Will this

Re: [HACKERS] New version numbering practices

On 8/1/16 9:10 PM, Alvaro Herrera wrote: > I don't see any value to the _STABLE > suffix, given the way we treat branches. It would be nice to be able to tell easily from convention whether something is a branch or a tag. Anyway, this is a question for many months from now. -- Peter Eisentraut

Re: [HACKERS] Possible duplicate release of buffer lock.

Kyotaro HORIGUCHI writes: > My point here is that if concurrent deletion can't be perfomed by > the current implement, this while loop could be removed and > immediately error out or log a message, >> if (P_ISDELETED(opaque) || opaque->btpo_next != target) >> {

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On Wed, Aug 3, 2016 at 9:54 AM, Álvaro Hernández Tortosa wrote: > What would it take to support it? Would it be of any value to support "Modified UTF-8"? https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8 -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise

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

On Wed, Aug 3, 2016 at 2:52 AM, Tal Walter wrote: > I'd appreciate if you could help me understand how I can research the > answers to these type of questions by myself. > Could I perhaps search the commit > comments somehow? Or perhaps a different approach to suggest? In

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

=?UTF-8?Q?=c3=81lvaro_Hern=c3=a1ndez_Tortosa?= writes: > As has been previously discussed (see > https://www.postgresql.org/message-id/BAY7-F17FFE0E324AB3B642C547E96890%40phx.gbl > > for instance) varlena fields cannot accept the literal 0x00 value. Yup. > What

Re: [HACKERS] regression test for extended query protocol

On 3 August 2016 at 10:53, Tom Lane wrote: > Tatsuo Ishii writes: > >>> 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

Re: [HACKERS] PostgreSQL 10 kick-off

On Tue, Aug 2, 2016 at 5:44 PM, Alvaro Herrera wrote: > > 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

Re: [HACKERS] OldSnapshotTimemapLock information is missing in monitoring.sgml file

On Wed, Aug 3, 2016 at 4:52 AM, Ashutosh Sharma wrote: > monitoring.sgml file has the list of all the wait event names that is > being monitored by pg_stat_activity but as one of the LWLock named > 'OldSnapshotTimemapLock' was added recently as the part of git commit >

[HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

Hi list. As has been previously discussed (see https://www.postgresql.org/message-id/BAY7-F17FFE0E324AB3B642C547E96890%40phx.gbl for instance) varlena fields cannot accept the literal 0x00 value. Sure, you can use bytea, but this hardly a good solution. The problem seems to be

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

Tal Walter writes: > The example questions I gave are just some of the questions I've tried to > search the answer to, using google and searching this mailing list > specifically, but I came up with nothing. Could I perhaps search the commit > comments somehow? Or perhaps a

Re: [HACKERS] regression test for extended query protocol

Tatsuo Ishii writes: >>> 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

Re: [HACKERS] Slowness of extended protocol

Tom Lane : > Bruce Momjian 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 only the ability to send parameter values out-of-line > instead >

Re: [HACKERS] Comment typo in tuplesort.c

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 http://momjian.us EnterpriseDB

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

On 3 August 2016 at 15:04, Kevin Grittner wrote: > My initial experience with PostgreSQL would have been entirely > different had I not found the community lists and benefited from > the assistance and collective wisdom found on them. The top non-sponsored link on google for

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

On Wed, Aug 3, 2016 at 8:58 AM, Alfred Perlstein wrote: > On Aug 3, 2016, at 3:29 AM, Greg Stark wrote: > >> Honestly the take-away I see in the Uber story is that they apparently >> had nobody on staff that was on -hackers or apparently even -general >> and

Re: [HACKERS] Slowness of extended protocol

Bruce Momjian 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 only the ability to send parameter values out-of-line instead >> of having to quote/escape them into SQL

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

> On Aug 3, 2016, at 3:29 AM, Greg Stark wrote: > >> > > Honestly the take-away I see in the Uber story is that they apparently > had nobody on staff that was on -hackers or apparently even -general > and tried to go it alone rather than involve experts from outside > their

Re: [HACKERS] Detecting skipped data from logical slots (data silently skipped)

I didn't follow all of that but I wonder if it isn't just that when you restore from backup you should be creating a new slot? On 3 Aug 2016 14:39, "Craig Ringer" wrote: > Hi all > > I think we have a bit of a problem with the behaviour specified for > logical slots, one

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

On 3 August 2016 at 11:37, Joshua Bay wrote: > Hi, > > 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. > To what end? What problem are you trying to solve? What

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

On 3 August 2016 at 05:14, Tom Lane wrote: > > In short, I think Uber's position that logical replication is somehow more > reliable than physical is just wishful thinking. If anything, my money > would be on the other way around: there's a lot less mechanism that can go >

[HACKERS] Detecting skipped data from logical slots (data silently skipped)

Hi all I think we have a bit of a problem with the behaviour specified for logical slots, one that makes it hard to prevent a outdated snapshot or backup of a logical-slot-using downstream from knowing it's missing a chunk of data that's been consumed from a slot. That's not great since slots are

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

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 before a new

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

Hi, 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. Thanks! Joshua

Re: [COMMITTERS] [HACKERS] Logical decoding

Thanks a lot for your help!! On Tue, Jul 12, 2016 at 4:42 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > On Mon, Jul 11, 2016 at 2:13 AM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > > > > On Mon, Jul 11, 2016 at 2:03 PM, Craig Ringer >

Re: [HACKERS] pg_ctl promote wait

Updated patch set for pg_ctl promote -w, incorporating AFAICT all of the previous reviews, in particular Michael Paquier's changes to the StartupXLOG() ordering, and rebasing on top of src/common/controldata_utils.c. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

  1   2   >