On Fri, Mar 20, 2020 at 8:24 PM Justin Pryzby wrote:
>
> On Fri, Mar 20, 2020 at 04:58:08PM +0530, Amit Kapila wrote:
> > See, how the attached looks? I have written a commit message as well,
> > see if I have missed anyone is from the credit list?
>
> Thanks for looking again.
>
> Couple tweaks:
On Sat, Mar 21, 2020 at 01:00:03PM +0530, Amit Kapila wrote:
> I have addressed your comments in the attached patch. Today, while
> testing error messages from various phases, I noticed that the patch
> fails to display error context if the error occurs during the truncate
> phase. The reason was
Attached 46th version of the patches.
On 20.03.2020 22:34, Pavel Stehule wrote:
čt 19. 3. 2020 v 23:57 odesílatel Nikita Glukhov
mailto:n.glu...@postgrespro.ru>> napsal:
Attached 45th version of the patches.
Nodes JsonFormat, JsonReturning, JsonPassing, JsonBehavior were fixed.
On 2020-03-17 15:47, Kartyshov Ivan wrote:
Synopsis
==
WAIT FOR [ANY | SOME | ALL] event [, event ...]
I'm confused as to what SOME would mean in this
command's syntax, but I can see you removed it
from gram.y since the last patch. Did you
decide to not implement it after all?
Also,
Hi, Peter!
On Sat, Mar 21, 2020 at 12:36 AM Peter Griggs wrote:
> I am hacking some GIST code for a research project and wanted clarification
> about what exactly a secondary split is in GIST.
Secondary split in GiST is the split by second and subsequent columns
on multicolumn GiST indexes. In
As it was discussed earlier, I added wait for statement into begin/start
statement.
Synopsis
==
BEGIN [ WORK | TRANSACTION ] [ transaction_mode[, ...] ] wait_for_event
where transaction_mode is one of:
ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ
COMMITTED |
On Sat, Mar 21, 2020 at 4:00 AM Robert Haas wrote:
>
> On Mon, Mar 16, 2020 at 2:03 AM Suraj Kharage
> wrote:
> > One more suggestion, recent commit (1933ae62) has added the PostgreSQL home
> > page to --help output.
>
> Good catch. Fixed. I also attempted to address the compiler warning
> you m
On 3/15/20 10:14 PM, Andreas Karlsson wrote:
> On 2/18/20 11:39 PM, Andrew Dunstan wrote:
>> This should fix the issue, it happened when I switched to using a
>> pre-generated cert/key.
>
> # Review
>
> The patch still applies and passes the test suite, both with openssl
> enabled and with it dis
On 3/19/20 4:10 AM, asaba.takan...@fujitsu.com wrote:
> Trailing space:
>
> 220 + X509v3 Subject Key Identifier:
> 222 + X509v3 Authority Key Identifier:
We're going to remove all the text, so this becomes moot.
>
> Missing "d"(password?):
>
> 121 +/* init hook for SSL,
On Sat, 21 Mar 2020 at 00:25, Jonah H. Harris
wrote:
> On Tue, Dec 31, 2019 at 8:35 AM Tom Lane wrote:
>
>> Peter Eisentraut writes:
>> > With the attached patch, I propose to enable the colored output by
>> > default in PG13.
>>
>> FWIW, I shall be setting NO_COLOR permanently if this gets com
On Sat, Mar 21, 2020 at 02:12:46PM +0900, Masahiko Sawada wrote:
> On Sat, 21 Mar 2020 at 05:30, Bruce Momjian wrote:
> > We should create an SQL-level master key that is different from the
> > block-level master key. By using separate keys, and not deriving them
> > from a single key, they keys
On 21.03.20 00:03, Justin Pryzby wrote:
+
+Host
+
+
+ See Server.
Or client. Or proxy at some layer or other intermediate thing. Maybe just
remove this.
Sometimes the term "host" is used in a different meaning. Therefor we shall
have this glossary entry for clarification
On 03/19/20 15:31, Stephen Frost wrote:
>> So I'm not certain how it should be categorized, or whether GSoC
>> rules should preclude it. Judgment call?
>
> You could ask on the GSoC mentors list, but I feel pretty confident that
> this doesn't meet the criteria to be a GSoC project, unfortunately.
> ---Original Message---
> From: Chapman Flack
>
> p.b uday, thank you for your interest and the time spent on your
> proposal; I'm sorry to be withdrawing this project. I hope you might
> continue to have interest in PostgreSQL generally or PL/Java specifically
> in the future.
>
On Sat, Mar 21, 2020 at 10:01:02AM -0400, Bruce Momjian wrote:
> On Sat, Mar 21, 2020 at 02:12:46PM +0900, Masahiko Sawada wrote:
> > On Sat, 21 Mar 2020 at 05:30, Bruce Momjian wrote:
> > > We should create an SQL-level master key that is different from the
> > > block-level master key. By using
On 03/21/20 10:36, inout wrote:
> Uday how about starting work on your proposal and claimed interest in
> PostgreSQL without worrying about the GSoC money ?
Naturally I'd be pleased with that outcome, but it's a purely personal
and situational decision that I wouldn't presume to press.
Regards,
On Sat, Mar 21, 2020 at 03:08:30PM +0100, Jürgen Purtz wrote:
> On 21.03.20 00:03, Justin Pryzby wrote:
> > > > > +
> > > > > +Host
> > > > > +
> > > > > +
> > > > > + See Server.
> > > > Or client. Or proxy at some layer or other intermediate thing. Maybe
> > > > just
> > >
Hey Folks!
irc://irc.freenode.net/postgresql link is not working and I am not able to
use the chat option to clear some doubt. here is an ss if you require it.
Thanking you in advance
Ananya Srivastava
[image: image.png]
On 2020-03-19 14:29, Mike Palmiotto wrote:
More specifically, I don't agree with the wholesale renaming of
auxiliary process to subprocess. Besides the massive code churn, the
I'm not sure I understand the argument here. Where do you see
wholesale renaming of AuxProc to Subprocess? Subprocess
On Tue, Mar 10, 2020 at 01:47:14PM +0100, Filip Janus wrote:
> Hello,
> After upgrade from 11.2 to 12.2 I found, that build of ecpg component depends
> on pgcommon_shlib and pgport_shlib. But build of ecpg doesn't include build
> of pgcommon_shlib and pgport_shlib. That means, if I want to build e
Pavel Stehule writes:
> So the patch has a problem with constant casting - unfortunately the mix of
> double precision variables and numeric constants is pretty often in
> Postgres.
Yeah. I believe the cause of that is that the patch thinks it can skip
passing an inline-function-free simple expr
On Sat, Mar 21, 2020 at 02:14:44PM -0400, Bruce Momjian wrote:
> On Tue, Mar 10, 2020 at 01:47:14PM +0100, Filip Janus wrote:
> > Hello,
> > After upgrade from 11.2 to 12.2 I found, that build of ecpg component
> > depends
> > on pgcommon_shlib and pgport_shlib. But build of ecpg doesn't include
On Sun, Mar 15, 2020 at 08:46:47PM -0700, Noah Misch wrote:
> On Wed, Mar 04, 2020 at 04:29:19PM +0900, Kyotaro Horiguchi wrote:
> > The attached is back-patches from 9.5 through master.
>
> Thanks. I've made some edits. I'll plan to push the attached patches on
> Friday or Saturday.
Pushed, af
Wow, this thread started in 2015. :-O
Date: Fri, 3 Jul 2015 00:05:24 +0200
---
On Sat, Mar 21, 2020 at 12:01:27PM -0700, Noah Misch wrote:
> On Sun, Mar 15, 2020 at 08:46:47PM -0700, Noah Misch wrote:
> > On Wed,
Bruce Momjian writes:
> On Sat, Mar 21, 2020 at 02:14:44PM -0400, Bruce Momjian wrote:
>> On Tue, Mar 10, 2020 at 01:47:14PM +0100, Filip Janus wrote:
>> > Hello,
>> > After upgrade from 11.2 to 12.2 I found, that build of ecpg component
>> > depends
>> > on pgcommon_shlib and pgport_shlib. But
so 21. 3. 2020 v 11:07 odesílatel Nikita Glukhov
napsal:
> Attached 46th version of the patches.
>
>
> On 20.03.2020 22:34, Pavel Stehule wrote:
>
>
> čt 19. 3. 2020 v 23:57 odesílatel Nikita Glukhov
> napsal:
>
>> Attached 45th version of the patches.
>>
>> Nodes JsonFormat, JsonReturning, Json
so 21. 3. 2020 v 19:24 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > So the patch has a problem with constant casting - unfortunately the mix
> of
> > double precision variables and numeric constants is pretty often in
> > Postgres.
>
> Yeah. I believe the cause of that is that the pa
On Thu, Mar 19, 2020 at 07:08:07PM +, Dean Rasheed wrote:
On Wed, 18 Mar 2020 at 19:31, Tomas Vondra wrote:
Attached is a rebased patch series, addressing both those issues.
I've been wondering why none of the regression tests failed because of
the 0.0 vs. 1.0 issue, but I think the expla
On Sat, Mar 21, 2020 at 07:30:48PM +, Dagfinn Ilmari Mannsåker wrote:
> Bruce Momjian writes:
>
> > On Sat, Mar 21, 2020 at 02:14:44PM -0400, Bruce Momjian wrote:
> >> On Tue, Mar 10, 2020 at 01:47:14PM +0100, Filip Janus wrote:
> >> > Hello,
> >> > After upgrade from 11.2 to 12.2 I found, th
On Sat, Mar 21, 2020 at 12:01:27PM -0700, Noah Misch wrote:
> Pushed, after adding a missing "break" to gist_identify() and tweaking two
> more comments. However, a diverse minority of buildfarm members are failing
> like this, in most branches:
>
> Mar 21 13:16:37 # Failed test 'wal_level = mi
Michael Paquier writes:
> The fun does not stop here. gcc is fine when using that for C and
> C++:
> #define StaticAssertStmt(condition, errmessage) \
>do { struct static_assert_struct { int static_assert_failure : (condition)
> ? 1 : -1; }; } while(0)
> #define StaticAssertExpr(condition, e
Hey Hackers,
We had a database running on debian where its disks went corrupted. And
currently is not possible to access those disks, unreadable.
For backup we used:
File System Level Backup
Continuous Archiving and Point-in-Time Recovery (PITR)
We used tablespaces for the entire database.
Whe
On Sat, 21 Mar 2020 at 09:38, Justin Pryzby wrote:
>
> On Thu, Mar 19, 2020 at 03:44:49PM -0700, Andres Freund wrote:
> > But uh, unfortunately the vacuum delay code just sleeps without setting
> > a wait event:
> ...
> > Seems like it should instead use a new wait event in the PG_WAIT_TIMEOUT
> >
On 3/21/20 9:18 AM, Andrew Dunstan wrote:
> On 3/19/20 4:10 AM, asaba.takan...@fujitsu.com wrote:
>
>
>
>> Trailing space:
>>
>> 220 + X509v3 Subject Key Identifier:
>> 222 + X509v3 Authority Key Identifier:
>
> We're going to remove all the text, so this becomes moot.
>
>
>> M
Hi,
> On Thu, Mar 19, 2020 at 03:44:49PM -0700, Andres Freund wrote:
> > But uh, unfortunately the vacuum delay code just sleeps without setting
> > a wait event:
> ...
> > Seems like it should instead use a new wait event in the PG_WAIT_TIMEOUT
> > class?
> >
> > Given how frequently we run into
On Fri, 2020-03-13 at 00:34 +, Andrew Gierth wrote:
> > > > > > "Justin" == Justin Pryzby writes:
>
> > On Thu, Mar 12, 2020 at 12:16:26PM -0700, Andres Freund wrote:
> >> Indeed, that's incorrect. Causes the number of buckets for the
> >> hashtable to be set higher - the size is just used
On Sat, Mar 21, 2020 at 5:25 PM Andres Freund wrote:
> > diff --git a/src/backend/access/gin/ginfast.c
> > b/src/backend/access/gin/ginfast.c
> > index 11d7ec067a..c99dc4a8be 100644
> > --- a/src/backend/access/gin/ginfast.c
> > +++ b/src/backend/access/gin/ginfast.c
> > @@ -892,7 +892,7 @@ ginIn
Hi,
On March 21, 2020 5:51:19 PM PDT, Peter Geoghegan wrote:
>On Sat, Mar 21, 2020 at 5:25 PM Andres Freund
>wrote:
>> > diff --git a/src/backend/access/gin/ginfast.c
>b/src/backend/access/gin/ginfast.c
>> > index 11d7ec067a..c99dc4a8be 100644
>> > --- a/src/backend/access/gin/ginfast.c
>> > +++
On Sat, Mar 21, 2020 at 5:53 PM Andres Freund wrote:
> My comment is entirely unrelated to GIN, but about the way the delay
> infrastructure manages state (in global vars).
The fact that ginInsertCleanup() uses "stats != NULL" to indicate
whether it is being called from within VACUUM or not is s
Hi,
On 2020-03-21 17:45:31 -0700, Jeff Davis wrote:
> Or, we can keep the 'additionalsize' argument but put it to work store
> the AggStatePerGroupData inline in the hash table. That would allow us
> to remove the 'additional' pointer from TupleHashEntryData, saving 8
> bytes plus the chunk header
Original, long thread
https://www.postgresql.org/message-id/flat/CAA4eK1%2Bnw1FBK3_sDnW%2B7kB%2Bx4qbDJqetgqwYW8k2xv82RZ%2BKw%40mail.gmail.com#b1745ee853b137043e584b500b41300f
diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml
index ab1b8c2398..140637983a 100644
--- a/doc/src/
Hi,
reply largely based on a quick IM conversation between Peter and me.
On 2020-03-04 17:13:33 -0800, Peter Geoghegan wrote:
> Both plans are very similar, really. The number of heap accesses and
> B-Tree index page accesses is exactly the same in each case.
Note that bitmap heap scans, current
On Sat, Mar 21, 2020 at 07:33:02PM -0700, Andres Freund wrote:
> While your recent btree work ensures that we get the heap tids for an
> equality lookup in heap order (right?),
I think when I tested the TID tiebreaker patch, it didn't help for our case,
which is for inequality: (timestamptz >= sta
Hi,
On 2020-03-21 23:53:05 -0500, Justin Pryzby wrote:
> On Sat, Mar 21, 2020 at 07:33:02PM -0700, Andres Freund wrote:
> > While your recent btree work ensures that we get the heap tids for an
> > equality lookup in heap order (right?),
>
> I think when I tested the TID tiebreaker patch, it didn
44 matches
Mail list logo
