Hi
Consider the following cascading standby setup with PostgreSQL 12:
- there exists a running primary "A"
- standby "B" is cloned from primary "A" using "pg_basebackup
--write-recovery-conf"
- standby "C" is cloned from standby "B" using "pg_basebackup
--write-recovery-conf"
So far, so good,
13.06.2019, 13:57, "Michael Paquier" :
> On Thu, Jun 13, 2019 at 01:25:38PM +0600, Timur Birsh wrote:
>> Just to be sure, a new command line argument needs to be added for
>> reporting the numbers? Should it implies --verbose argument?
>
> Nope. I mean that running a SELECT count(*) can be costly
On Tue, May 14, 2019 at 1:24 PM Daniel Gustafsson wrote:
> > On 14 May 2019, at 03:49, Thomas Munro wrote:
>
> > I propose a new option $SUBJECT so that users can at least add a level of
> > indirection and put the password in a file.
>
> +1, seems like a reasonable option to give.
Thanks for th
Hello,
13.06.2019 11:10, Michael Paquier wrote:
> The last trace of tss_htup has been removed as of 2e3da03, and I see
> no mention of it in the related thread. Andres, is that intentional
> for table AMs to keep a trace of a currently-fetched tuple for a TID
> scan or something that can be remove
čt 13. 6. 2019 v 2:37 odesílatel Tom Lane napsal:
> Greg Stark writes:
> > The proposals I see above are "commontype", "supertype", "anycommontype",
> > and various abbreviations of those. I would humbly add "compatibletype".
> > Fwiw I kind of like commontype.
> > Alternately an argument could
I've previously noted upthread (along with several others), that I
don't see a good reason to limit this new capability to index only
scans. In addition to the reasons upthread, this also prevents using
the new feature on physical replicas since index only scans require
visibility map (IIRC) inform
On Wed, Jun 5, 2019 at 12:14 PM Rafia Sabih wrote:
> > > 2) Provide some fallback at execution time. For example, we might watch
> > > the size of the group, and if we run into an unexpectedly large one we
> > > might abandon the incremental sort and switch to a "full sort" mode.
> >
> > Are there
On Thu, Jun 13, 2019 at 01:22:16PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > The release notes say:
> >
> >
>
> >
> > Improve optimization of self-joins (Tom Lane)
> >
> >
>
> > I don't think that's an accurate summary of those two items. It's
> > t
David Rowley writes:
> On Fri, 14 Jun 2019 at 13:54, Bruce Momjian wrote:
>> Have you tested the performance impact?
> I did some and posted earlier in the thread:
> https://postgr.es/m/cakjs1f8h2vs8m0cgfsgfivfkjvudu5-mzo1gjb2uf0m8_9v...@mail.gmail.com
> It came out only slightly slower over th
On Sun, May 26, 2019 at 09:53:41PM +0900, Tatsuo Ishii wrote:
> In the v12 beta1 release note:
>
> E.1.3.9. Server Applications
>
> Allow vacuumdb to select tables for vacuum based on...
>
> Why is vacuumdb listed in "Server Applications"? It's in "PostgreSQL
> Client Applications" section i
On Fri, 14 Jun 2019 at 13:54, Bruce Momjian wrote:
>
> On Sat, May 25, 2019 at 11:48:47AM -0400, Tom Lane wrote:
> > I wrote:
> > > Here's a new version of the Lists-as-arrays patch.
> >
> > The cfbot noticed a set-but-not-used variable that my compiler hadn't
> > whined about. Here's a v5 to pac
On Sat, May 25, 2019 at 11:48:47AM -0400, Tom Lane wrote:
> I wrote:
> > Here's a new version of the Lists-as-arrays patch.
>
> The cfbot noticed a set-but-not-used variable that my compiler hadn't
> whined about. Here's a v5 to pacify it. No other changes.
Have you tested the performance impac
On Fri, Jun 14, 2019 at 02:12:07AM +0200, Tomas Vondra wrote:
> FWIW my assumption was that we could just add an "encrypted" flag into
> the main XLogRecord header, and then an extra part with important
> encryption-related data - the key, and the important metadata needed by
> external tools (e.g.
On Fri, Jun 14, 2019 at 9:12 AM Tomas Vondra
wrote:
>
> On Thu, Jun 13, 2019 at 07:49:48PM -0400, Bruce Momjian wrote:
> >On Fri, Jun 14, 2019 at 12:41:17AM +0200, Tomas Vondra wrote:
> >> On Thu, Jun 13, 2019 at 11:07:25AM -0400, Bruce Momjian wrote:
> >> IMHO we should implement the simplest sys
Hi Sawada-san,
On Thursday, June 13, 2019 8:01 PM, Masahiko Sawada wrote:
> On Thu, Jun 13, 2019 at 6:30 PM Jamison, Kirk
> wrote:
> >
> > On Wednesday, June 12, 2019 4:29 PM (GMT+9), Masahiko Sawada wrote:
> > > ...
> > > I've not look at this patch deeply but in DropRelFileNodeBuffer I
> > > th
On Thu, Jun 13, 2019 at 09:12:58AM -0400, Bruce Momjian wrote:
> I went with this wording:
>
> This prevents unauthorized locking, which could interfere with
> user queries.
Okay, fine for me. Thanks for updating the notes.
--
Michael
signature.asc
Description: PGP signature
On Mon, Jun 3, 2019 at 12:04:54PM -0400, Robert Haas wrote:
>
> What I'm talking about here is that it also has to be reasonably
> possible to write an encryption key command that does something
> useful. I don't have a really clear vision for how that's going to
> work. Nobody wants the server
Pavel Trukhanov writes:
> Though I might've used wrong words to describe my holdback here, what
> I meant is that I'll need to create new node type (in primnodes.h?)
> for IN-list, that will allow to differentiate it from direct "ARRAY"
> usage.
> This will require changes to parse_expr.c, execExp
On Fri, Jun 14, 2019 at 12:02:52PM +1200, David Rowley wrote:
On Fri, 14 Jun 2019 at 11:45, Tomas Vondra wrote:
On Wed, Jun 12, 2019 at 10:58:44AM +0800, Richard Guo wrote:
># explain (costs off, verbose) select c1, c2, avg(c3) from t2 group by
>grouping sets((c1,c2), (c1));
>
On Thu, Jun 13, 2019 at 11:28:42AM +0300, Alexander Lakhin wrote:
> Yes, you're right. I've completed the patch for a possible elimination
> of the field.
For now I have discarded this one, and committed the rest as the
inconsistencies stand out. Good catches by the way.
Your patch was actually
On Tue, May 21, 2019 at 03:06:43PM -0400, Tom Lane wrote:
> * Speed of the generated parser could be better. I suspect this has
> a lot to do with the fact that our grammar is huge, and so are the
> tables, and that causes lots of cache misses. Maybe this could be
> addressed by trying to make th
On Thu, Jun 13, 2019 at 07:49:48PM -0400, Bruce Momjian wrote:
On Fri, Jun 14, 2019 at 12:41:17AM +0200, Tomas Vondra wrote:
On Thu, Jun 13, 2019 at 11:07:25AM -0400, Bruce Momjian wrote:
IMHO we should implement the simplest system possible, and optimize the
hell out of it without sacrificing a
On Thu, Jun 13, 2019 at 10:31:23AM +0200, Daniel Gustafsson wrote:
> Right, there is no use in backporting of course.
And applied now, in time for beta2.
--
Michael
signature.asc
Description: PGP signature
From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> for (i = 0; i < NBuffers; i++)
> {
> (snip)
> buf_state = LockBufHdr(bufHdr);
>
> /* check with the lower bound and skip the loop */
> if (bufHdr->tag.blockNum < minBlock)
> {
> UnlockBufHdr(
On Fri, 14 Jun 2019 at 11:45, Tomas Vondra wrote:
>
> On Wed, Jun 12, 2019 at 10:58:44AM +0800, Richard Guo wrote:
> ># explain (costs off, verbose) select c1, c2, avg(c3) from t2 group by
> >grouping sets((c1,c2), (c1));
> > QUERY PLAN
> >
On Fri, Jun 14, 2019 at 12:41:17AM +0200, Tomas Vondra wrote:
> On Thu, Jun 13, 2019 at 11:07:25AM -0400, Bruce Momjian wrote:
> IMHO we should implement the simplest system possible, and optimize the
> hell out of it without sacrificing any safety/security aspects. No smart
> tunables, no extra GU
On Wed, Jun 12, 2019 at 10:58:44AM +0800, Richard Guo wrote:
Hi all,
Paul and I have been hacking recently to implement parallel grouping
sets, and here we have two implementations.
Implementation 1
Attached is the patch and also there is a github branch [1] for this
work.
Pa
Hi,
On June 13, 2019 3:38:47 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> I am too tired to look further into this. I suspect the only reason
>we
>> didn't previously run into trouble with the executor stashing
>hashkeys
>> manually at a different tree level with:
>> ((HashState *) innerPla
Hi,
Commit 675f switched from a semaphore-based waiting to latch-based
waiting for ProcSleep()/ProcWakeup(), but left behind some stray
references to semaphores. PSA.
--
Thomas Munro
https://enterprisedb.com
0001-Remove-obsolete-comments-about-sempahores-from-proc..patch
Description: Bina
On Thu, Jun 13, 2019 at 11:07:25AM -0400, Bruce Momjian wrote:
On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote:
On Thu, Jun 13, 2019 at 3:48 AM Bruce Momjian wrote:
> The big question is how many people will be mixing encrypted and
> unencrypted data in the same cluster, and car
Andres Freund writes:
> I am too tired to look further into this. I suspect the only reason we
> didn't previously run into trouble with the executor stashing hashkeys
> manually at a different tree level with:
> ((HashState *) innerPlanState(hjstate))->hashkeys
> is that hashkeys itself isn't pri
On 2019-Jun-13, Alvaro Herrera wrote:
> On 2019-Jun-13, Oleksii Kliukin wrote:
>
> > Makes sense. For the symmetry I have included those that perform lock
> > upgrades in one session and those that doesn’t, while the other sessions
> > acquire locks, do updates or deletes. For those that don’t up
David Rowley writes:
> On Fri, 14 Jun 2019 at 05:22, Tom Lane wrote:
>> Robert Haas writes:
>>> So I think that this should probably be changed to say something like
>>> "Improve optimization of self-joins on ctid columns" or "Improve
>>> optimization of joins involving columns of type tid."
>>
On Fri, 14 Jun 2019 at 05:22, Tom Lane wrote:
>
> Robert Haas writes:
> > So I think that this should probably be changed to say something like
> > "Improve optimization of self-joins on ctid columns" or "Improve
> > optimization of joins involving columns of type tid."
>
> The latter seems fine
On Thu, Jun 13, 2019 at 4:10 PM Alvaro Herrera wrote:
> On 2019-Jun-13, Robert Haas wrote:
> > Typing "COMMIT;" or "ROLLBACK;" in S1 unblocks the reindex and it
> > succeeds, but otherwise it doesn't, contrary to the claim that a
> > regular REINDEX does not block reads. The reason for this seems
On 2019-Jun-13, Robert Haas wrote:
> Typing "COMMIT;" or "ROLLBACK;" in S1 unblocks the reindex and it
> succeeds, but otherwise it doesn't, contrary to the claim that a
> regular REINDEX does not block reads. The reason for this seems to be
> that the REINDEX acquires AccessExclusiveLock on all
On Thu, Jun 13, 2019 at 1:04 PM Robert Haas wrote:
> Typing "COMMIT;" or "ROLLBACK;" in S1 unblocks the reindex and it
> succeeds, but otherwise it doesn't, contrary to the claim that a
> regular REINDEX does not block reads. The reason for this seems to be
> that the REINDEX acquires AccessExclu
Hello Noah,
there is no simple way to know whether hostaddr was set at
the libPQ level
A solution could be to have a PQdoestheconnectionuseshostaddr(conn)
function, but I cannot say I'd be thrilled.
PQconninfo() is the official way to retrieve that.
Thanks for the pointer! I did not noti
The documentation for the new REINDEX CONCURRENTLY option says:
"When this option is used, PostgreSQL will rebuild the index without
taking any locks that prevent concurrent inserts, updates, or deletes
on the table; whereas a standard reindex build locks out writes (but
not reads) on the table un
Hi,
On June 12, 2019 6:42:11 PM PDT, David Rowley
wrote:
>On Mon, 10 Jun 2019 at 11:45, David Rowley
> wrote:
>>
>> On Sat, 8 Jun 2019 at 04:51, Andres Freund
>wrote:
>> > David, any opinions on how to best fix this? It's not extremely
>obvious
>> > how to do so best in the current setup of the
Hi,
On June 13, 2019 11:08:15 AM PDT, didier wrote:
>Extensions can do it, timescaledb in this case with:
>INSERT INTO ... RETURNING *;
>
>Or replacing the test in llvm_compile_expr with an Assert in
>slot_compile_deform ?
In that case we ought to never generate a deform expression step - core
Extensions can do it, timescaledb in this case with:
INSERT INTO ... RETURNING *;
Or replacing the test in llvm_compile_expr with an Assert in
slot_compile_deform ?
On 2019-Jun-13, Oleksii Kliukin wrote:
> Makes sense. For the symmetry I have included those that perform lock
> upgrades in one session and those that doesn’t, while the other sessions
> acquire locks, do updates or deletes. For those that don’t upgrade locks the
> test checks that the locks are
didier writes:
> JIT slot_compile_deform assumes there's at least 'natts' in TupleDesc, eg
> /*
> * Iterate over each attribute that needs to be deformed, build code
> to
> * deform it.
> */
> for (attnum = 0; attnum < natts; attnum++)
> {
>
On Mon, Jun 10, 2019 at 02:32:04PM +0100, Dean Rasheed wrote:
On Thu, 6 Jun 2019 at 21:33, Tomas Vondra wrote:
Hi,
Attached are three patches tweaking the stats - two were already posted
in this thread, the third one is just updating docs.
1) 0001 - split pg_statistic_ext into definition + d
On Wed, Jun 12, 2019 at 12:47 PM Alvaro Herrera
wrote:
> Please don't simplify the table name to just "t" -- the reason I used
> another name is that we want these tests to be able to run concurrently
> at some point; ref.
> https://postgr.es/m/20180124231006.z7spaz5gkzbdvob5@alvherre.pgsql
Not o
Robert Haas writes:
> The release notes say:
>
>
>
> Improve optimization of self-joins (Tom Lane)
>
>
> I don't think that's an accurate summary of those two items. It's
> true that they could make self-joins more efficient, but my reading is
> that it wo
The release notes say:
Improve optimization of self-joins (Tom Lane)
I don't think that's an accurate summary of those two items. It's
true that they could make self-joins more efficient, but my reading is
that it would only do so if the self-join happened
Hi,
On 6/5/19 3:39 PM, Floris Van Nee wrote:
Thanks! I've verified that it works now.
Here is a rebased version.
I was wondering if we're not too strict in some cases now though. Consider the
following queries:
[snip]
This is basically the opposite case - when distinct_pathkeys matches
Thanks for your reply
> If I understand correctly, "IN (...)" is reprecented by A_Expr with kind
> AEXPR_IN, and only in transformAExprIn converted to ArrayExpr if possible.
That seems to be correct, yes, thank you.
> So probably it doesn't makes sense to introduce another one.
Though I might've
On Jun 13, 2019 17:56, Tom Lane wrote:Pavlo Golub writes:
> Trying to build pg extension I've got error:
> ```
> pglogical_monitoring.o:pglogical_monitoring.c:(.rdata$.refptr.ReplicationSlotCtl[.refptr.ReplicationSlotCtl]+0x0): undefined reference to `ReplicationSlotCtl'
> collect2: error: ld
On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote:
> On Thu, Jun 13, 2019 at 3:48 AM Bruce Momjian wrote:
> > The big question is how many people will be mixing encrypted and
> > unencrypted data in the same cluster, and care about performance? Just
> > because someone might care is
Pavlo Golub writes:
> Trying to build pg extension I've got error:
> ```
> pglogical_monitoring.o:pglogical_monitoring.c:(.rdata$.refptr.ReplicationSlotCtl[.refptr.ReplicationSlotCtl]+0x0):
> undefined reference to `ReplicationSlotCtl'
> collect2: error: ld returned 1 exit status
> ```
> But acc
[ blast-from-the-past department ]
Craig Ringer writes:
> On 5 December 2017 at 22:49, Robert Haas wrote:
>> Mark assorted variables PGDLLIMPORT.
> I was going to pipe up here to add ReplicationSlotCtl to the list.
> Otherwise the only way to access slot information is via the SPI and
> pg_
On 2019-Jun-13, Michael Paquier wrote:
> On Wed, Jun 12, 2019 at 02:45:27PM -0400, Alvaro Herrera wrote:
> > Some grepping found a bit more; patch attached.
>
> Indeed. There were much more. I just got to look with stuff like
> that:
> find . -name "*.c" | xargs egrep "(\b[a-zA-Z]+) \1\b"
This
On Tue, Jun 11, 2019 at 2:35 PM Melanie Plageman
wrote:
> Let me try to articulate what I think the bitmap implementation would look
> like:
>
> Before doing chunked hashloop join for any batch, we would need to
> know how many tuples are in the outer batch to make the bitmap the
> correct size.
Hi,
I've been reading through the documentation regarding jsonpath and
jsonb_path_query etc., and I have found it lacking explanation for
some functionality, and I've also had some confusion when using the
feature.
? operator
==
The first mention of '?' is in section 9.15, where it says:
I think there's an off-by-one bug in your script. I picked one value at
random to verify -- 0x0BC0. Old:
> - {0x0BC0, 0x0BC0}, {0x0BCD, 0x0BCD}, {0x0C3E, 0x0C40},
New:
> + {0x0BC0, 0x0BC1}, {0x0BCD, 0x0BD0}, {0x0C00, 0x0C01},
the UCD file has:
0BC0;TAMIL VOWEL SIGN
Hello,
Alvaro Herrera wrote:
> On 2019-Jun-12, Oleksii Kliukin wrote:
>
>> Thank you! I can make it even simpler; s1 just acquires for share lock, s3
>> gets for update one and s2 takes for share lock first, and then tries to
>> acquire for update one; once s1 finishes, s3 deadlocks.
>
> Cool
On Thu, Jun 13, 2019 at 03:17:07PM +0200, Rafia Sabih wrote:
On Thu, 13 Jun 2019 at 06:07, Kuntal Ghosh wrote:
On Thu, Jun 13, 2019 at 5:49 AM Tomas Vondra
wrote:
>
> >> ...
> >>
> >That'll be an interesting work. For the above query, we can definitely
> >calculate the correction coefficient
Peter Eisentraut writes:
> Any thoughts about applying this as
> a) a bug fix with backpatching
> b) just to master
> c) wait for PG13
> d) it's all wrong?
Well, it's a behavioral change, and we've not gotten field complaints,
so I'm about -0.1 on back-patching. No objection to apply to master
On Thu, Jun 13, 2019 at 09:37:07AM +0530, Kuntal Ghosh wrote:
On Thu, Jun 13, 2019 at 5:49 AM Tomas Vondra
wrote:
For example, we might require 1000 samples for a given node (say, scan
with some quals), before we start using it to tweak the estimates. Once
we get the number of estimates, we ca
On Thu, 13 Jun 2019 at 06:07, Kuntal Ghosh wrote:
>
> On Thu, Jun 13, 2019 at 5:49 AM Tomas Vondra
> wrote:
> >
> > For example, we might require 1000 samples for a given node (say, scan
> > with some quals), before we start using it to tweak the estimates. Once
> > we get the number of estimates
On Thu, Jun 13, 2019 at 09:11:08AM -0400, Bruce Momjian wrote:
> On Thu, Jun 13, 2019 at 03:33:48PM +0900, Michael Paquier wrote:
> > On Wed, Jun 12, 2019 at 05:25:37PM -0400, Bruce Momjian wrote:
> > > Since we did not backpatch this fix, I am hesitant to spell out exactly
> > > how to exploit thi
On Thu, Jun 13, 2019 at 03:33:48PM +0900, Michael Paquier wrote:
> On Wed, Jun 12, 2019 at 05:25:37PM -0400, Bruce Momjian wrote:
> > Since we did not backpatch this fix, I am hesitant to spell out exactly
> > how to exploit this DOS attack. Yes, people can read it in the email
> > archives, and c
> On Thu, Jun 13, 2019 at 1:38 PM Pavel Trukhanov
> wrote:
>
> Hi Hackers
>
> I would like to embark on a journey to try to implement this issue I
> found on TODO list –
> https://www.postgresql.org/message-id/flat/CAM3SWZSpdPB3uErnXWMt3q74y0r%2B84ZsOt2U3HKKes_V7O%2B0Qg%40mail.gmail.com
> In shor
On Thu, Jun 13, 2019 at 5:19 PM Peter Eisentraut
wrote:
>
> Currently, calling pg_upgrade with an invalid command-line option aborts
> pg_upgrade but leaves a pg_upgrade_internal.log file lying around. This
> patch reorder things a bit so that that file is not created until all
> the options have
Hi Hackers
I would like to embark on a journey to try to implement this issue I
found on TODO list –
https://www.postgresql.org/message-id/flat/CAM3SWZSpdPB3uErnXWMt3q74y0r%2B84ZsOt2U3HKKes_V7O%2B0Qg%40mail.gmail.com
In short: pgss distinguishes "SELECT * WHERE id IN (1, 2)" and "SELECT
* WHERE id
I applied the 'alter-table-with-recursive-process-utility-calls-wip.patch'
on the master(e788e849addd56007a0e75f3b5514f294a0f3bca). And
when I test the cases, I find it works well on 'alter table t1 add column
f2 int not null, alter column f2 add generated always as identity' case,
but it doesn't
Fujita-san,
> From: Etsuro Fujita [mailto:etsuro.fuj...@gmail.com]
>
> Mochizuki-san,
>
> On Wed, Jun 12, 2019 at 6:08 PM wrote:
> > > On Mon, Jun 10, 2019 at 9:04 PM Etsuro Fujita
> > >
> > > wrote:
> > > > I'll look into the patch more closely tomorrow.
> > >
> > > I did that, but couldn't f
On Thu, Jun 13, 2019 at 6:30 PM Jamison, Kirk wrote:
>
> On Wednesday, June 12, 2019 4:29 PM (GMT+9), Masahiko Sawada wrote:
> > On Wed, Jun 12, 2019 at 12:25 PM Tsunakawa, Takayuki
> > wrote:
> > >
> > > From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
> > > > Years ago I've implemented
On Thu, Jun 13, 2019 at 12:29 PM David Rowley
wrote:
> On Wed, 12 Jun 2019 at 14:59, Richard Guo wrote:
> > Implementation 1
>
> > Parallel aggregation has already been supported in PostgreSQL and it is
> > implemented by aggregating in two stages. First, each worker performs an
> > aggregation
On Wednesday, June 12, 2019 4:29 PM (GMT+9), Masahiko Sawada wrote:
> On Wed, Jun 12, 2019 at 12:25 PM Tsunakawa, Takayuki
> wrote:
> >
> > From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
> > > Years ago I've implemented an optimization for many DROP TABLE
> > > commands in a single trans
Mochizuki-san,
On Wed, Jun 12, 2019 at 6:08 PM wrote:
> > On Mon, Jun 10, 2019 at 9:04 PM Etsuro Fujita
> > wrote:
> > > I'll look into the patch more closely tomorrow.
> >
> > I did that, but couldn't find any issue about the patch. Here is an updated
> > version of the patch. Changes are:
>
> On 13 Jun 2019, at 10:29, Michael Paquier wrote:
> I would not back-patch that though as currently
> USE_SSL <=> USE_OPENSSL.
Right, there is no use in backporting of course.
cheers ./daniel
On Thu, Jun 13, 2019 at 09:32:28AM +0200, Daniel Gustafsson wrote:
> The #ifdef guards in sha2.h are using USE_SSL when they in fact are guarding
> the inclusion of OpenSSL specific code. This has never caused any issues as
> there only is a single supported TLS backend in core so far, but since w
Hello Michael,
13.06.2019 11:10, Michael Paquier wrote:
> On Wed, Jun 12, 2019 at 05:34:06PM +0300, Alexander Lakhin wrote:
>> I can't see another inconsistencies for v12 for now, but there are some
>> that appeared before.
>> If this work can be performed more effectively or should be
>> postponed
Currently, calling pg_upgrade with an invalid command-line option aborts
pg_upgrade but leaves a pg_upgrade_internal.log file lying around. This
patch reorder things a bit so that that file is not created until all
the options have been parsed.
--
Peter Eisentraut http://www.2ndQuad
On Wed, Jun 12, 2019 at 05:34:06PM +0300, Alexander Lakhin wrote:
> I can't see another inconsistencies for v12 for now, but there are some
> that appeared before.
> If this work can be performed more effectively or should be
> postponed/canceled, please let me know.
Note sure that it is much prod
Dear all,
I apologize for my late reply.
I realized that the current implementation could not imitate the oracle's
precompiler.
The attached example can be accepted by both precompilers, but building the c
file made by ecpg fails.
For handling this source, we have to refactor some sources relat
On Thu, Jun 13, 2019 at 01:25:38PM +0600, Timur Birsh wrote:
> Just to be sure, a new command line argument needs to be added for
> reporting the numbers? Should it implies --verbose argument?
Nope. I mean that running a SELECT count(*) can be costly for many
items.
--
Michael
signature.asc
Des
The #ifdef guards in sha2.h are using USE_SSL when they in fact are guarding
the inclusion of OpenSSL specific code. This has never caused any issues as
there only is a single supported TLS backend in core so far, but since we’ve
spent a significant amount of energy on making the TLS backend non-h
On Thu, Jun 13, 2019 at 3:48 AM Bruce Momjian wrote:
>
> On Wed, Jun 5, 2019 at 11:54:04AM +0900, Masahiko Sawada wrote:
> > On Fri, May 10, 2019 at 2:42 AM Bruce Momjian wrote:
> > > I think we need to step back and see what we want to do. There are six
> > > levels of possible encryption:
> >
Hello Michael,
13.06.2019, 12:11, "Michael Paquier" :
> Welcome. Nice to see that you have subscribed to the lists.
Thank you for your explanations!
> Now, if you want to get review for your patch, you should register it
> in what we call the commit fest app, which is here:
> https://commitfest.
On 2019-06-04 22:58, Peter Eisentraut wrote:
> AFAICT, these Unicode definitions haven't changed since that list was
> put in originally around 2006, so I wonder what's going on there.
>
> I have written a script that recomputes that list from the current
> Unicode data. Patch and script are atta
On 2019-06-13 08:55, Michael Paquier wrote:
> Speaking about pg_lsn. We have introduced it to reduce the amount of
> duplication when mapping an LSN to text, so I am not much a fan of
> this patch which adds again a duplication. You also lose some error
> context as you get the same type of error
86 matches
Mail list logo
