Re: New vacuum option to do only freezing

On Thu, Feb 28, 2019 at 2:46 AM Bossart, Nathan wrote: > > On 2/27/19, 2:08 AM, "Masahiko Sawada" wrote: > >> + if (skip_index_vacuum) > >> + appendStringInfo(&buf, ngettext("%.0f tuple is left as > >> dead.\n", > >> +

Re: Prevent extension creation in temporary schemas

Hi > I found that this strange error appears after making > temporary tables. > > test=> CREATE TEMPORARY TABLE temp (id int); > CREATE TABLE > test=> CREATE EXTENSION file_fdw WITH SCHEMA pg_temp_3; > ERROR: function file_fdw_handler() does not exist > > I would try to understand this problem for

RE: reloption to prevent VACUUM from truncating empty pages at the end of relation

From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com] > Robert used the phrase "attractive nuisance", which maybe sounds like a > good thing to have to a non native speaker, but it actually isn't -- he > was saying we should avoid a GUC at all, and I can see the reason for > that. I think we shou

RE: Problem with default partition pruning

Hosoya-san On Wed, Feb 27, 2019 at 6:51 AM, Yuzuko Hosoya wrote: > > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > > Sent: Wednesday, February 27, 2019 11:22 AM > > > > Hosoya-san, > > > > On 2019/02/22 17:14, Yuzuko Hosoya wrote: > > > Hi, > > > > > > I found the bug of default part

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

Tsunakawa, Takayuki wrote: > Why do you think that it's better for VACUUM command to have the option? I > think it's a > table property whose value is determined based on the application workload, > not per VACUUM > execution. Rather, I think GUC is more useful to determine the behavior of > t

extension patch of CREATE OR REPLACE TRIGGER

Dear hackers Hi there ! One past thread about introducing CREATE OR REPLACE TRIGGER into the syntax had stopped without complete discussion in terms of LOCK level. The past thread is this. I'd like to inherit this one. https://www.postgresql.org/message-id/flat/0B4917A40C80E34BBEC4BE1A7A9AB7E276F

RE: Protect syscache from bloating with negative cache entries

>From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com] >From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com] >> I measured the memory context accounting overhead using Tomas's tool >> palloc_bench, which he made it a while ago in the similar discussion. >> https://www.postgres

Re: get_controlfile() can leak fds in the backend

Hello Andres, Note that my concern is not about the page size, but rather that as more commands may change the cluster status by editing the control file, it would be better that a postmaster does not start while a pg_rewind or enable checksum or whatever is in progress, and currently there is

Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context

