Re: FETCH FIRST clause PERCENT option

On Sun, Feb 10, 2019 at 2:22 AM Tomas Vondra wrote: > > I'm not sure I understand - are you saying every time the user does a > FETCH, we have to run the outer plan from scratch? I don't see why would > that be necessary? And if it is, how come there's no noticeable > performance difference? >

Re: WIP: Avoid creation of the free space map for small tables

On Thu, Feb 21, 2019 at 9:27 PM Alvaro Herrera wrote: > > I think this test is going to break on nonstandard block sizes. While > we don't promise that all tests work on such installs (particularly > planner ones), it seems fairly easy to cope with this one -- just use a > record size expressed

Re: proposal: variadic argument support for least, greatest function

so 23. 2. 2019 v 4:50 odesílatel Chapman Flack napsal: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: not tested > Documentation:tested,

Re: proposal: variadic argument support for least, greatest function

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed The latest patch provides the same functionality without growing

JIT on FreeBSD ARMv7

This seems to be the cleanest way to get a JIT build working on FreeBSD on the armv7 platform. Without this, it fails because the ABI functions __aeabi_ldivmod and so on are not found by the symbol lookup for JITted code. It's completely unclear who (llvm, freebsd, or us) is at fault here for it

Re: proposal: variadic argument support for least, greatest function

On 02/22/19 19:31, Chapman Flack wrote: > minmax_variadic-20190222-3.patch same as -2 but for doc grammar fix > (same fix made in minmax_variadic-20190221b.patch). and naturally I didn't attach it. -Chap diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 86ff4e5c9e..aa4e

Re: proposal: variadic argument support for least, greatest function

On 02/22/19 14:57, Pavel Stehule wrote: > I am sending second variant (little bit longer, but the main code is not > repeated) minmax_variadic-20190222-3.patch same as -2 but for doc grammar fix (same fix made in minmax_variadic-20190221b.patch). Regards, -Chap

Re: WIP: Avoid creation of the free space map for small tables

On 2019-Feb-22, Peter Geoghegan wrote: > I find it suspicious that there is another crash in pageinspect's > brin_page_items(), since like amcheck, pageinspect is a contrib module > that relies on BLCKSZ when allocating a local temp buffer. Ah. Maybe they just weren't rebuilt. -- Álvaro

Re: Refactoring the checkpointer's fsync request queue

