On Thu, Feb 28, 2019 at 11:50:16PM -0500, Tom Lane wrote:
> FWIW, I don't agree with Michael's suggestion above. A plain table is
> significantly different from a partitioned table with no children:
> you can store rows in the former but not the latter, and you can add
> partitions to the latter
On Fri, Mar 01, 2019 at 10:23:02AM +0300, Konstantin Knizhnik wrote:
> Yes, Yuri Kurenkov and Grigory Smalking did a lot in investigation
> of this problem.
> (the irony is that the problem detected by Yuri was caused by
> another bug in pg_probackup, but we thought that it was related with
>
On 01.03.2019 9:13, Michael Paquier wrote:
On Thu, Feb 28, 2019 at 11:15:53AM +0900, Michael Paquier wrote:
Could you add it to the next commit fest as a bug fix please? I think
that I will be able to look at that in details soon, but if not it
would be better to not lose track of your fix.
Hello Andres,
I think putting this into the control file is a seriously bad
idea. Postmaster interlocks against other postmasters running via
postmaster.pid.
Having a second interlock mechanism, in a different file, doesn't make
any sort of sense. Nor does it seem sane to have external
On 3/1/19 8:19 AM, Michael Paquier wrote:
On Thu, Feb 28, 2019 at 10:47:06PM -0500, Tom Lane wrote:
Michael Paquier writes:
So do we have anybody willing to take the glorious position of CFM for
this commit fest?
IIRC, Steele already said he'd do it.
Okay, fine for me of course if that's
On Thu, Feb 28, 2019 at 10:47:06PM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> So do we have anybody willing to take the glorious position of CFM for
>> this commit fest?
>
> IIRC, Steele already said he'd do it.
Okay, fine for me of course if that's the case! For what it's worth,
I
On Thu, Feb 28, 2019 at 10:52:52PM -0500, Tom Lane wrote:
> If you're suggesting that we disable that security restriction
> during extension creation, I really can't see how that'd be a
> good thing ...
No, I don't mean that. I was just wondering if someone can set
search_path within the SQL
On Thu, Feb 28, 2019 at 11:15:53AM +0900, Michael Paquier wrote:
> Could you add it to the next commit fest as a bug fix please? I think
> that I will be able to look at that in details soon, but if not it
> would be better to not lose track of your fix.
Okay, I have looked at your patch. And
(2019/03/01 14:17), Tatsuro Yamada wrote:
Attached patch is wip patch.
Is it possible to remove the following patch?
Because I registered the patch twice on CF Mar.
https://commitfest.postgresql.org/22/2049/
Please remove the above and keep this:
https://commitfest.postgresql.org/22/1779/
On Fri, Mar 1, 2019 at 3:36 AM Nikita Glukhov wrote:
> I can also offset to explicitly pass timezone info into jsonpath function
> using
> the special user dataype encapsulating struct pg_tz.
More interesting question is what would be the source of timezone. If
even you encapsulate timezone in
On Thu, Feb 28, 2019 at 7:51 PM Michael Paquier wrote:
> On Thu, Feb 28, 2019 at 11:07:47PM -0300, Martín Marqués wrote:
> > El 28/2/19 a las 15:13, David Steele escribió:
> > +
> > + The exclusive backup method is deprecated and should be avoided in
> > favor
> > + of the
On Thu, Feb 28, 2019 at 2:44 AM Robert Haas wrote:
>
> On Thu, Feb 14, 2019 at 5:17 AM Masahiko Sawada wrote:
> > Thank you. Attached the rebased patch.
>
> Here are some review comments.
Thank you for reviewing the patches!
>
> + started by a single utility command. Currently, the
Robert> This email thread is really short on clear demonstrations that X or Y
Robert> is useful.
It is useful when the whole database does **not** crash, isn't it?
Case A (==current PostgeSQL mode): syscache grows, then OOMkiller
chimes in, kills the database process, and it leads to the
Attached patch is wip patch.
Is it possible to remove the following patch?
Because I registered the patch twice on CF Mar.
https://commitfest.postgresql.org/22/2049/
Thanks,
Tatsuro Yamada
On 2019/02/23 6:02, Robert Haas wrote:
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
Amit Langote writes:
> On 2019/03/01 9:22, Michael Paquier wrote:
>> What I am writing next sounds perhaps a bit fancy, but in my opinion a
>> normal table is itself a partition tree, made of one single member:
>> itself.
> That's what we discussed, but it seems that we ended up allowing regular
Hi,
On 2019/03/01 9:22, Michael Paquier wrote:
> On Thu, Feb 28, 2019 at 04:32:03PM -0300, Alvaro Herrera wrote:
>> Yeah, looks good, please push.
>
> Done for this part.
>
>> I would opt for returning the empty set for legacy inheritance too.
>>
>> More generally, I think we should return
Michael Paquier writes:
> On Thu, Feb 28, 2019 at 10:13:17AM -0500, Tom Lane wrote:
>> Yeah, I think it's just because we won't search the pg_temp schema
>> for function or operator names, unless the calling SQL command
>> explicitly writes "pg_temp.foo(...)" or equivalent. That's an
>> ancient
Michael Paquier writes:
> So do we have anybody willing to take the glorious position of CFM for
> this commit fest?
IIRC, Steele already said he'd do it.
regards, tom lane
> I've made a patch to add CREATE OR REPLACE TRIGGER with some basic tests in
> triggers.sql.
>> I see there are two patch entries in the commitfest for this. Is that a
>> mistake? If so can you "Withdraw" one of them?
Oh my bad. Sorry, this time was my first time to register my patch !
Please
On Thu, Feb 28, 2019 at 07:41:11PM -0300, Alvaro Herrera wrote:
> We all seem to agree that REPLICA IDENTITY should recurse.
(entering the ring)
FWIW, I agree that having REPLICA IDENTITY recurse on partitions feels
more natural, as much as being able to use ALTER TABLE ONLY to only
update the
On Thu, Feb 28, 2019 at 11:07:47PM -0300, Martín Marqués wrote:
> El 28/2/19 a las 15:13, David Steele escribió:
> +
> + The exclusive backup method is deprecated and should be avoided in
> favor
> + of the non-exclusive backup method or
> + pg_basebackup.
> +
>
> Isn't
Hi David,
On Thu, Feb 28, 2019 at 11:05:33AM +0200, David Steele wrote:
> The 2019-03 CF is almost upon us. The CF will officially start at 00:00 AoE
> (12:00 UTC) on Friday, March 1st.
Thanks for the reminder.
> If you have a patch that has been Waiting on Author without any discussion
>
On Thu, Feb 28, 2019 at 10:13:17AM -0500, Tom Lane wrote:
> Yeah, I think it's just because we won't search the pg_temp schema
> for function or operator names, unless the calling SQL command
> explicitly writes "pg_temp.foo(...)" or equivalent. That's an
> ancient security decision, which we're
Hi all,
Joe's message here has reminded me that we have lacked a lot of error
handling around CloseTransientFile():
https://www.postgresql.org/message-id/c49b69ec-e2f7-ff33-4f17-0eaa4f2ce...@joeconway.com
This has been mentioned by Alvaro a couple of months ago (cannot find
the thread about that
On Tue, Feb 26, 2019 at 6:51 AM Li, Zheng wrote:
> Resend the patch with a whitespace removed so that "git apply patch" works
> directly.
>
>
Hi Zheng,
I have reviewed your patch. Good job except two issues I can find:
1. The patch would give wrong results when the inner side is empty. In
Unfortunately, contrib/jsonb_plpython still contain a lot of problems in error
handling that can lead to memory leaks:
- not all Python function calls are checked for the success
- not in all places PG exceptions are caught to release Python references
But it seems that this errors can happen
On Thu, Feb 28, 2019 at 9:59 AM John Naylor wrote:
>
> On Thu, Feb 28, 2019 at 10:25 AM Amit Kapila wrote:
> >
> > Here's an updated patch based on comments by you. I will proceed with
> > this unless you have any more comments.
>
> Looks good to me. I would just adjust the grammar in the
El 28/2/19 a las 15:13, David Steele escribió:
>
> It seems to me that the best way to discuss this is via a patch to the
> main documentation. I've written something to get us started:
>
> https://commitfest.postgresql.org/22/2042/
+
+ The exclusive backup method is deprecated and
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
For completeness, I'll mark this reviewed again. It passes
From: Ideriha, Takeshi/出利葉 健
> [Size=800, iter=1,000,000]
> Master |15.763
> Patched|16.262 (+3%)
>
> [Size=32768, iter=1,000,000]
> Master |61.3076
> Patched|62.9566 (+2%)
What's the unit, second or millisecond?
Why is the number of digits to the right of the decimal point?
Is the measurement
Hello.
At Thu, 28 Feb 2019 21:16:25 +0100, Tomas Vondra
wrote in
> > One biggest issue seems to be we don't know the total number of
# One *of* the biggest *issues*?
> > outer tuples before actually reading a null tuple. I doubt of
> > general shortcut for that. It also seems preventing
Hi, thanks for checking the patches!
On 02/28/19 19:36, Ramanarayana wrote:
> The below statement needs to be executed before running the query to
> replicate the issue
>
> update xmldata set data = regexp_replace(data::text, '791',
> '791')::xml;
If you are applying that update (and there is a
Hi,
On 2019-03-01 10:11:53 +0900, Michael Paquier wrote:
> One thing is that we don't protect a data folder to be started when it
> is in the process of being treated by an external tool, like
> pg_rewind, or pg_checksums. So having an extra flag in the control
> file, which can be used by
On Thu, Feb 28, 2019 at 01:07:23PM -0800, Andres Freund wrote:
> Huh? Postmaster.pid is written by the backend, pg_ctl just checks it to
> see if the backend has finished starting up etc. It's precisely what the
> backend uses to prevent two postmasters to start etc. It's also what say
>
On Thu, Feb 28, 2019 at 04:09:32PM -0500, Joe Conway wrote:
> Committed and push that way.
Thanks for committing a fix.
> By the way, while looking at this, I noted at least a couple of places
> where OpenTransientFile() is being passed O_RDWR when the usage is
> pretty clearly intended to be
On 2019-03-01 03:36:49 +0300, Nikita Glukhov wrote:
> Patch 1 is what we are going to commit in PG12.
I think it's too early to make that determination. I think there's a
good chance, but that this needs more independent review.
Hi,
The below statement needs to be executed before running the query to
replicate the issue
update xmldata set data = regexp_replace(data::text, '791',
'791')::xml;
On Thu, 28 Feb 2019 at 17:55, Pavel Stehule wrote:
>
>
> čt 28. 2. 2019 v 10:31 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>>
On Thu, Feb 28, 2019 at 04:32:03PM -0300, Alvaro Herrera wrote:
> Yeah, looks good, please push.
Done for this part.
> I would opt for returning the empty set for legacy inheritance too.
>
> More generally, I think we should return empty for anything that's
> either not
Hi,
Am Donnerstag, den 28.02.2019, 14:29 +0100 schrieb Fabien COELHO:
> > 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
> >
On Thu, Feb 28, 2019 at 3:40 PM Tom Lane wrote:
> Robert Haas writes:
> >>> just as a thought, what if we stopped assigning manual OIDs for new
> >>> catalog entries altogether, except for once at the end of each release
> >>> cycle?
>
> Actually ... that leads to an idea that wouldn't add any
On 3/1/19 12:41 AM, Peter Geoghegan wrote:
> On Thu, Feb 28, 2019 at 3:09 PM Tom Lane wrote:
>> The only thing that's really clear is that some senior committers don't
>> want to be bothered because they don't think there's a problem here that
>> justifies any additional expenditure of their
On Thu, Feb 28, 2019 at 3:09 PM Tom Lane wrote:
> The only thing that's really clear is that some senior committers don't
> want to be bothered because they don't think there's a problem here that
> justifies any additional expenditure of their time. Perhaps they are
> right, because I'd
Robert Haas writes:
>>> just as a thought, what if we stopped assigning manual OIDs for new
>>> catalog entries altogether, except for once at the end of each release
>>> cycle?
Actually ... that leads to an idea that wouldn't add any per-commit
overhead, or really much change at all to existing
Added Peter E to CC; question at the very end.
On 2019-Feb-20, Robert Haas wrote:
> Yeah, we could. I wonder, though, whether we should just make
> everything recurse. I think that's what people are commonly going to
> want, at least for partitioned tables, and it doesn't seem to me that
> it
On 3/1/19 12:03 AM, Thomas Munro wrote:
> On Fri, Mar 1, 2019 at 11:23 AM Jeff Janes wrote:
>> On Thu, Jan 31, 2019 at 1:32 AM Kyotaro HORIGUCHI
>> wrote:
>>> At Wed, 30 Jan 2019 18:19:05 +0100, Dmitry Dolgov <9erthali...@gmail.com>
>>> wrote in
>>>
A bit of adjustment after
Peter Geoghegan writes:
> On Thu, Feb 28, 2019 at 7:59 AM Robert Haas wrote:
>> OK. Well, I think that doing nothing is superior to this proposal,
>> for reasons similar to what Peter Eisentraut has already articulated.
>> And I think rather than blasting forward with your own preferred
>>
On Fri, Mar 1, 2019 at 11:23 AM Jeff Janes wrote:
> On Thu, Jan 31, 2019 at 1:32 AM Kyotaro HORIGUCHI
> wrote:
>> At Wed, 30 Jan 2019 18:19:05 +0100, Dmitry Dolgov <9erthali...@gmail.com>
>> wrote in
>> > A bit of adjustment after nodes/relation -> nodes/pathnodes.
>>
>> I had a look on this.
On Fri, Mar 1, 2019 at 11:31 AM Shawn Debnath wrote:
> On Thu, Feb 28, 2019 at 02:08:49PM -0800, Andres Freund wrote:
> > On 2019-03-01 09:48:33 +1300, Thomas Munro wrote:
> > > On Fri, Mar 1, 2019 at 7:24 AM Andres Freund wrote:
> > > > On 2019-02-28 13:16:02 -0500, Tom Lane wrote:
> > > > >
On Thu, Feb 28, 2019 at 7:59 AM Robert Haas wrote:
> I don't think this is the worst proposal ever. However, I also think
> that it's not unreasonable to raise the issue that writing OR
> reviewing OR committing a patch already involves adhering to a thicket
> of undocumented rules. When
On Fri, Mar 1, 2019 at 10:41 AM Shawn Debnath wrote:
> On Fri, Mar 01, 2019 at 10:33:06AM +1300, Thomas Munro wrote:
> > It doesn't make any sense to put things like clog or any other SLRU in
> > a non-default tablespace though. It's perfectly OK if not all smgr
> > implementations know how to
On 2019-Feb-20, Robert Haas wrote:
> On Wed, Feb 20, 2019 at 12:38 PM Alvaro Herrera
> wrote:
> > Maybe the ALL IN TABLESPACE and OWNED BY sub-forms should be split to a
> > separate para. I suggest:
> >
> > : This form changes the table's tablespace to the specified tablespace
> > : and
On Thu, Jan 31, 2019 at 1:32 AM Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello.
>
> At Wed, 30 Jan 2019 18:19:05 +0100, Dmitry Dolgov <9erthali...@gmail.com>
> wrote in aa+fz3guncutf52q1sufb7ise37tjpsd...@mail.gmail.com>
> > A bit of adjustment after nodes/relation ->
Andres Freund writes:
> FWIW, I think while distasteful, I could see us actually using oids,
> just ones that are small enough to fit into 16bit...
If we suppose that all smgrs must be built-in, that's not even much
of a restriction...
regards, tom lane
Alvaro Herrera writes:
> On 2019-Feb-28, Tom Lane wrote:
>> I wasn't really working on that for v12 --- I figured it was way
>> too late in the cycle to be starting on such a significant change.
> Oh, well, it certainly seems far too late *now*. However, what about
> the idea in
>
On 2019-03-01 09:48:33 +1300, Thomas Munro wrote:
> 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
Here's a rebased version of the main patch.
David Rowley writes:
> The only thing that I did to manage to speed the patch up was to ditch
> the additional NULL test in lnext(). I don't see why that's required
> since lnext(NULL) would have crashed with the old implementation.
I adopted this
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
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
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
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
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
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
> 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.
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
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
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
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
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
>>>
opment, 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
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
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
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
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
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
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
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
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
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.
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
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
č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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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,
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
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
1 - 100 of 156 matches
Mail list logo