> > Hi, I have tested the three issues fixed in patch 001. Array Indexes issue is still there.Running the following query returns ERROR: more than one value returned by column XPath expression SELECT xmltable.* FROM (SELECT data FROM xmldata) x, LATERAL XMLTABLE('/ROWS/ROW' PASSING data C

2019-03 Starts Tomorrow

Hackers, The 2019-03 CF is almost upon us. The CF will officially start at 00:00 AoE (12:00 UTC) on Friday, March 1st. Any large, new patches submitted at the last moment will likely be labelled as targeting PG13 and may be pushed off to the 2017-07 CF as well. With the new labeling scheme

Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context

čt 28. 2. 2019 v 9:58 odesílatel Ramanarayana napsal: > Hi, > > I have tested the three issues fixed in patch 001. Array Indexes > issue is still there.Running the following query returns ERROR: more than > one value returned by column XPath expression > > SELECT xmltable.* > FROM (SELECT

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

Hi Andres, (2019/02/28 5:33), Andres Freund wrote: On 2015-05-12 14:24:34 -0400, Tom Lane wrote: I did a very basic update of your postgres_fdw patch to test this with, and attach that so that you don't have to repeat the effort. I'm not sure whether we want to try to convert that into somethi

Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context

Hi, I applied the following patches 0001-XML-XPath-comments-processing-instructions-array-ind.patch 0002-XML-avoid-xmlStrdup-if-possible.patch

Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context

čt 28. 2. 2019 v 10:49 odesílatel Ramanarayana napsal: > Hi, > I applied the following patches > > 0001-XML-XPath-comments-processing-instructions-array-ind.patch > > > 0002-XM

Re: FETCH FIRST clause PERCENT option

On Sun, Feb 24, 2019 at 12:27 AM Tomas Vondra wrote: > > I'm sorry, I still don't understand what the supposed problem is. I > don't think it's all that different from what nodeMaterial.c does, for > example. > > sorry for the noise .Attache is complete patch for incremental approach regards Sur

Re: extension patch of CREATE OR REPLACE TRIGGER

On Thu, 28 Feb 2019 at 21:44, Osumi, Takamichi wrote: > I've made a patch to add CREATE OR REPLACE TRIGGER with some basic tests in > triggers.sql. Hi, I see there are two patch entries in the commitfest for this. Is that a mistake? If so can you "Withdraw" one of them? -- David Rowley

Re: FETCH FIRST clause PERCENT option

Hello. At Sat, 23 Feb 2019 22:27:44 +0100, Tomas Vondra wrote in <81a5c0e9-c17d-28f3-4647-8a4659cdf...@2ndquadrant.com> > > > On 2/23/19 8:53 AM, Surafel Temesgen wrote: > > > > > > On Sun, Feb 10, 2019 at 2:22 AM Tomas Vondra > > mailto:tomas.von...@2ndquadrant.com>> wrote: > >   > > > >

Re: FETCH FIRST clause PERCENT option

At Thu, 28 Feb 2019 13:32:17 +0300, Surafel Temesgen wrote in > On Sun, Feb 24, 2019 at 12:27 AM Tomas Vondra > wrote: > > > > > I'm sorry, I still don't understand what the supposed problem is. I > > don't think it's all that different from what nodeMaterial.c does, for > > example. > > > > >

Re: get_controlfile() can leak fds in the backend

On 2/27/19 7:54 PM, Michael Paquier wrote: > On Wed, Feb 27, 2019 at 07:45:11PM -0500, Joe Conway wrote: >> It seems to me that OpenTransientFile() is more appropriate. Patch done >> that way attached. > > Works for me, thanks for sending a patch! While on it, could you > clean up the comment on

Re: get_controlfile() can leak fds in the backend

On Thu, Feb 28, 2019 at 07:11:04AM -0500, Joe Conway wrote: > Sure, will do. What are your thoughts on backpatching? This seems > unlikely to be a practical concern in the field, so my inclination is a > master only fix. I agree that this would unlikely become an issue as an error on the control f

Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context

čt 28. 2. 2019 v 10:31 odesílatel Pavel Stehule napsal: > > > čt 28. 2. 2019 v 9:58 odesílatel Ramanarayana > napsal: > >> Hi, >> >> I have tested the three issues fixed in patch 001. Array Indexes >> issue is still there.Running the following query returns ERROR: more >> than one value

Re: Libpq support to connect to standby server as priority

> Now I will add the another parameter target_server_type to choose the > primary, standby or prefer-standby > as discussed in the upthreads with a new GUC variable. > So just to further confuse things here is a use case for "preferPrimary" This is from the pgjdbc list. "if the master instance

Re: pgbench MAX_ARGS

On Wed, 27 Feb 2019 at 01:57, Simon Riggs wrote: > I've put it as 256 args now. I had a look at this and I see you've added some docs to mention the number of parameters that are allowed; good. + pgbench supports up to 256 variables in one + statement. However, the code does not allow 256 v

Re: Online verification of checksums

Hallo Mickael, So I have now changed behaviour so that short writes count as skipped files and pg_verify_checksums no longer bails out on them. When this occors a warning is written to stderr and their overall count is also reported at the end. However, unless there are other blocks with bad c

Re: Why don't we have a small reserved OID range for patch revisions?

On Wed, Feb 27, 2019 at 10:41 PM Tom Lane wrote: > In short, this situation may look fine from the perspective of a committer > with a relatively short timeline to commit, but it's pretty darn awful for > everybody else. The only way to avoid a ~ 50% failure rate is to choose > OIDs above 6K, and

Re: BUG #15623: Inconsistent use of default for updatable view

On Thu, 28 Feb 2019 at 07:47, Amit Langote wrote: > > +if (attrno == 0) > +elog(ERROR, "Cannot set value in column %d to > DEFAULT", i); > > Maybe: s/Cannot/cannot/g > Ah yes, you're right. That is the convention. > +Assert(list_length(sublist) == num

Re: Removing unneeded self joins

Hi Tom, Thanks for the update. On 2/22/19 03:25, Tom Lane wrote: * My compiler was bitching about misplaced declarations, so I moved some variable declarations accordingly. I couldn't help noticing that many of those wouldn't have been a problem in the first place if you were following projec

Re: Row Level Security − leakproof-ness and performance implications

On Wed, Feb 27, 2019 at 6:03 PM Joe Conway wrote: > Patch for discussion attached. So... you're just going to replace ALL error messages of any kind with "ERROR: missing error text" when this option is enabled? That sounds unusable. I mean if I'm reading it right this would get not only message

Re: Drop type "smgr"?

On Thu, Feb 28, 2019 at 1:03 AM Thomas Munro wrote: > The type smgr has only one value 'magnetic disk'. ~15 years ago it > also had a value 'main memory', and in Berkeley POSTGRES 4.2 there was > a third value 'sony jukebox'. Back then, all tables had an associated > block storage manager, and i

Re: Optimze usage of immutable functions as relation

On 2/18/19 03:20, Tom Lane wrote: The dummy-relation stuff I referred to has now been merged, so there's really no good reason not to revise the patch along that line. I'll try to post the revised implementation soon. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com T

Re: Remove Deprecated Exclusive Backup Mode

On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe wrote: > > Fujii Masao wrote: > > So, let me clarify the situations; > > > > (3) If backup_label.pending exists but recovery.signal doesn't, the server > >ignores (or removes) backup_label.pending and do the recovery > >starting the pg_c

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 9:12 AM, Robert Haas wrote: > On Wed, Feb 27, 2019 at 6:03 PM Joe Conway wrote: >> Patch for discussion attached. > > So... you're just going to replace ALL error messages of any kind with > "ERROR: missing error text" when this option is enabled? That sounds > unusable. I mean if I'

Re: Row Level Security − leakproof-ness and performance implications

On Thu, 28 Feb 2019 at 14:13, Robert Haas wrote: > A wild idea might be to let > proleakproof take on three values: yes, no, and maybe. When 'maybe' > functions are involved, we tell them whether or not the current query > involves any security barriers, and if so they self-censor. > Does self-c

Re: Remove Deprecated Exclusive Backup Mode

Greetings, * Fujii Masao (masao.fu...@gmail.com) wrote: > On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe wrote: > > > > Fujii Masao wrote: > > > So, let me clarify the situations; > > > > > > (3) If backup_label.pending exists but recovery.signal doesn't, the server > > >ignores (or removes

Add exclusive backup deprecation notes to documentation

Hackers, It has been noted on multiple threads, such as [1], that it would be good to have additional notes in the documentation to explain why exclusive backups have been deprecated and why they should be avoided when possible. This patch attempts to document the limitations of the exclusiv

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 9:52 AM, Dean Rasheed wrote: > Does self-censoring mean that they might still throw an error for some > inputs, but that error won't reveal any information about the input > values? That's not entirely consistent with my understanding of the > definition of leakproof That's the questio

Re: Row Level Security − leakproof-ness and performance implications

On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote: Hi, Robert, it has been a while :) > > So... you're just going to replace ALL error messages of any kind with > "ERROR: missing error text" when this option is enabled? That sounds > unusable. I mean if I'm reading it right this would get not

Re: Remove Deprecated Exclusive Backup Mode

On 2/28/19 4:44 PM, Fujii Masao wrote: On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe wrote: Fujii Masao wrote: So, let me clarify the situations; (3) If backup_label.pending exists but recovery.signal doesn't, the server ignores (or removes) backup_label.pending and do the recovery

Re: Drop type "smgr"?

Thomas Munro writes: > On Thu, Feb 28, 2019 at 7:37 PM Tom Lane wrote: >> Thomas Munro writes: >>> Our current thinking is that smgropen() should know how to map a small >>> number of special database OIDs to different smgr implementations >> Hmm. Maybe mapping based on tablespaces would be a

Re: Prevent extension creation in temporary schemas

Sergei Kornilov writes: >> test=> CREATE EXTENSION file_fdw WITH SCHEMA pg_temp_3; >> ERROR: function file_fdw_handler() does not exist > This behavior seems as not related to extensions infrastructure: Yeah, I think it's just because we won't search the pg_temp schema for function or operator n

Re: [HACKERS] Incomplete startup packet errors

Re: Magnus Hagander 2016-04-13 > > >>> It's fairly common to see a lot of "Incomplete startup packet" in the > > >>> logfiles caused by monitoring or healthcheck connections. > > > > >> I've also seen it caused by port scanning. > > > > > Yes, definitely. Question there might be if that's actuall

PostgreSQL Participates in GSoC 2019!

Greetings, I'm pleased to announce that we have been accepted by Google to participate in the Summer of Code (GSoC) 2019 program. This will be the 12th time that the PostgreSQL Project will provide mentorship for students to help develop new features for PostgreSQL. We have the chance to accept st

Re: Why don't we have a small reserved OID range for patch revisions?

Robert Haas writes: > This seems like a big piece of new mechanism being invented > to solve an occasional annoyance. Your statistics are not convincing > at all: you're arguing that this is a big problem because 2-3% of > pending patches current have an issue here, and some others have in > the p

Re: Drop type "smgr"?

On Thu, Feb 28, 2019 at 10:09 AM Tom Lane wrote: > The real reason I'm concerned about this, though, is that for either > a database or a tablespace, you can *not* get away with having a magic > OID just hanging in space with no actual catalog row matching it. > If nothing else, you need an entry

Re: Re: Continue work on changes to recovery.conf API

On 11/27/18 4:36 PM, Peter Eisentraut wrote: On 27/11/2018 13:21, David Steele wrote: I would prefer a specific file that will be auto-included into postgresql.conf when present but be ignored when not present. Some settings are generally ephemeral (recovery_target_time) and it would be nice fo

Re: Re: Continue work on changes to recovery.conf API

Hi Peter, On 11/27/18 5:34 PM, Stephen Frost wrote: Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: On 27/11/2018 13:21, David Steele wrote: I would prefer a specific file that will be auto-included into postgresql.conf when present but be ignored when not present. So

Re: Re: Row Level Security − leakproof-ness and performance implications

Joshua Brindle writes: > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote: >> So... you're just going to replace ALL error messages of any kind with >> "ERROR: missing error text" when this option is enabled? That sounds >> unusable. I mean if I'm reading it right this would get not only >> me

Re: Why don't we have a small reserved OID range for patch revisions?

On Thu, Feb 28, 2019 at 10:27 AM Tom Lane wrote: > Robert Haas writes: > > This seems like a big piece of new mechanism being invented > > to solve an occasional annoyance. Your statistics are not convincing > > at all: you're arguing that this is a big problem because 2-3% of > > pending patches

Re: [HACKERS] WIP: Aggregation push-down

Tom Lane wrote: > Antonin Houska writes: > > Michael Paquier wrote: > >> Latest patch set fails to apply, so moved to next CF, waiting on > >> author. > > > Rebased. > > This is in need of rebasing again :-(. I went ahead and pushed the 001 > part, since that seemed fairly uncontroversial.

Re: Re: Row Level Security − leakproof-ness and performance implications

On Thu, Feb 28, 2019 at 10:49 AM Tom Lane wrote: > > Joshua Brindle writes: > > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote: > >> So... you're just going to replace ALL error messages of any kind with > >> "ERROR: missing error text" when this option is enabled? That sounds > >> unusable.

Re: Drop type "smgr"?

Robert Haas writes: > My first intuition was the same as yours -- that we should use the > tablespace to decide which smgr is relevant -- but I now think that > intuition was wrong. Even if you use the tablespace OID to select the > smgr, it doesn't completely solve the problem you're worried abo

Re: Add exclusive backup deprecation notes to documentation

David Steele wrote: > This patch attempts to document the limitations of the exclusive mode. Thanks! > + > + The primary issue with the exclusive method is that the > + backup_label file is written into the data > directory > + when pg_start_backup is called and remains until > +

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 11:03 AM, Joshua Brindle wrote: > How is leakproof defined WRT Postgres? Generally speaking a 1 bit >From the CREATE FUNCTION reference page: LEAKPROOF indicates that the function has no side effects. It reveals no information about its arguments other than by its return value. For ex

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 11:03 AM, Joshua Brindle wrote: > On Thu, Feb 28, 2019 at 10:49 AM Tom Lane wrote: >> >> Joshua Brindle writes: >> > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote: >> >> So... you're just going to replace ALL error messages of any kind with >> >> "ERROR: missing error text" when t

Re: Row Level Security − leakproof-ness and performance implications

On Thu, Feb 28, 2019 at 11:14 AM Joe Conway wrote: > > > Although, and Joe may hate me for saying this, I think only the > > non-constants should be redacted to keep some level of usability for > > regular SQL errors. Maybe system errors like the above should be > > removed from client messages in

Re: Index INCLUDE vs. Bitmap Index Scan

I wrote: > Tomas Vondra writes: >> I do recall a discussion about executing expressions on index tuples >> during IOS (before/without inspecting the heap tuple). I'm too lazy to >> search for the thread now, but I recall it was somehow related to >> leak-proof-ness. And AFAICS none of the "div" pr

Re: Row Level Security − leakproof-ness and performance implications

On Thu, Feb 28, 2019 at 11:14 AM Joe Conway wrote: > > Although, and Joe may hate me for saying this, I think only the > > non-constants should be redacted to keep some level of usability for > > regular SQL errors. Maybe system errors like the above should be > > removed from client messages in g

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 11:37 AM, Robert Haas wrote: > On Thu, Feb 28, 2019 at 11:14 AM Joe Conway wrote: >> > Although, and Joe may hate me for saying this, I think only the >> > non-constants should be redacted to keep some level of usability for >> > regular SQL errors. Maybe system errors like the above sh

Re: Row Level Security − leakproof-ness and performance implications

On Thu, Feb 28, 2019 at 11:44 AM Joe Conway wrote: > No, and Tom stated as much too, but life is all about tradeoffs. Some > people will find this an acceptable compromise. For those that don't > they don't have to use it. IMHO we tend toward too much nannyism too often. Well, I agree with that,

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 11:50 AM, Robert Haas wrote: > On Thu, Feb 28, 2019 at 11:44 AM Joe Conway wrote: >> No, and Tom stated as much too, but life is all about tradeoffs. Some >> people will find this an acceptable compromise. For those that don't >> they don't have to use it. IMHO we tend toward too much n

Re: Row Level Security − leakproof-ness and performance implications

On Thu, Feb 28, 2019 at 12:05 PM Joe Conway wrote: > I think that would affect the server logs too, no? Worth thinking about > though... Yeah, I suppose so, although there might be a way to work around that. > Also manually marking all functions leakproof is far less convenient > than turning of

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 12:28 PM, Robert Haas wrote: > Mmmph. If your customers always have a non-production instance where > problems from production can be easily reproduced, your customers are > not much like our customers. Well I certainly did not mean to imply that this is always the case ;-) But I thin

Re: Drop type "smgr"?

On Thu, Feb 28, 2019 at 11:06 AM Tom Lane wrote: > It's certainly possible/likely that we're going to end up needing to > widen buffer tags to represent the smgr explicitly, because some use > cases are going to need a real database spec, some are going to need > a real tablespace spec, and some m

Re: Drop type "smgr"?

Robert Haas writes: > On Thu, Feb 28, 2019 at 1:03 AM Thomas Munro wrote: >> Nothing seems to break if you remove it (except for some tests using >> it in an incidental way). See attached. > FWIW, +1 from me. To be clear, I'm not objecting to the proposed patch either. I was just wondering wh

plpgsql variable named as SQL keyword

Hi one user of plpgsql_check reported interesting error message create or replace function omega.foo(a int) returns int as $$ declare offset integer := 0; begin return offset + 1; end; $$ language plpgsql; postgres=# select omega.foo(10); ERROR: query "SELECT offset + 1" returned 0 columns CO

Re: Bloom index cost model seems to be wrong

On Sun, Feb 24, 2019 at 11:09 AM Jeff Janes wrote: > I've moved this to the hackers list, and added Teodor and Alexander of the > bloom extension, as I would like to hear their opinions on the costing. > My previous patch had accidentally included a couple lines of a different thing I was workin

Re: Drop type "smgr"?

Hi, On 2019-02-28 12:36:50 -0500, Robert Haas wrote: > Well, Andres will probably complain about that. He thinks, IIUC, that > the buffer tags are too wide already and that it's significantly > hurting performance on very very common operations - like buffer > lookups. Correct. Turns out especia

Re: Remove Deprecated Exclusive Backup Mode

On 2/27/19 8:22 PM, Christophe Pettus wrote: On Feb 26, 2019, at 11:38, Magnus Hagander wrote: That should not be a wiki page, really, that should be part of the main documentation. I was just suggesting using a wiki page to draft it before we drop it into the main documentation. I'm ope

Question about pg_upgrade from 9.2 to X.X

Dear SMEs I have finally decided to move forward after great hospitality in Version 9.2.24 :-) First i attempted to upgrade from 9.2.24 to 10.7, but its failed with following error during Check Mode. could not load library "$libdir/hstore": ERROR: could not access file "$libdir/hstore": No such

