Re: [HACKERS] [sqlsmith] Infinite recursion in bitshift

On Fri, Oct 14, 2016 at 3:31 PM, Tom Lane wrote: > Andreas Seltenreich writes: >> Tom Lane writes: >>> Seems sane, though I wonder if it'd be better to use -INT_MAX rather >>> than -VARBITMAXLEN. > >> I am undecided between those two. -INT_MAX might be a

Re: [HACKERS] [COMMITTERS] pgsql: Remove spurious word.

> On Thu, Oct 13, 2016 at 3:41 PM, Tatsuo Ishii wrote: >> Shouldn't this be back patched to REL9_6_STABLE as well? > > Sure. Please go ahead, or I can do it. Done. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php

Re: [HACKERS] [sqlsmith] Infinite recursion in bitshift

Andreas Seltenreich writes: > Tom Lane writes: >> Seems sane, though I wonder if it'd be better to use -INT_MAX rather >> than -VARBITMAXLEN. > I am undecided between those two. -INT_MAX might be a more precise fix > for the problem, but the extra distance to the danger zone

Re: [HACKERS] btree vacuum and suspended scans can deadlock

On Thu, Oct 13, 2016 at 4:44 PM, Tom Lane wrote: > I was about to suggest that maybe we didn't need cleanup locks in btree > indexes anymore now that SnapshotNow is gone, but I see that somebody > already altered nbtree/README to say this: > > : Therefore, a scan using an

Re: [HACKERS] [sqlsmith] Infinite recursion in bitshift

Merlin Moncure writes: > On Fri, Oct 14, 2016 at 3:31 PM, Tom Lane wrote: >> Poking around in varbit.c, I noticed some other places that were assuming >> that a typmod couldn't exceed VARBITMAXLEN. > Curious -- are there real world scenarios where this

Re: [HACKERS] COPY as a set returning function

> > > That sounds fantastic. It'd help this copy variant retain festure parity > > with normal copy. And it'd bring us closer to being able to FETCH in non > > queries. > > On second thought, though, this couldn't exactly duplicate the existing > COPY syntax, because COPY relies heavily on the

Re: [HACKERS] [PATCH] pg_filedump is broken

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested pg_filedump is a separate git repo, so the commitfest app won't let me mark

Re: [HACKERS] logical replication connection information management

On 12/10/16 19:59, Peter Eisentraut wrote: > > So functionality-wise, this looks pretty good, but there is some > awkwardness in how to wire this into the existing facilities, since a > server, also known as a foreign server, is currently tied to a foreign > data wrapper. I have currently

[HACKERS] Question about behavior of snapshot too old feature

Hi all, I have a question about behavior of snapshot too old feature. For example, I set old_snapshot_threshold = 1min and prepare a table and two terminals. And I did the followings steps. 1. [Terminal 1] Begin transaction and get snapshot data and wait. BEGIN TRANSACTION ISOLATION LEVEL

Re: [HACKERS] signal handling in plpython

On 10/13/2016 08:57 PM, Mario De Frutos Dieguez wrote: I come here asking for some advice/help because we're facing some unexpected behavior when we want to interrupt functions doing CPU intensive operations in plpython. Our problem is that we're not able to interrupt them when they're making

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

> > > It has recently come to my attention that this implementation is > problematic > > because it forces the batch to occur within a transaction; in other > words, > > there's no option for a non-transactional batch. > > That's not strictly the case. If you explicitly BEGIN and COMMIT, > those

Re: [HACKERS] proposal: session server side variables

Pavel Stehule wrote > Session server side variables are one major missing feature in PLpgSQL. I think this would also be useful outside of PL/pgSQL to support query level variables similar to what SQL Server does. -- View this message in context:

Re: [HACKERS] signal handling in plpython

Hi! Thank you very much for your quick response :) We're looking for a solution at plpython level. My two proposals are a quick "workaround" that let us interrupt using custom signal handlers in the python code at plpython level. But I'm looking for something more solid and your proposal, I've

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On 2016/10/12 12:21, Haribabu Kommi wrote: On Thu, Sep 29, 2016 at 3:45 PM, Haribabu Kommi > wrote: On Thu, Sep 22, 2016 at 3:05 AM, Alvaro Herrera > wrote:

Re: [HACKERS] [PATCH] pg_filedump is broken