On 2019-02-22 15:45:50 -0800, Shawn Debnath wrote: > > > Well even if you do it with individual segment cancel messages for > > > relations, you still need a way to deal with whole-database drops > > > (generating the cancels for every segment in every relation in the > > > database would be

Re: Prepared transaction releasing locks before deregistering its GID

On Fri, Feb 22, 2019 at 12:17:01PM +0100, Oleksii Kliukin wrote: > Thank you for updating the patch and sorry for the delay, it looks good to > me, the tests pass on my system. Thanks. I am still looking at this patch an extra time, so this may take at most a couple of days from my side. For

Re: Autovaccuum vs temp tables crash

On Fri, Feb 22, 2019 at 09:45:42AM -0500, Tom Lane wrote: > +1 ... maybe "(dropped)", because we tend to use parens for this sort > of thing, I think. +1. Using "dropped" sounds good to me in this context. Perhaps we could have something more fancy like what's used for dropped columns? It would

Re: Journal based VACUUM FULL

Greetings, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > On 2/22/19 2:15 PM, Andres Freund wrote: > > On 2019-02-21 16:27:06 +0100, Andreas Karlsson wrote: > >> I have not heard many requests for bringing back the old behavior, but I > >> could easily have missed them. Either way I

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Feb 22, 2019 at 12:35 PM Fujii Masao wrote: > > -1 for the removal. I think that there are still many users of an exclusive > > backup API, and it's not so easy to migrate their backup scripts so that > > only non-exclusive one is

Re: Refactoring the checkpointer's fsync request queue

Hi, On 2019-02-23 11:59:04 +1300, Thomas Munro wrote: > On Sat, Feb 23, 2019 at 11:48 AM Andres Freund wrote: > > > Yeah I suggested dynamic registration to avoid the problem that eg > > > src/backend/storage/sync.c otherwise needs to forward declare > > > md_tagtopath(), undofile_tagtopath(),

Re: WIP: Avoid creation of the free space map for small tables

On Fri, Feb 22, 2019 at 8:04 AM Alvaro Herrera wrote: > Wow, there's a lot less tests failing there than I thought there would > be. That increases hope that we can someday have them pass. +1 on not > making things worse. > > I think the crash in the amcheck test should be studied, one way or >

Re: Refactoring the checkpointer's fsync request queue

On Sat, Feb 23, 2019 at 11:48 AM Andres Freund wrote: > > Yeah I suggested dynamic registration to avoid the problem that eg > > src/backend/storage/sync.c otherwise needs to forward declare > > md_tagtopath(), undofile_tagtopath(), slru_tagtopath(), ..., or maybe > > #include etc, which seemed

Re: Refactoring the checkpointer's fsync request queue

Hi, On 2019-02-23 11:42:49 +1300, Thomas Munro wrote: > On Sat, Feb 23, 2019 at 11:15 AM Andres Freund wrote: > > On 2019-02-22 10:18:57 -0800, Shawn Debnath wrote: > > > I think using callbacks is the better path forward than having md or > > > other components issue an invalidate request for

Re: Refactoring the checkpointer's fsync request queue

On Sat, Feb 23, 2019 at 11:15 AM Andres Freund wrote: > On 2019-02-22 10:18:57 -0800, Shawn Debnath wrote: > > I think using callbacks is the better path forward than having md or > > other components issue an invalidate request for each and every segment > > which can get quite heavy handed for

Re: oddity with ALTER ROLE/USER

On 2/22/19 4:19 PM, Tom Lane wrote: > Joe Conway writes: >> I noticed that ALTER ROLE/USER succeeds even when called without any >> options: > >> postgres=# alter user foo; >> ALTER ROLE >> postgres=# alter role foo; >> ALTER ROLE >> postgres=# alter group foo; >> ERROR: syntax error at or near

Re: Refactoring the checkpointer's fsync request queue

Hi, On 2019-02-22 10:18:57 -0800, Shawn Debnath wrote: > I think using callbacks is the better path forward than having md or > other components issue an invalidate request for each and every segment > which can get quite heavy handed for large databases. I'm not sure I buy this. Unlinking

Re: monitoring CREATE INDEX [CONCURRENTLY]

Hmm, looks like a very bare-bones support for hash indexes does not require a lot of code, and gives a clear picture (you can sit all night watching the numbers go up, instead of biting your fingernails wondering if it'll be completed by dawn.) This part isn't 100% done -- it we would better to

Re: monitoring CREATE INDEX [CONCURRENTLY]

On 2019-Feb-13, Amit Langote wrote: > Doesn't the name amphasename sound a bit too generic, given that it can > only describe the phases of ambuild? Maybe ambuildphase? Hmm, yeah, maybe it does. I renamed it "ambuildphasename", since it's not about reporting the phase itself -- it's about

Re: Temporal Table Proposal

Em sex, 22 de fev de 2019 às 18:16, Paul Jungwirth escreveu: > > On 2/22/19 11:31 AM, Euler Taveira wrote: > > Em sex, 22 de fev de 2019 às 15:41, Ibrar Ahmed > > escreveu: > >> > >> While working on another PostgreSQL feature, I was thinking that we could > >> use a temporal table in

Re: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior

Hi, On 2019-02-22 16:27:28 -0500, Regina Obe wrote: > > I think there are probably other ways of fixing this query that won't have > > such dramatic effects; it doesn't really seem to need to use WITH, and I bet > > you could also tweak the WITH query to prevent inlining. > > Yes I know I can

Re: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior

On Fri, Feb 22, 2019 at 4:27 PM Regina Obe wrote: > It's going to make a lot of people hesitant to upgrade if they think they > need to revisit every CTE (that they intentionally wrote cause they thought > it would be materialized) to throw in a MATERIALIZED keyword. You might be right, but I

RE: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior

> I think there are probably other ways of fixing this query that won't have > such dramatic effects; it doesn't really seem to need to use WITH, and I bet > you could also tweak the WITH query to prevent inlining. Yes I know I can change THIS QUERY. I've changed other ones to work around

Re: oddity with ALTER ROLE/USER

Joe Conway writes: > I noticed that ALTER ROLE/USER succeeds even when called without any > options: > postgres=# alter user foo; > ALTER ROLE > postgres=# alter role foo; > ALTER ROLE > postgres=# alter group foo; > ERROR: syntax error at or near ";" > LINE 1: alter group foo; > That seems

Re: Temporal Table Proposal

On 2/22/19 11:31 AM, Euler Taveira wrote: Em sex, 22 de fev de 2019 às 15:41, Ibrar Ahmed escreveu: While working on another PostgreSQL feature, I was thinking that we could use a temporal table in PostgreSQL. Some existing databases offer this. I searched for any discussion on the

Re: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior

Andres Freund writes: > On 2019-02-22 15:33:08 -0500, Regina Obe wrote: >> The CTE change in PostgreSQL 12 broke several of PostGIS regression tests >> because many of our tests are negative tests that test to confirm we get >> warnings in certain cases. In the past, these would output 1 notice

oddity with ALTER ROLE/USER

I noticed that ALTER ROLE/USER succeeds even when called without any options: postgres=# alter user foo; ALTER ROLE postgres=# alter role foo; ALTER ROLE postgres=# alter group foo; ERROR: syntax error at or near ";" LINE 1: alter group foo; That seems odd, does nothing useful, and is

Re: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior

On Fri, Feb 22, 2019 at 3:33 PM Regina Obe wrote: > Historically PostGIS functions haven't been costed right and can't be > because they rely on INLINING of sql functions which gets broken when too > high of cost is put on functions. We have a ton of functions like these > that return composite

Re: [HACKERS] CLUSTER command progress monitor

On Fri, Dec 28, 2018 at 3:20 AM Tatsuro Yamada wrote: > This patch is rebased on HEAD. > I'll tackle revising the patch based on feedbacks next month. + Running VACUUM FULL is listed in pg_stat_progress_cluster + view because it uses CLUSTER command internally. See . It's not really true

Re: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior

Hi, On 2019-02-22 15:33:08 -0500, Regina Obe wrote: > The CTE change in PostgreSQL 12 broke several of PostGIS regression tests > because many of our tests are negative tests that test to confirm we get > warnings in certain cases. In the past, these would output 1 notice because > the CTE was

Re: [PATCH v20] GSSAPI encryption support

Stephen Frost writes: > * Robbie Harwood (rharw...@redhat.com) wrote: >> Stephen Frost writes: >>> * Robbie Harwood (rharw...@redhat.com) wrote: >>> Sure! I'll go ahead and hack up the checks and lucid stuff and get back to you. >>> >>> Great! I'll finish fleshing out the basics of

Re: unconstify equivalent for volatile

Hi, On 2019-02-22 12:38:35 +0100, Peter Eisentraut wrote: > On 2019-02-19 18:02, Andres Freund wrote: > > But even if we were to decide we'd want to keep a volatile in SetLatch() > > - which I think really would only serve to hide bugs - that'd not mean > > it's a good idea to keep it on all the

CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior

The CTE change in PostgreSQL 12 broke several of PostGIS regression tests because many of our tests are negative tests that test to confirm we get warnings in certain cases. In the past, these would output 1 notice because the CTE was materialized, now they output 1 for each column. An example

Re: proposal: variadic argument support for least, greatest function

pá 22. 2. 2019 v 13:42 odesílatel Pavel Stehule napsal: > Hi > > čt 21. 2. 2019 v 22:05 odesílatel Tom Lane napsal: > >> Pavel Stehule writes: >> > čt 21. 2. 2019 v 3:20 odesílatel Chapman Flack >> > napsal: >> >> I am not sure I have an answer to the objections being raised on >> grounds >>

Re: Journal based VACUUM FULL

On 2/22/19 2:15 PM, Andres Freund wrote: > Hi, > > On 2019-02-21 16:27:06 +0100, Andreas Karlsson wrote: >> I have not heard many requests for bringing back the old behavior, but I >> could easily have missed them. Either way I do not think there would be much >> demand for an in-place VACUUM

Re: Pluggable Storage - Andres's take

On Fri, Feb 22, 2019 at 11:19 AM Amit Khandekar wrote: > Thanks for the review. Attached v2. Thanks. I took this, combined it with Andres's v12-0040-WIP-Move-xid-horizon-computation-for-page-level-.patch, did some polishing of the code and comments, and pgindented. Here's what I ended up with;

Re: [Bug Fix] ECPG: could not use set xxx to default statement

Andrew Dunstan writes: > On 2/19/19 9:29 AM, Tom Lane wrote: >> Probably, somebody who's a better Perl programmer than me >> ought to take point on improving that. > Agreed. Not seeing any motion on this, here's a draft patch to make these scripts complain about missing semicolons. Against the

Re: Temporal Table Proposal

Em sex, 22 de fev de 2019 às 15:41, Ibrar Ahmed escreveu: > > While working on another PostgreSQL feature, I was thinking that we could use > a temporal table in PostgreSQL. Some existing databases offer this. I > searched for any discussion on the PostgreSQL mailing list, but could not > find

Re: Journal based VACUUM FULL

Hi, On 2019-02-21 16:27:06 +0100, Andreas Karlsson wrote: > I have not heard many requests for bringing back the old behavior, but I > could easily have missed them. Either way I do not think there would be much > demand for an in-place VACUUM FULL unless the index bloat problem is also > solved.

Re: libpq debug log

Robert Haas writes: > On Thu, Feb 21, 2019 at 7:52 PM Iwata, Aya wrote: >> Aside from problems with my current documentation which I will fix, >> could you explain more detail about the problem of the design? > We already have a PQtrace() facility that could be improved, and it > has been

Temporal Table Proposal

Hi, While working on another PostgreSQL feature, I was thinking that we could use a temporal table in PostgreSQL. Some existing databases offer this. I searched for any discussion on the PostgreSQL mailing list, but could not find any. Maybe my search wasn’t accurate enough: if anyone can point

Re: [patch] Add schema total size to psql \dn+

Robert Haas writes: > On Wed, Feb 20, 2019 at 5:26 PM Gilles Darold > wrote: >> The attached simple patch adds this feature. Is there any cons adding >> this information? > Well, it'll take time to compute, maybe a lot of time if the database > is big and the server is busy. Not sure how

Re: Autovaccuum vs temp tables crash

On Fri, Feb 22, 2019 at 1:14 PM Tom Lane wrote: > Why? It would likely be a significant amount of effort and added overhead, > to accomplish no obviously-useful goal. > > Note that all the temp schemas are made as owned by the bootstrap > superuser, so there is no real argument to be made that

Re: Autovaccuum vs temp tables crash

Robert Haas writes: > On Fri, Feb 22, 2019 at 12:54 PM Tom Lane wrote: >> Robert Haas writes: >>> On Fri, Feb 22, 2019 at 3:43 AM Magnus Hagander wrote: We are certainly not supposed to go DROP SCHEMA on the temp namespaces, ... >>> Actually, I think that's supposed to work. >> If it's

Re: some ri_triggers.c cleanup

On Fri, Feb 22, 2019 at 11:05 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > ri_triggers.c is endlessly long and repetitive. I want to clean it up a > bit (more). > Having just been down this road, I agree that a lot of cleanup is needed and possible. > I looked into all

Re: Remove Deprecated Exclusive Backup Mode

On Fri, Feb 22, 2019 at 12:35 PM Fujii Masao wrote: > -1 for the removal. I think that there are still many users of an exclusive > backup API, and it's not so easy to migrate their backup scripts so that > only non-exclusive one is used because of the reason I wrote in another > thread. >

Re: Autovaccuum vs temp tables crash

On Fri, Feb 22, 2019 at 12:54 PM Tom Lane wrote: > Robert Haas writes: > > On Fri, Feb 22, 2019 at 3:43 AM Magnus Hagander wrote: > >> We are certainly not supposed to go DROP SCHEMA on the temp namespaces, ... > > > Actually, I think that's supposed to work. > > If it's in active use by any

Re: speeding up planning with partitions

On Sat, Feb 23, 2019 at 02:54:35AM +0900, Amit Langote wrote: > > On Fri, Feb 22, 2019 at 09:45:38PM +0900, Amit Langote wrote: > > > I have updated the inheritance expansion patch. > > > > > > Patch 0001 rewrites optimizer/utils/inherit.c, so that it allows > > > > Thanks for your continued work

Re: Autovaccuum vs temp tables crash

Robert Haas writes: > On Fri, Feb 22, 2019 at 3:43 AM Magnus Hagander wrote: >> We are certainly not supposed to go DROP SCHEMA on the temp namespaces, ... > Actually, I think that's supposed to work. If it's in active use by any session (including your own), that's not going to have nice

Re: speeding up planning with partitions

Hi Justin, Thanks for checking. On Sat, Feb 23, 2019 at 1:59 AM Justin Pryzby wrote: > > On Fri, Feb 22, 2019 at 09:45:38PM +0900, Amit Langote wrote: > > I have updated the inheritance expansion patch. > > > > Patch 0001 rewrites optimizer/utils/inherit.c, so that it allows > > Thanks for your

Re: boolean and bool in documentation

Robert Haas writes: > On Thu, Feb 21, 2019 at 7:31 PM Tom Lane wrote: >> FWIW, I'm not excited about this. We accept "bool" and "boolean" >> interchangeably, and it does not seem like an improvement for the >> docs to use only one form. By that argument, somebody should go >> through the docs

Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

I have reproduced this bug on PostgreSQL version 10.7 and 11.2 using the steps described in Michael Powers' original report. The issue also still seems to be present even with the patch provided by Sergei Kornilov. Are there plans to address this issue any time soon or is there some way I can

Re: libpq host/hostaddr/conninfo inconsistencies

Hello Tom, However, it does not discuss that an IP can (and should, IMHO) be given through "host" if the point is to specify the target by its IP rather than a lookup shortcut. Ah, that's the crux of the problem. Yep! There are two ways that you could consider to be "best practice" for

Re: psql show URL with help

Euler Taveira writes: > I'm not suggesting that we replace version number using the latest > version URL. However, we could prevent URL to be shown if the version > mismatch. If psql wasn't backward compatible we shouldn't care but it > is. Someone could be confused as I said earlier. I tend to

Re: Remove Deprecated Exclusive Backup Mode

On Tue, Nov 27, 2018 at 12:13 PM David Steele wrote: > > Hackers, > > I propose we remove the deprecated exclusive backup mode of > pg_start_backup()/pg_stop_backup() for Postgres 12. -1 for the removal. I think that there are still many users of an exclusive backup API, and it's not so easy to

Re: Referential Integrity Checks with Statement-level Triggers

> > > While the idea to use the transition table is good, this approach probably > requires the trigger engine (trigger.c) to be adjusted, and that in a > non-trivial way. > It probably does. Several people with advanced knowledge of trigger.c expressed a desire to rebuild trigger.c from the

Re: Remove Deprecated Exclusive Backup Mode

On 2/22/19 6:32 PM, Stephen Frost wrote: * Magnus Hagander (mag...@hagander.net) wrote: On Mon, Feb 18, 2019 at 6:13 AM David Steele wrote: On 2/16/19 5:57 AM, Andres Freund wrote: I don't agree with a general 5 year deprecation window either. But it seems pretty clear that there's no

Re: speeding up planning with partitions

On Fri, Feb 22, 2019 at 09:45:38PM +0900, Amit Langote wrote: > I have updated the inheritance expansion patch. > > Patch 0001 rewrites optimizer/utils/inherit.c, so that it allows Thanks for your continued work on this. I applied v23 patch and imported one of our customers' schema, and ran

Re: Autovaccuum vs temp tables crash

On Fri, Feb 22, 2019 at 3:43 AM Magnus Hagander wrote: > We are certainly not supposed to go DROP SCHEMA on the temp namespaces, ... Actually, I think that's supposed to work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Mon, Feb 18, 2019 at 6:13 AM David Steele wrote: > > On 2/16/19 5:57 AM, Andres Freund wrote: > > > On 2019-01-05 13:19:20 -0500, Stephen Frost wrote: > > >> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > >>> On

Re: Pluggable Storage - Andres's take

On Thu, 21 Feb 2019 at 18:06, Robert Haas wrote: > > On Thu, Feb 21, 2019 at 6:44 AM Amit Khandekar wrote: > > Ok, so something like XidHorizonPrefetchState ? On similar lines, does > > prefetch_buffer() function name sound too generic as well ? > > Yeah, that sounds good. > And, yeah, then

Re: CPU costs of random_zipfian in pgbench

I also noticed that i is int in this function, but n is int64. That seems like an oversight. Indeed, that is a bug! Here is a v2 with hopefully better wording, comments and a fix for the bug you pointed out. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml

Re: CPU costs of random_zipfian in pgbench

There are pretty good approximations for s > 1.0 using Riemann zeta function and Euler derived a formula for the s = 1 case. I believe that's what random_zipfian() already uses, because for s > 1.0 it refers to "Non-Uniform Random Variate Generation" by Luc Devroye, and the text references

Re: [patch] Add schema total size to psql \dn+

On Wed, Feb 20, 2019 at 5:26 PM Gilles Darold wrote: > The attached simple patch adds this feature. Is there any cons adding > this information? Well, it'll take time to compute, maybe a lot of time if the database is big and the server is busy. Not sure how serious that problem can get. --

Re: WIP: Avoid creation of the free space map for small tables

On 2019-Feb-22, Amit Kapila wrote: > On Fri, Feb 22, 2019 at 1:57 AM Alvaro Herrera > wrote: > > > > I think this test is going to break on nonstandard block sizes. While > > we don't promise that all tests work on such installs (particularly > > planner ones), > > The reason for not pushing

some ri_triggers.c cleanup

ri_triggers.c is endlessly long and repetitive. I want to clean it up a bit (more). I looked into all these switch cases for the unimplemented MATCH PARTIAL option. I toyed around with how a MATCH PARTIAL implementation would actually look like, and it likely wouldn't use the existing code

Re: BRIN summarize autovac_report_workitem passes datname as relname

On 2019-Feb-20, Euler Taveira wrote: > Em qua, 20 de fev de 2019 às 15:56, Justin Pryzby > escreveu: > > > > I guess it should be database.namespace.relname ? > > > Yup. It is an oversight in 7526e10224f0792201e99631567bbe44492bbde4. Oops. Pushed fix. Thanks for reporting. -- Álvaro Herrera

Re: Protect syscache from bloating with negative cache entries

On Thu, Feb 21, 2019 at 1:38 AM Tsunakawa, Takayuki wrote: > Why don't we consider this just like the database cache and other DBMS's > dictionary caches? That is, > > * If you want to avoid infinite memory bloat, set the upper limit on size. > > * To find a better limit, check the hit ratio

Re: WIP: Avoid creation of the free space map for small tables

On Thu, Feb 21, 2019 at 9:59 PM Amit Kapila wrote: > The reason for not pushing much on making the test pass for > nonstandard block sizes is that when I tried existing tests, there > were already some failures. Sure, but let's not make things worse. -- Robert Haas EnterpriseDB:

RE: Protect syscache from bloating with negative cache entries

>From: Tsunakawa, Takayuki >Ideriha-san, >Could you try simplifying the v15 patch set to see how simple the code would >look or >not? That is: > >* 0001: add dlist_push_tail() ... as is >* 0002: memory accounting, with correction based on feedback >* 0003: merge the original 0003 and 0005, with

Re: libpq debug log

On Thu, Feb 21, 2019 at 7:52 PM Iwata, Aya wrote: > > I'm not really sure that I like the design of this patch in any way. > Aside from problems with my current documentation which I will fix, > could you explain more detail about the problem of the design? > I would like to improve my current

Re: partitioned tables referenced by FKs

Here's another rebase. The code is structured somewhat differently from the previous one, mostly because of the backpatched bugfixes, but also because of the changes in dependency handling. I think there's also at least one more bugfix to backpatch (included in 0003 here), related to whether

Re: boolean and bool in documentation

On Thu, Feb 21, 2019 at 7:31 PM Tom Lane wrote: > FWIW, I'm not excited about this. We accept "bool" and "boolean" > interchangeably, and it does not seem like an improvement for the > docs to use only one form. By that argument, somebody should go > through the docs and nuke every usage of

Re: Problems with plan estimates in postgres_fdw

Etsuro Fujita wrote: > (2019/02/08 21:35), Etsuro Fujita wrote: > > (2019/02/08 2:04), Antonin Houska wrote: > >> * regression tests: I think test(s) should be added for queries that have > >> ORDER BY clause but do not have GROUP BY (and also no LIMIT / OFFSET) > >> clause. I haven't noticed

Re: psql show URL with help

Em sex, 22 de fev de 2019 às 11:55, Tom Lane escreveu: > > The syntax summary that psql is showing is for its own version, and > I'd say the URL must be too. You can't even be sure that a corresponding > URL would exist in another version, so blindly inserting the server's > major version into a

Re: Reaping Temp tables to avoid XID wraparound

On Wed, Feb 20, 2019 at 3:41 AM Michael Paquier wrote: > On Tue, Feb 19, 2019 at 09:56:28AM +0100, Magnus Hagander wrote: > > 2. Or probably even better, just put it in PgBackendStatus? Overhead here > > is a lot cheaper than PGPROC. > > > > ISTM 2 is probably the most reasonable option here? >

Re: FOP warnings about id attributes in title tags

On 2/19/19 11:07 AM, Peter Eisentraut wrote: > On 2019-02-18 16:37, Peter Eisentraut wrote: >>> It appears that these are due to title elements having id tags. At >>> is says: >>> >>> When adding an |id| or |xml:id| attribute, put it on the

Re: psql show URL with help

Euler Taveira writes: > Em qui, 21 de fev de 2019 às 14:28, Peter Eisentraut > escreveu: >> URL: https://www.postgresql.org/docs/12/sql-analyze.html > What happen if I connect to an old server? Did it print URL according > to psql version or server version? psql prints help about its version >

Re: Checksum errors in pg_stat_database

On Fri, Feb 22, 2019 at 3:25 PM Magnus Hagander wrote: > > On Fri, Feb 22, 2019 at 3:23 PM Magnus Hagander wrote: >> >> >> >> On Fri, Feb 22, 2019 at 3:16 PM Julien Rouhaud wrote: >>> >>> On Fri, Feb 22, 2019 at 3:01 PM Magnus Hagander wrote: >>> > >>> > PFA is a patch to do this. >>> >>>

Re: psql show URL with help

On 2019-02-22 15:37, Euler Taveira wrote: > Em qui, 21 de fev de 2019 às 14:28, Peter Eisentraut > escreveu: >> URL: https://www.postgresql.org/docs/12/sql-analyze.html >> >> > What happen if I connect to an old server? Did it print URL according > to psql version or server version? psql

Re: Autovaccuum vs temp tables crash

Magnus Hagander writes: > The reason for the crash is 6d842be6c11, where Tom added an assert for > passing null into %s. But I don't think we can blame that patch for the > problem -- it's passing the NULL there in the first place that's the > problem. Indeed; this crash existed on some

Re: psql show URL with help

Em qui, 21 de fev de 2019 às 14:28, Peter Eisentraut escreveu: > > URL: https://www.postgresql.org/docs/12/sql-analyze.html > > What happen if I connect to an old server? Did it print URL according to psql version or server version? psql prints help about its version and if user wants

Re: Unnecessary checks for new rows by some RI trigger functions?

Antonin Houska writes: > Tom Lane wrote: >> It's quite easy to demonstrate that the second part of Antonin's >> proposed patch (ie, don't check for new rows in the FK table during >> ri_restrict) is wrong: > When I was running this example, the other session got blocked until the first >

Re: Checksum errors in pg_stat_database

On Fri, Feb 22, 2019 at 3:23 PM Magnus Hagander wrote: > > > On Fri, Feb 22, 2019 at 3:16 PM Julien Rouhaud wrote: > >> On Fri, Feb 22, 2019 at 3:01 PM Magnus Hagander >> wrote: >> > >> > PFA is a patch to do this. >> >> +void >> +pgstat_report_checksum_failure(void) >> +{ >> +

Re: Checksum errors in pg_stat_database

On Fri, Feb 22, 2019 at 3:16 PM Julien Rouhaud wrote: > On Fri, Feb 22, 2019 at 3:01 PM Magnus Hagander > wrote: > > > > PFA is a patch to do this. > > +void > +pgstat_report_checksum_failure(void) > +{ > + PgStat_MsgDeadlock msg; > > I think that you meant PgStat_MsgChecksumFailure :) > >

Re: Checksum errors in pg_stat_database

On Fri, Feb 22, 2019 at 3:01 PM Magnus Hagander wrote: > > PFA is a patch to do this. +void +pgstat_report_checksum_failure(void) +{ + PgStat_MsgDeadlock msg; I think that you meant PgStat_MsgChecksumFailure :) +/* -- + * pgstat_recv_checksum_failure() - + * + * Process a DEADLOCK

INSERT ... OVERRIDING USER VALUE vs GENERATED ALWAYS identity columns

So I started looking into the bug noted in [1], but before getting to multi-row inserts, I concluded that the current single-row behaviour isn't spec-compliant. In particular, Syntax Rule 11b of section 14.11 says that an INSERT statement on a GENERATED ALWAYS identity column must specify an

Re: postgres_fdw: another oddity in costing aggregate pushdown paths

Etsuro Fujita wrote: > As mentioned in the near thread, I think there is another oversight in > the cost estimation for aggregate pushdown paths in postgres_fdw, IIUC. > When costing an aggregate pushdown path using local statistics, we > re-use the estimated costs of implementing the

Re: Remove Deprecated Exclusive Backup Mode

On Mon, Feb 18, 2019 at 6:13 AM David Steele wrote: > On 2/16/19 5:57 AM, Andres Freund wrote: > > On 2019-01-05 13:19:20 -0500, Stephen Frost wrote: > >> Greetings, > >> > >> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > >>> On 12/12/2018 05:31, Robert Haas wrote: > Most

Re: Checksum errors in pg_stat_database

On Sat, Jan 12, 2019 at 5:16 AM David Steele wrote: > On 1/11/19 10:25 PM, Magnus Hagander wrote: > > On Fri, Jan 11, 2019 at 9:20 PM Tomas Vondra > > On 1/11/19 7:40 PM, Robert Haas wrote: > > > But I'm tentatively in favor of your proposal anyway, because it's > > > pretty simple

Re: Problems with plan estimates in postgres_fdw

Etsuro Fujita wrote: > Maybe, my explanation in that thread was not enough, but the changes proposed > by the patch posted there wouldn't obsolete the above. Let me explain using a > foreign-table variant of the example shown in the comments for > make_group_input_target(): > > SELECT a+b,

Re: Using old master as new replica after clean switchover

On Fri, Feb 22, 2019 at 5:47 AM Jehan-Guillaume de Rorthais wrote: > > On Thu, 21 Feb 2019 15:38:21 -0300 > Claudio Freire wrote: > > > On Tue, Feb 19, 2019 at 9:44 PM Michael Paquier wrote: > > > > > > On Tue, Feb 19, 2019 at 04:27:02PM -0800, RSR999GMAILCOM wrote: > > > > So wanted to

Re: proposal: variadic argument support for least, greatest function

Hi čt 21. 2. 2019 v 22:05 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > čt 21. 2. 2019 v 3:20 odesílatel Chapman Flack > > napsal: > >> I am not sure I have an answer to the objections being raised on grounds > >> of taste. To me, it's persuasive that GREATEST and LEAST are

Re: CPU costs of random_zipfian in pgbench

On 2/22/19 11:22 AM, Ants Aasma wrote: > On Sun, Feb 17, 2019 at 10:52 AM Fabien COELHO > wrote: > > > I'm trying to use random_zipfian() for benchmarking of skewed data > sets, > > and I ran head-first into an issue with rather excessive CPU costs. >

Re: unconstify equivalent for volatile

On 2019-02-19 18:02, Andres Freund wrote: > Because SetLatch() is careful to have a pg_memory_barrier() before > touching shared state and conversely so are ResetLatch() (and > WaitEventSetWait(), which already has no volatiles). And if we've got > this wrong they aren't safe for shared latches,

Re: Prepared transaction releasing locks before deregistering its GID

Hi, Michael Paquier wrote: > On Wed, Feb 20, 2019 at 11:50:42AM +0100, Oleksii Kliukin wrote: >> RecoverPreparedTransactions calls ProcessRecords with >> twophase_recover_callbacks right after releasing the TwoPhaseStateLock, so I >> think lock_held should be false here (matching the similar

Re: psql show URL with help

On Thu, Feb 21, 2019 at 6:28 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > As mentioned on > > > https://www.cybertec-postgresql.com/en/looking-at-mysql-8-with-postgresql-goggles-on/ > > how about this: > > => \h analyze > Command: ANALYZE > Description: collect statistics

  1   2   >