Re: Drop type "smgr"?

Shawn Debnath writes: > On Thu, Feb 28, 2019 at 10:35:50AM -0500, Robert Haas wrote: >> Also, I don't see why we'd need a fake pg_database row in the first >> place. IIUC, the OID counter wraps around to FirstNormalObjectId, so >> nobody should have a database with an OID less than that value. >

Re: Drop type "smgr"?

Hi, On 2019-02-28 10:02:46 -0800, Shawn Debnath wrote: > We have scripts under catalog directory that can check to ensure OIDs > aren't re-used accidentally. However, we still have to define an entry > in a catalog somewhere and I was proposing creating a new one, > pg_storage_managers?, to tra

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

Hi, Thanks for the quick response. On 2019-02-28 18:28:37 +0900, Etsuro Fujita wrote: > > I'm currently > > converting the EPQ machinery to slots, and in course of that I (with > > Horiguchi-san's help), converted RefetchForeignRow to return a slot. But > > there's currently no in-core user of

Re: plpgsql variable named as SQL keyword

Pavel Stehule writes: > Maybe we should to disallow variables named as sql reserved keyword. That would just break existing code. There are lots of other examples where you can get away with such things. We've expended quite a lot of sweat to avoid reserving more names than we had to in plpgsql

Re: Question about pg_upgrade from 9.2 to X.X