Re: Aleksander Alekseev 2016-10-12 <20161012111527.GA17916@e733.localdomain> > Hello. > > First patch fixes: > > ``` > pg_filedump.c: In function ‘FormatItem’: > pg_filedump.c:994:18: error: ‘SizeOfIptrData’ undeclared (first use in > this function) >if (numBytes <

Re: [HACKERS] proposal: session server side variables

On 14 October 2016 at 13:30, Pavel Stehule wrote: > Hi, > > long time I working on this topic. Session server side variables are one > major missing feature in PLpgSQL. Now I hope, I can summarize requests for > implementation in Postgres: +1 > 2. accessed with

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 10/11/2016 08:56 AM, Pavel Stehule wrote: 2016-10-11 7:49 GMT+02:00 Heikki Linnakangas : Unfortunately there are cases that are fundamentally ambiguous. create type comptype as (intarray int[]); create function array_return() returns comptype[] as $$ return 1; $$

Re: [HACKERS] WIP: About CMake v2

Stas Kelvich wrote: Tried to generate Xcode project out of cmake, build fails on genbki.pl: can't locate Catalog.pm (which itself lives in src/backend/catalog/Catalog.pm) Thanks again! I have corrected your issue. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian

Re: [HACKERS] pg_basebackup stream xlog to tar

On Tue, Oct 4, 2016 at 12:05 AM, Michael Paquier wrote: > (Squashing two emails into one) > > On Fri, Sep 30, 2016 at 11:16 PM, Magnus Hagander > wrote: > > And here's yet another version, now rebased on top of the fsync and > nosync > > changes

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Mon, Feb 29, 2016 at 4:09 PM, Peter Geoghegan wrote: > To recap, the extension adds some SQL-callable functions that verify > certain invariant conditions hold within some particular B-Tree index. > These are the conditions that index scans rely on always being true. > The

Re: [HACKERS] Polyphase merge is obsolete

On Wed, Oct 12, 2016 at 10:16 AM, Heikki Linnakangas wrote: > Let's switch over to a simple k-way balanced merge. Because it's simpler. If > you're severely limited on memory, like when sorting 1GB of data with > work_mem='1MB' or less, it's also slightly faster. I'm not too

Re: [HACKERS] Non-empty default log_line_prefix

Re: Stephen Frost 2016-10-12 <20161012190732.gj13...@tamriel.snowman.net> > For my 2c, I'd rather have %m, but I definitely agree with Robert that > we need to do *something* here and if the only thing holding us back is > %t vs. %m, then let's just pick one and move on. I'll just hold my nose >

Re: [HACKERS] signal handling in plpython

On 10/14/2016 04:05 PM, Tom Lane wrote: I wrote: Py_AddPendingCall is safe to call from a signal handler? That would be ... quite remarkable. Yes, I believe it is. That's pretty much the raison d'être for Py_AddPendingCall(). I believe the Python interpreter itself implements signal

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 10/12/2016 11:11 AM, Michael Paquier wrote: And so we are back on that, with a new set: Great! I'm looking at this first one for now: - 0001, introducing pg_strong_random() in src/port/ to have the backend portion of SCRAM use it instead of random(). This patch is from Magnus who has

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net> > > I think it would help if we moved it to something like > > "internal/pg_xlog" and "internal/pg_clog". Keep the name but move it > > out of sight. > > I disagree that this will materially help with the issue. And

Re: [HACKERS] signal handling in plpython

Heikki Linnakangas writes: > It would be nice to have a solution for this in plpython itself, so that > the query cancel was turned into a Python exception. Patches for that > would be welcome. I think you could use Py_AddPendingCall() from > PostgreSQL's signal handler, to

Re: [HACKERS] signal handling in plpython

I wrote: > Py_AddPendingCall is safe to call from a signal handler? That would > be ... quite remarkable. I think that a much safer way to proceed would be, rather than asking "how can I mess with the signal handlers", asking "how can I make my python code act like it is sprinkled with

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 10/14/2016 03:08 PM, Heikki Linnakangas wrote: I spent some time whacking that around: Sigh, forgot attachment. Here you go. - Heikki >From 4b3000df3dc71ad41018a6606c92bc4a0adeb8f5 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Fri, 14 Oct 2016

Re: [HACKERS] Stats sender and 2pc minor problem

Tom Lane wrote: > Stas Kelvich writes: > > Statistics sender logic during usual commit and two-phase commit do not > > strictly matches each other and that leads to delta_live_tuples added to > > n_live_tup in case of truncate in two phase commit. > > Yeah, that code

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

On Thu, Oct 13, 2016 at 9:23 PM, Peter Eisentraut wrote: > On 10/12/16 7:38 PM, Andres Freund wrote: >>> We generally don't build test code during make world. >> FWIW, I find that quite annoying. I want to run make world with parallelism >> so >> I can run make

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

On Fri, Oct 14, 2016 at 8:33 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Oct 13, 2016 at 9:23 PM, Peter Eisentraut >> wrote: >>> Well, the purpose of make all or make world is to build the things that >>> are

Re: [HACKERS] process type escape for log_line_prefix

Re: Michael Paquier 2016-02-10

Re: [HACKERS] signal handling in plpython

On 10/14/2016 01:57 PM, Mario De Frutos Dieguez wrote: Hi! Thank you very much for your quick response :) We're looking for a solution at plpython level. My two proposals are a quick "workaround" that let us interrupt using custom signal handlers in the python code at plpython level. But I'm

Re: [HACKERS] make coverage-html on OS X

On 10/13/16 11:13 PM, Peter Eisentraut wrote: On 10/13/16 4:03 PM, Jim Nasby wrote: I've slowly stripped away my normal build environment; I'm now using baseline gcc (no ccache) with the following ./configure... anyone have any ideas how to debug/fix this? Which gcc are you using? gcc

Re: [HACKERS] [COMMITTERS] pgsql: Remove spurious word.

On Thu, Oct 13, 2016 at 3:41 PM, Tatsuo Ishii wrote: > Shouldn't this be back patched to REL9_6_STABLE as well? Sure. Please go ahead, or I can do it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

Robert Haas writes: > On Thu, Oct 13, 2016 at 9:23 PM, Peter Eisentraut > wrote: >> Well, the purpose of make all or make world is to build the things that >> are to be installed by make install or make install-world, which is the >> stuff

Re: [HACKERS] Renaming of pg_xlog and pg_clog

* Christoph Berg (m...@debian.org) wrote: > Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net> > > > I think it would help if we moved it to something like > > > "internal/pg_xlog" and "internal/pg_clog". Keep the name but move it > > > out of sight. > > > > I disagree

[HACKERS] Make getrusage() output a little more readable

The getrusage() output that is shown by VACUUM VERBOSE and other places has always been a little too terse and confusing for me. I propose to improve that a bit: -CPU 0.01s/0.08u sec elapsed 0.18 sec. +CPU: user: 0.08s, system: 0.01s, elapsed: 0.18s. Patch attached. I have also updated the

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Tom Lane wrote: >> Well, the buildfarm doesn't like that even a little bit. It seems that >> the MSVC compiler does not like seeing both "extern Datum foo(...)" and >> "extern PGDLLEXPORT Datum foo(...)", so anything that had an extern in >> a .h file is failing. There is also quite a bit of

Re: [HACKERS] proposal: session server side variables

2016-10-14 9:56 GMT+02:00 Craig Ringer : > On 14 October 2016 at 13:30, Pavel Stehule > wrote: > > Hi, > > > > long time I working on this topic. Session server side variables are one > > major missing feature in PLpgSQL. Now I hope, I can

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

> > > Of course, this is a > > relatively minor performance issue (especially when compared to the > overall > > performance benefits provided by batching), and providing an API > distinction > > between adding a Sync and flushing the buffer may over-complicate the > API. I > > just thought I'd

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 14 October 2016 at 22:15, Shay Rojansky wrote: > Unless I'm mistaken TCP_CORK is not necessarily going to work across all > platforms (e.g. Windows), although SO_LINGER (which is more standard) also > helps here. Yeah, true. You can also twiddle TCP_NODELAY on and off on

Re: [HACKERS] Question about behavior of snapshot too old feature

On Fri, Oct 14, 2016 at 1:40 PM, Masahiko Sawada wrote: > Hi all, > > I have a question about behavior of snapshot too old feature. > > For example, I set old_snapshot_threshold = 1min and prepare a table > and two terminals. > And I did the followings steps. > > 1.

Re: [HACKERS] Question about behavior of snapshot too old feature

On Fri, Oct 14, 2016 at 8:53 AM, Amit Kapila wrote: > On Fri, Oct 14, 2016 at 1:40 PM, Masahiko Sawada > wrote: >> For example, I set old_snapshot_threshold = 1min and prepare a table >> and two terminals. >> And I did the followings steps. >> >>

Re: [HACKERS] pg_dump, pg_dumpall and data durability

On Thu, Oct 13, 2016 at 2:49 PM, Michael Paquier wrote: > In my quest of making the backup tools more compliant to data > durability, here is a thread for pg_dump and pg_dumpall. Here is in a > couple of lines my proposal: > - Addition in _archiveHandle of a field to

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

Hi, On 2016-10-11 17:27:56 +0530, Dilip Kumar wrote: > I would like to propose a patch for pushing down the scan key to heap. I think that makes sense. Both because scankey eval is faster than generic expression eval, and because it saves a lot of function calls in heavily filtered cases. >

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net> > > We have a tool called pg_xlogdump in the standard installation. initdb > > has an option --xlogdir, pg_basebackup has --xlog and others. Renaming > > the xlog directory would make this all a bit confusing, unless we're

Re: [HACKERS] signal handling in plpython

On 14 October 2016 16:22:12 EEST, Tom Lane wrote: >Heikki Linnakangas writes: >> On 10/14/2016 04:05 PM, Tom Lane wrote: >>> I wrote: Py_AddPendingCall is safe to call from a signal handler? That >would be ... quite remarkable. > >> Yes, I

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

On Fri, Oct 14, 2016 at 9:43 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Oct 14, 2016 at 9:10 AM, Tom Lane wrote: >>> Well, if it has no tests *and* it's not getting installed, what's >>> the point of having it at all? > >>

Re: [HACKERS] signal handling in plpython

Heikki Linnakangas writes: > On 14 October 2016 16:22:12 EEST, Tom Lane wrote: >> I don't know whether to laugh or cry, but that code is a joke. Just >> silently fail if you can't get the lock? > Heh, ok, let me rephrase: I believe it's *intended* to be

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 10/14/16 9:06 AM, Stephen Frost wrote: > And internal/base and internal/global and internal/pg_... because > these shouldn't be touched by the users either. > > I don't think this would lead anywhere. It'd probably be easier to move the things that are *not* PG internal (eg: config files, et

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

Robert Haas writes: > On Fri, Oct 14, 2016 at 8:33 AM, Tom Lane wrote: >> Not sure. There's something to be said for the equivalence Peter >> proposes above. What you actually wanted, as I understood it, was >> that "make world" plus "make

[HACKERS] tablesample test failure with small TOAST_TUPLE_THRESHOLD

Today, I tried compiling with: -#define TOAST_TUPLE_THRESHOLD MaximumBytesPerTuple(TOAST_TUPLES_PER_PAGE) +#define TOAST_TUPLE_THRESHOLD 100 Most of the regression tests pass just fine, but the tablesample one experiences numerous failures. For example: SELECT t.id FROM test_tablesample

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

On Fri, Oct 14, 2016 at 9:10 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Oct 14, 2016 at 8:33 AM, Tom Lane wrote: >>> Not sure. There's something to be said for the equivalence Peter >>> proposes above. What you actually

Re: [HACKERS] Patch to implement pg_current_logfile() function

Re: To Gilles Darold 2016-10-14 <20161014125406.albrfj3qldiwj...@msg.df7cb.de> > A better design might be to return two columns instead: > > postgres=# select * from pg_current_logfile(); > stderr| csvlog >

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Oct 14, 2016 at 4:35 AM, Stephen Frost wrote: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > On 10/12/16 11:22 AM, Tom Lane wrote: > > > The main problem we're trying to fix here is people thinking that > > > something with "log" in the name

Re: [HACKERS] signal handling in plpython

On 2016-10-14 13:50:35 -0400, Tom Lane wrote: > Heikki Linnakangas writes: > > On 14 October 2016 16:22:12 EEST, Tom Lane wrote: > >> I don't know whether to laugh or cry, but that code is a joke. Just > >> silently fail if you can't get the lock? > > >

Re: [HACKERS] Renaming of pg_xlog and pg_clog

14.10.2016, 07:38, Peter Eisentraut kirjoitti: On 10/12/16 11:22 AM, Tom Lane wrote: The main problem we're trying to fix here is people thinking that something with "log" in the name contains discardable data. Just relocating the directory without renaming it won't improve that. I think it

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 14 October 2016 19:18:01 EEST, Jim Nasby wrote: >On 10/14/16 3:53 AM, Heikki Linnakangas wrote: >> Composite types in arrays must now be returned as >> Python tuples, not lists, to resolve the ambiguity. I.e. "[(col1, >col2), >> (col1, col2)]". > >Shouldn't dicts be

Re: [HACKERS] process type escape for log_line_prefix

On Fri, Oct 14, 2016 at 4:11 AM, Christoph Berg wrote: > Re: Michael Paquier 2016-02-10

Re: [HACKERS] signal handling in plpython

Hi! Following your ideas I've made a test [here ], only in plpython and seems to works pretty well. I've to make more tests and execute the postgres regress too. This ad-hoc solution could be enough for now, we

Re: [HACKERS] process type escape for log_line_prefix

Re: Jeff Janes 2016-10-14

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 10/14/16 3:53 AM, Heikki Linnakangas wrote: Composite types in arrays must now be returned as Python tuples, not lists, to resolve the ambiguity. I.e. "[(col1, col2), (col1, col2)]". Shouldn't dicts be allowed as well? I'm not sure they would automatically be considered as tuples (unlike

Re: [HACKERS] Renaming of pg_xlog and pg_clog

* Jim Nasby (jim.na...@bluetreble.com) wrote: > On 10/14/16 9:06 AM, Stephen Frost wrote: > >>> And internal/base and internal/global and internal/pg_... because > >>> these shouldn't be touched by the users either. > >>> > >>> I don't think this would lead anywhere. > >It'd probably be easier to

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

Robert Haas writes: > On Fri, Oct 14, 2016 at 9:10 AM, Tom Lane wrote: >> Well, if it has no tests *and* it's not getting installed, what's >> the point of having it at all? > It's intended as a demonstration of stuff you could do with background >

Re: [HACKERS] tablesample test failure with small TOAST_TUPLE_THRESHOLD

Robert Haas writes: > Today, I tried compiling with: > -#define TOAST_TUPLE_THRESHOLD MaximumBytesPerTuple(TOAST_TUPLES_PER_PAGE) > +#define TOAST_TUPLE_THRESHOLD 100 > Most of the regression tests pass just fine, but the tablesample one > experiences numerous

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Jim Nasby writes: > On 10/14/16 9:06 AM, Stephen Frost wrote: >> It'd probably be easier to move the things that are *not* PG internal >> (eg: config files, et al) *out* of the data directory and into somewhere >> sensible, like /etc ... > I do think it would be an

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Oct 14, 2016 at 9:56 AM, Tom Lane wrote: > Jim Nasby writes: > > On 10/14/16 9:06 AM, Stephen Frost wrote: > >> It'd probably be easier to move the things that are *not* PG internal > >> (eg: config files, et al) *out* of the data directory

Re: [HACKERS] Renaming of pg_xlog and pg_clog

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 10/12/16 11:22 AM, Tom Lane wrote: > > The main problem we're trying to fix here is people thinking that > > something with "log" in the name contains discardable data. Just > > relocating the directory without renaming it won't

Re: [HACKERS] Patch to implement pg_current_logfile() function

Hi Gilles, Re: Gilles Darold 2016-10-07 <0731a353-8d2f-0f2f-fcd5-fde77114c...@dalibo.com> > > What bugs me is the new file "pg_log_file" in PGDATA. It clutters the > > directory listing. I wouldn't know where else to put it, but you might > > want to cross-check that with the thread that is

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 14 October 2016 at 18:09, Shay Rojansky wrote: >> > It has recently come to my attention that this implementation is >> > problematic >> > because it forces the batch to occur within a transaction; in other >> > words, >> > there's no option for a non-transactional batch. >> >>

Re: [HACKERS] signal handling in plpython

Heikki Linnakangas writes: > On 10/14/2016 04:05 PM, Tom Lane wrote: >> I wrote: >>> Py_AddPendingCall is safe to call from a signal handler? That would >>> be ... quite remarkable. > Yes, I believe it is. >

Re: [HACKERS] Renaming of pg_xlog and pg_clog

* Magnus Hagander (mag...@hagander.net) wrote: > On Fri, Oct 14, 2016 at 4:35 AM, Stephen Frost wrote: > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > > On 10/12/16 11:22 AM, Tom Lane wrote: > > > > The main problem we're trying to fix here is people

Re: [HACKERS] Renaming of pg_xlog and pg_clog

* Christoph Berg (m...@debian.org) wrote: > Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net> > > > We have a tool called pg_xlogdump in the standard installation. initdb > > > has an option --xlogdir, pg_basebackup has --xlog and others. Renaming > > > the xlog directory

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Oct 14, 2016 at 11:48 AM, Stephen Frost wrote: > * Magnus Hagander (mag...@hagander.net) wrote: > > On Fri, Oct 14, 2016 at 4:35 AM, Stephen Frost > wrote: > > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > > > On 10/12/16

Re: [HACKERS] process type escape for log_line_prefix

On 2016-10-14 13:11:51 +0200, Christoph Berg wrote: > Re: Michael Paquier 2016-02-10 >

Re: [HACKERS] tablesample test failure with small TOAST_TUPLE_THRESHOLD

On Fri, Oct 14, 2016 at 9:51 AM, Tom Lane wrote: > Robert Haas writes: >> Today, I tried compiling with: >> -#define TOAST_TUPLE_THRESHOLD MaximumBytesPerTuple(TOAST_TUPLES_PER_PAGE) >> +#define TOAST_TUPLE_THRESHOLD 100 > >> Most of the regression

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

Robert Haas writes: > On Fri, Oct 14, 2016 at 9:43 AM, Tom Lane wrote: >> TBH, I can't muster much sympathy for that position. Make a test case >> for it, and the problem goes away, not to mention that confidence in >> whether it actually works (not

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

On Fri, Oct 14, 2016 at 11:00 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Oct 14, 2016 at 9:43 AM, Tom Lane wrote: >>> TBH, I can't muster much sympathy for that position. Make a test case >>> for it, and the problem goes

Re: [HACKERS] signal handling in plpython

Robert Haas writes: > On Fri, Oct 14, 2016 at 10:50 AM, Tom Lane wrote: >> I dunno. If the failure were very low-probability, you could maybe live >> with that behavior, but I'm not sure it is. Presumably the Python >> interpreter loop is taking that

Re: [HACKERS] signal handling in plpython

On Fri, Oct 14, 2016 at 10:50 AM, Tom Lane wrote: > Heikki Linnakangas writes: >> On 14 October 2016 16:22:12 EEST, Tom Lane wrote: >>> I don't know whether to laugh or cry, but that code is a joke. Just >>> silently fail if you can't

Re: [HACKERS] tablesample test failure with small TOAST_TUPLE_THRESHOLD

Robert Haas writes: > On Fri, Oct 14, 2016 at 9:51 AM, Tom Lane wrote: >> Possibly we should be using a less chintzy (ie slower) test there, >> but a change like this would inevitably change the outputs anyway. > OK. So passing the regression tests

Re: [HACKERS] Patch to implement pg_current_logfile() function

Le 14/10/2016 à 18:50, Christoph Berg a écrit : > Re: To Gilles Darold 2016-10-14 <20161014125406.albrfj3qldiwj...@msg.df7cb.de> >> A better design might be to return two columns instead: >> >> postgres=# select * from pg_current_logfile(); >> stderr|

Re: [HACKERS] Patch to implement pg_current_logfile() function

Re: Gilles Darold 2016-10-14 > Agree, the usability of the current version is really a pain. What I've > thought is that the function could return the csv log in all case when > csvlog is set in log_destination and the stderr log file when csvlog

[HACKERS] [sqlsmith] Infinite recursion in bitshift

Hi, sqlsmith just found another crasher: select bit '1' >> (-2^31)::int; This is due to an integer overflow in bitshiftright()/bitshiftleft() leading to them recursively calling each other. Patch attached. regards, Andreas >From cfdc425f75da268e1c2af08f936c59f34b69e577 Mon Sep 17 00:00:00

Re: [HACKERS] [sqlsmith] Infinite recursion in bitshift

Andreas Seltenreich writes: > sqlsmith just found another crasher: > select bit '1' >> (-2^31)::int; Nice catch :-) > This is due to an integer overflow in bitshiftright()/bitshiftleft() > leading to them recursively calling each other. Patch attached. Seems sane,

Re: [HACKERS] [sqlsmith] Infinite recursion in bitshift

Tom Lane writes: >> This is due to an integer overflow in bitshiftright()/bitshiftleft() >> leading to them recursively calling each other. Patch attached. > > Seems sane, though I wonder if it'd be better to use -INT_MAX rather > than -VARBITMAXLEN. I am undecided between those two. -INT_MAX