Hi Please try with below commands. Let we want to upgrade v6 to v11. Note: I installed my binary inside result folder. export OLDCLUSTER=./6_EDBAS/EDBAS/result export NEWCLUSTER=./11_EDBAS/EDBAS/result ./11_EDBAS/EDBAS/result/bin/pg_upgrade --old-bindir=$OLDCLUSTER/bin --new-bindir=$NEWCLUSTER/bi

Re: Drop type "smgr"?

On 2019-02-28 13:16:02 -0500, Tom Lane wrote: > Shawn Debnath writes: > > On Thu, Feb 28, 2019 at 10:35:50AM -0500, Robert Haas wrote: > >> Also, I don't see why we'd need a fake pg_database row in the first > >> place. IIUC, the OID counter wraps around to FirstNormalObjectId, so > >> nobody sho

Re: plpgsql variable named as SQL keyword

čt 28. 2. 2019 v 19:20 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > Maybe we should to disallow variables named as sql reserved keyword. > > That would just break existing code. There are lots of other > examples where you can get away with such things. > > We've expended quite a lot

Re: Question about pg_upgrade from 9.2 to X.X

Thanks Mahendra for quick response. I have followed same way, only difference i didn't bringup Source ( 9.2), But not sure how that will resolve libraries issue. All i tried with --check mode only Thanks, On Thu, Feb 28, 2019 at 10:23 AM Mahendra Singh wrote: > Hi > Please try with below comm

Re: Question about pg_upgrade from 9.2 to X.X

Hello pgsql-hackers seems wrong list for such question. > could not load library "$libdir/hstore": ERROR:  could not access file > "$libdir/hstore": No such file or directory > could not load library "$libdir/adminpack": ERROR:  could not access file > "$libdir/adminpack": No such file or direc

Re: partitioned tables referenced by FKs

On 2019-Feb-28, Amit Langote wrote: > Hi Alvaro, > > I looked at the latest patch and most of the issues/bugs that I was going > to report based on the late January version of the patch seem to have been > taken care of; sorry that I couldn't post sooner which would've saved you > some time. Th

Re: Question about pg_upgrade from 9.2 to X.X

Thank you very much Sergei, Yes, i want to get rid of old extension, Could you please share the query to find extension which is using pg_reorg. Regards, On Thu, Feb 28, 2019 at 10:27 AM Sergei Kornilov wrote: > Hello > > pgsql-hackers seems wrong list for such question. > > > could not loa

Re: Bloom index cost model seems to be wrong

Jeff Janes writes: > Should we be trying to estimate the false positive rate and charging > cpu_tuple_cost and cpu_operator_cost the IO costs for visiting the table to > recheck and reject those? I don't think other index types do that, and I'm > inclined to think the burden should be on the user

Re: [RFC] [PATCH] Flexible "partition pruning" hook

On Wed, Feb 27, 2019 at 12:36 PM Peter Eisentraut wrote: > > To rephrase this: You have a partitioned table, and you have a RLS > policy that hides certain rows, and you know based on your business > logic that under certain circumstances entire partitions will be hidden, > so they don't need to

Re: Question about pg_upgrade from 9.2 to X.X

Hi > Yes, i want to get rid of old extension, Could you please share the query to > find extension which is using pg_reorg. pg_reorg is name for both tool and extension. Check every database in cluster with, for example, psql command "\dx" or read pg_dumpall -s output for some CREATE EXTENSION

Re: Question about pg_upgrade from 9.2 to X.X

here is the data, postgres=# \c template1 You are now connected to database "template1" as user "postgres". template1=# \dx List of installed extensions Name | Version | Schema | Description -+-++-- plpgsql |

Re: POC: converting Lists into arrays

David Rowley writes: > On Thu, 28 Feb 2019 at 09:26, Tom Lane wrote: >> 0001 below does this. I found a couple of places that could use >> forfive(), as well. I think this is a clear legibility and >> error-proofing win, and we should just push it. > I've looked over this and I agree that it's

Re: pg_partition_tree crashes for a non-defined relation

On 2019-Feb-28, Michael Paquier wrote: > On Wed, Feb 27, 2019 at 03:48:08PM -0300, Alvaro Herrera wrote: > > I just happened to come across the result of this rationale in > > pg_partition_tree() (an SRF) while developing a new related function, > > pg_partition_ancestors(), and find the resulting

Re: some ri_triggers.c cleanup

On 2019-02-25 17:17, Corey Huinker wrote: > Right, this makes a lot of sense, similar to how ri_restrict() combines > RESTRICT and NO ACTION. > > > I'm pretty sure that's where I got the idea, yes.  Committed, including your patch. -- Peter Eisentraut http://www.2ndQuadran

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

ed out by David. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 0001-multivariate-MCV-lists-20190228.patch.gz Description: application/gzip 0002-multivariate-histograms-20190228.patch.gz Description: application/gzip

Re: FETCH FIRST clause PERCENT option

On 2/28/19 12:26 PM, Kyotaro HORIGUCHI wrote: > Hello. > > At Sat, 23 Feb 2019 22:27:44 +0100, Tomas Vondra > wrote in > <81a5c0e9-c17d-28f3-4647-8a4659cdf...@2ndquadrant.com> >> >> >> On 2/23/19 8:53 AM, Surafel Temesgen wrote: >>> >>> >>> On Sun, Feb 10, 2019 at 2:22 AM Tomas Vondra >>> mailt

Re: Protect syscache from bloating with negative cache entries

On Wed, Feb 27, 2019 at 3:16 AM Ideriha, Takeshi wrote: > I'm afraid I may be quibbling about it. > What about users who understand performance drops but don't want to > add memory or decrease concurrency? > I think that PostgreSQL has a parameter > which most of users don't mind and use is as def

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On 2019-Feb-28, Tom Lane wrote: > Alvaro Herrera writes: > > Hopefully we'll get Tom's patch that addresses the failure-to-truncate > > issues in pg12. > > Hm, are you speaking of the handwaving I did in > https://www.postgresql.org/message-id/2348.1544474...@sss.pgh.pa.us > ? > > I wasn't real

Re: Segfault when restoring -Fd dump on current HEAD

On 2019-Feb-27, Dmitry Dolgov wrote: > > On Wed, Feb 27, 2019 at 1:32 PM Alvaro Herrera > > wrote: > > > > > > I think it would be better to just put back the .defn = "" (etc) to the > > > > ArchiveEntry calls. > > > > > > Then we should do this not only for defn, but for owner and dropStmt too.

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Tue, Feb 26, 2019 at 5:10 PM Robert Haas wrote: > Aside from these problems, I think I have spotted a subtle problem in > 0001. I'll think about that some more and post another update. 0001 turned out to be guarding against the wrong problem. It supposed that if we didn't get a coherent view

Re: Segfault when restoring -Fd dump on current HEAD

> On Thu, Feb 28, 2019 at 9:24 PM Alvaro Herrera > wrote: > > Pushed, thanks. I added the reminder comment I mentioned. Thank you, sorry for troubles.

Re: Drop type "smgr"?

On Fri, Mar 1, 2019 at 7:24 AM Andres Freund wrote: > On 2019-02-28 13:16:02 -0500, Tom Lane wrote: > > Shawn Debnath writes: > > > Another thought: my colleague Anton Shyrabokau suggested potentially > > > re-using forknumber to differentiate smgrs. We are using 32 bits to > > > map 5 entries to

Re: get_controlfile() can leak fds in the backend

Hi, On 2019-02-28 09:54:48 +0100, Fabien COELHO wrote: > > If we were to want to do more here, ISTM the right approach would use > > the postmaster pid file, not the control file. > > ISTM that this just means re-inventing a manual poor-featured > race-condition-prone lock API around another file

Re: get_controlfile() can leak fds in the backend

On 2/28/19 7:20 AM, Michael Paquier wrote: > On Thu, Feb 28, 2019 at 07:11:04AM -0500, Joe Conway wrote: >> Sure, will do. What are your thoughts on backpatching? This seems >> unlikely to be a practical concern in the field, so my inclination is a >> master only fix. > > I agree that this would u

Re: Drop type "smgr"?

On Fri, Mar 1, 2019 at 4:09 AM Tom Lane wrote: > Thomas Munro writes: > > On Thu, Feb 28, 2019 at 7:37 PM Tom Lane wrote: > >> Thomas Munro writes: > >>> Our current thinking is that smgropen() should know how to map a small > >>> number of special database OIDs to different smgr implementation

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

Dear all, we rebased our temporal normalization patch on top of 554ebf687852d045f0418d3242b978b49f160f44 from 2019-02-28. On 9/7/18 1:02 PM, Peter Moser wrote: > The syntax is > SELECT * FROM (r NORMALIZE s USING() WITH(period_r, period_s)) c; Please find all information about our decisions and

Re: Index Skip Scan

On Wed, Feb 20, 2019 at 11:33 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On Fri, Feb 1, 2019 at 8:24 PM Jesper Pedersen < > jesper.peder...@redhat.com> wrote: > > > > Dmitry and I will look at this and take it into account for the next > > version. > > In the meantime, just to not forget,

  1   2   >