On Fri, Nov 29, 2019 at 09:27:02AM -0500, Andrew Dunstan wrote:
> On 11/28/19 10:25 PM, Greg Nancarrow wrote:
> > 3) Documentation for the "PQsslpassword" function should be added to the
> > libpq "33.2 Connection Status Functions" section.
> I plan to commit this tomorrow.
The PQsslpassword()
On Fri, Dec 06, 2019 at 07:56:08PM +1300, Thomas Munro wrote:
> On Fri, Dec 6, 2019 at 7:34 PM Noah Misch wrote:
> > We use system UTF-16 collation to implement UTF-8 collation on Windows. The
> > PostgreSQL security team received a report, from Timothy Kuun, that this
> > collation does not
On Fri, Dec 6, 2019 at 7:34 PM Noah Misch wrote:
> We use system UTF-16 collation to implement UTF-8 collation on Windows. The
> PostgreSQL security team received a report, from Timothy Kuun, that this
> collation does not uphold the "symmetric law" and "transitive law" that we
> require for
On Fri, Dec 6, 2019 at 1:44 AM Robert Haas wrote:
> On Thu, Dec 5, 2019 at 11:22 AM Rushabh Lathia
> wrote:
> > Here is the whole stack of patches.
>
> I committed 0001, as that's just refactoring and I think (hope) it's
> uncontroversial. I think 0002-0005 need to be squashed together
>
We use system UTF-16 collation to implement UTF-8 collation on Windows. The
PostgreSQL security team received a report, from Timothy Kuun, that this
collation does not uphold the "symmetric law" and "transitive law" that we
require for btree operator classes. The attached test program
Hi Amit-san,
I wonder two things below. What do you think?
1)
For now, I'm not sure it should be set current_child_table_relid to zero
when the current phase is changed from "acquiring inherited sample rows" to
"computing stats". See bellow.
In the upthread discussion [1], Robert asked to
On Fri, Dec 06, 2019 at 10:33:23AM +0900, Michael Paquier wrote:
> Thanks. Another argument in favor of dropping 1.0.0 and 0.9.8 is that
> it is a pain to check an OpenSSL patch across that many versions,
> multiplied by the number of Postgres branches in need of patching :)
I have done nothing
On Thu, Dec 05, 2019 at 11:40:37PM -0500, Tom Lane wrote:
> OK, re-reading the thread, I see the point --- old NetBSD has a weird
> OpenSSL version that this would break. OK, let's stay compatible
> with that on the back branches. So, your patch on HEAD and Daniel's
> in the back branches is the
Hello Hackers:
I'm reading the code of optimizer and get confused about the 3
functions. add_path/set_cheapest/get_cheapest_fractional_path
add_(partial_)path:
For every relations, optimizer will build path for it and add then call
add_path to the rel->pathlist. during this stage, *it
Hi,
In few scenarios the message displayed in psql console is not consistent in
windows and linux. The execution results from few scenarios in windows and
linux is listed below:
In CentOS
*After transaction idle timeout*postgres=# SET
On Thu, Dec 5, 2019 at 7:44 PM Robert Haas wrote:
>
> I think it might be a good idea to change what we expect index AMs to
> do rather than trying to make anything that they happen to be doing
> right now work, no matter how crazy. In particular, suppose we say
> that you CAN'T add data on to
On Thu, Dec 05, 2019 at 12:29:29PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 05 Dec 2019 12:06:54 +0900 (JST), Kyotaro Horiguchi
> wrote in
>> So, (IIUC) do we replace fprintf()s for error reporting together (but
>> maybe in a separate patch)?
I guess that we should do that at the end of the
New users frequently attempt to run PostgreSQL's command line utilities
from the psql prompt.
They tend to be confused when this appears to do absolutely nothing:
psql=> pg_restore
psql->
since they're generally not going to semicolon-terminate the command either.
The attached
Michael Paquier writes:
> About clear_options, my take is to remove the check on HEAD, and to
> apply Daniel's patch on *all* stable branches because I think that we
> should not break the business that happened with NetBSD 5 on already
> released branches. Does that sound good?
OK, re-reading
On Fri, Dec 6, 2019 at 12:55 AM Mahendra Singh wrote:
>
> On Thu, 5 Dec 2019 at 19:54, Robert Haas wrote:
> >
> > [ Please trim excess quoted material from your replies. ]
> >
> > On Thu, Dec 5, 2019 at 12:27 AM Dilip Kumar wrote:
> > > I agree that there is no point is first to spawn more
On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote:
> Concerning keeping PGPROC size as small as possible, I agree that it is
> reasonable argument.
> But even now it is very large (816 bytes) and adding extra 8 bytes will
> increase it on less than 1%.
It does not mean that we
On Thu, Dec 05, 2019 at 10:38:55AM -0500, Tom Lane wrote:
> Yeah; also as mentioned in the other thread, 1.0.1 is still in use
> in RHEL 6, so it's hard to consider dropping that for at least another
> year. I concur with the conclusion that we can stop worrying about
> NetBSD 5, though.
Thanks.
On Thu, Dec 05, 2019 at 01:41:20PM -0500, Robert Haas wrote:
> If you do decide to work on this, I recommend against preparing a
> single giant patch that changes every single one blindly. Try to think
> about which cases are the most egregious/dangerous and propose patches
> for those first. If
On Thu, Dec 05, 2019 at 07:41:14PM -0500, Tom Lane wrote:
> It'd be possible to also backpatch the other thread's
> 0001-Remove-configure-checks-for-SSL_get_current_compress.patch
> as far as v10, but I'm less excited about that -- it'd just save
> a few configure cycles, no?
Yeah. I'd try not
Daniel Gustafsson writes:
> On 5 Dec 2019, at 15:50, Tom Lane wrote:
>> What I'd like to know is whether not
>> realizing that SSL_clear_options is present causes any functional
>> issues that would justify back-patching a fix.
> ISTM that SSL_clear_options is required for turning on
Alvaro Herrera writes:
> If anybody would like to review it once more, now's the time. I'm
> aiming at getting it pushed tomorrow (including the length-limited
> appendStringInfoStringQuoted stuff).
Um, surely this bit is unacceptable?
+ /*
+* XXX this clobbers any other DETAIL
On Thu, Dec 05, 2019 at 09:14:12PM +, Alex Adriaanse wrote:
We have a Postgres 10 database that we recently upgraded to Postgres 12 using
pg_upgrade. We recently discovered that there are rows in one of the tables
that have duplicate primary keys:
record_loader=# \d loader.sync
Mark Dilger writes:
> On 12/3/19 5:24 PM, Ranier Vilela wrote:
>> Any comments?
> I suggested increasing the default warnings in an email some time ago,
> to which Tom made reasonable objections.
Yes, that whole thread is worth a read in this context:
On Thu, Dec 5, 2019 at 1:14 PM Alex Adriaanse wrote:
> We have a Postgres 10 database that we recently upgraded to Postgres 12 using
> pg_upgrade. We recently discovered that there are rows in one of the tables
> that have duplicate primary keys:
What's the timeline here? In other words, does
On 2019-Dec-05, Alvaro Herrera wrote:
> > Makes me wonder though, if we ought to invent something similar to the
> > errdata fields we have for schema, table, etc...
>
> Hmm, perhaps we should do that. It avoids the problem altogether.
... then again, I'm not up for writing everything that
> On 5 Dec 2019, at 10:17, Julien Rouhaud wrote:
> While reading pg_upgrade code to restore the objects on the new
> cluster, I noticed that 5b570d771b8 didn't adjust the database name in
> the comments explaining the requirements for an extra "--clean" for
> template1 and postgres databases.
> On 5 Dec 2019, at 15:50, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 5 Dec 2019, at 02:48, Michael Paquier wrote:
>>> So it seems to me that we are able to correctly
>>> detect the presence of this function in the configure checks if
>>> building with 1.1.0~, but not other versions.
On 2019-12-05 12:55:51 -0800, Jeff Davis wrote:
> On Thu, 2019-11-28 at 18:46 +0100, Tomas Vondra wrote:
> > And it's not clear to me why we should remove part of the comment
> > before
> > TupleHashTableHash.
>
> It looks like 5dfc1981 changed the signature of TupleHashTableHash
> without
On Thu, Dec 05, 2019 at 12:55:51PM -0800, Jeff Davis wrote:
On Thu, 2019-11-28 at 18:46 +0100, Tomas Vondra wrote:
And it's not clear to me why we should remove part of the comment
before
TupleHashTableHash.
It looks like 5dfc1981 changed the signature of TupleHashTableHash
without updating
We have a Postgres 10 database that we recently upgraded to Postgres 12 using
pg_upgrade. We recently discovered that there are rows in one of the tables
that have duplicate primary keys:
record_loader=# \d loader.sync
Table "loader.sync"
Column |
On 12/3/19 5:24 PM, Ranier Vilela wrote:
Hi,
I believe PostgreSQL can benefit from changing the alert level of compilation
warnings.
The current Level3 level for windows does not show any alerts, but that does
not mean that there are no problems.
Changing the level to Level4 and its
On Fri, Dec 6, 2019 at 9:20 AM Robert Haas wrote:
>
> On Thu, Dec 5, 2019 at 1:12 PM Bruce Momjian wrote:
> > I agree with Stephen's request. We have been waiting for the executor
> > rewrite for a while, so let's just do something simple and see how it
> > performs.
>
> I'm sympathetic to the
On Thu, 2019-11-28 at 18:46 +0100, Tomas Vondra wrote:
> And it's not clear to me why we should remove part of the comment
> before
> TupleHashTableHash.
It looks like 5dfc1981 changed the signature of TupleHashTableHash
without updating the comment, so it doesn't really make sense any more.
I
On Thu, Dec 5, 2019 at 1:12 PM Bruce Momjian wrote:
> I agree with Stephen's request. We have been waiting for the executor
> rewrite for a while, so let's just do something simple and see how it
> performs.
I'm sympathetic to the frustration here, and I think it would be great
if we could find
On Thu, Dec 5, 2019 at 11:22 AM Rushabh Lathia wrote:
> Here is the whole stack of patches.
I committed 0001, as that's just refactoring and I think (hope) it's
uncontroversial. I think 0002-0005 need to be squashed together
(crediting all authors properly and in the appropriate order) as it's
On Thu, 5 Dec 2019 at 19:54, Robert Haas wrote:
>
> [ Please trim excess quoted material from your replies. ]
>
> On Thu, Dec 5, 2019 at 12:27 AM Dilip Kumar wrote:
> > I agree that there is no point is first to spawn more workers to get
> > the work done faster and later throttle them.
Hello
On 2019-Dec-05, Andres Freund wrote:
> On 2019-12-05 14:19:45 -0300, Alvaro Herrera wrote:
> > What this does is set an error callback, which adds the parameter values
> > in the DETAIL line. This is at odds with all existing error callbacks:
> > they only add stuff to the CONTEXT string.
On Thu, Dec 5, 2019 at 11:22 AM Rushabh Lathia wrote:
> Here is the whole stack of patches.
Please include proper attribution and, where somebody's written them,
commit messages in each patch in the stack. For example, I see that
your 0001 is mostly the same as my 0001 from upthread, but now it
On Thu, Dec 5, 2019 at 11:26 AM Ranier Vilela wrote:
> Even so, there is some failure to review or compile in Unix environment,
> because there are so many cases.
> -Wshadow with GCC can show the alerts.
I mean, compiler warnings are not errors, and there's no requirement
that we fix every
On Thu, Dec 5, 2019 at 05:45:24PM +1300, Thomas Munro wrote:
> My patch set (rebased upthread) was extremely primitive, with no new
> planner concepts, and added only a very simple new executor node
> method: ExecReady(). Append used that to try to ask its children if
> they'd like some time to
Hi,
On 2019-12-05 14:19:45 -0300, Alvaro Herrera wrote:
> What this does is set an error callback, which adds the parameter values
> in the DETAIL line. This is at odds with all existing error callbacks:
> they only add stuff to the CONTEXT string. The implication is that
> if an error site has
On Thu, Dec 05, 2019 at 06:15:54PM +0100, Tomas Vondra wrote:
On Sun, Dec 01, 2019 at 08:08:58PM +0100, Tomas Vondra wrote:
On Sat, Nov 30, 2019 at 03:01:31PM -0800, Mark Dilger wrote:
Are you planning to submit a revised patch for this?
Yes, I'll submit a rebased version of this patch
I made a number of changes on the proposed patch and ended up with the
attached. (I have not included the business to limit number of
characters, yet).
What this does is set an error callback, which adds the parameter values
in the DETAIL line. This is at odds with all existing error callbacks:
On Sun, Dec 01, 2019 at 08:08:58PM +0100, Tomas Vondra wrote:
On Sat, Nov 30, 2019 at 03:01:31PM -0800, Mark Dilger wrote:
Are you planning to submit a revised patch for this?
Yes, I'll submit a rebased version of this patch shortly. I got broken
because of the recent fix in
Hi hackers,
On Fri, 23 Aug 2019 09:30:59 -0400
Andrew Dunstan wrote:
> On 8/23/19 8:47 AM, Pierre Giraud wrote:
> > "Plans": [
> > {
> > "Node Type": "Sort",
> > "Parent Relationship": "Outer",
> > "Parallel Aware": false,
> > "Actual
Robert wrote:
>Most of us don't develop on Windows, so changing warning levels on
>Windows won't really affect what developers see on their own machines,
>and thus probably doesn't have much value.
Yes the report is from msvc 2017.
Even so, there is some failure to review or compile in Unix
On Thu, Dec 5, 2019 at 12:17 AM Robert Haas wrote:
> On Wed, Dec 4, 2019 at 1:01 PM Rushabh Lathia
> wrote:
> > As per the discussion on the thread, here is the patch which
> >
> > a) Make checksum for manifest file optional.
> > b) Allow user to choose a particular algorithm.
> >
> >
Neha Sharma writes:
> It was observed that when we try to connect through a user/database
> created using simplified Chinese characters on EUC_CN server_encoding,
> it fails giving error that the object does not exists. Whereas if we
> query the system table we can find their entries there.
Daniel Gustafsson writes:
>> On 5 Dec 2019, at 09:32, Michael Paquier wrote:
>> From the point of view of the code, the cleanup is not actually that
>> amazing I am afraid, a jump directly to 1.1.0 would remove much more
>> because the breakages were wider when we integrated it. Anyway, those
On Thu, Dec 5, 2019 at 10:28 AM Daniel Gustafsson wrote:
> I am currently reviewing your latest patchset, but need a bit more time.
Oh, great, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On 5 Dec 2019, at 16:13, Robert Haas wrote:
>
>> On Tue, Dec 3, 2019 at 6:41 PM Daniel Gustafsson wrote:
>> Attached is a rebased v14 patchset on top of maser. The Global Barriers
>> patch
>> is left as a prerequisite, but it will obviously be dropped, or be
>> significantly changed, once
On Tue, Dec 3, 2019 at 8:24 PM Ranier Vilela wrote:
> I believe PostgreSQL can benefit from changing the alert level of compilation
> warnings.
> The current Level3 level for windows does not show any alerts, but that does
> not mean that there are no problems.
> Changing the level to Level4
On Tue, Dec 3, 2019 at 6:41 PM Daniel Gustafsson wrote:
> Attached is a rebased v14 patchset on top of maser. The Global Barriers patch
> is left as a prerequisite, but it will obviously be dropped, or be
> significantly changed, once the work Robert is doing with ProcSignalBarrier
> lands.
Any
On Tue, Dec 3, 2019 at 10:18 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > But nevertheless should we allow relocatable extension to use
> > @extschema@. Any thoughts?
>
> No. The reasoning in the comment still holds good: if you embed
> @extschema@ in an object's definition, it becomes
Daniel Gustafsson writes:
>> On 5 Dec 2019, at 02:48, Michael Paquier wrote:
>> So it seems to me that we are able to correctly
>> detect the presence of this function in the configure checks if
>> building with 1.1.0~, but not other versions.
> Yes, we can't use AC_CHECK_FUNCS but would need
[ Please trim excess quoted material from your replies. ]
On Thu, Dec 5, 2019 at 12:27 AM Dilip Kumar wrote:
> I agree that there is no point is first to spawn more workers to get
> the work done faster and later throttle them. Basically, that will
> lose the whole purpose of running it in
On Thu, Dec 5, 2019 at 12:22 AM Amit Kapila wrote:
> I think it could be required for the cases where the AM doesn't have a
> way (or it is difficult to come up with a way) to communicate the
> stats allocated by the first ambulkdelete call to the subsequent ones
> until amvacuumcleanup.
On Thu, 5 Dec 2019 at 14:45, Robert Haas wrote:
>
> On Tue, Dec 3, 2019 at 8:36 AM Rafia Sabih wrote:
> > While going through this file I noticed some inconsistencies in the
> > comments. Please find attachment for the fix.
>
> Committed. I think only the duplicated word is a clear error, but
On Tue, Dec 3, 2019 at 8:36 AM Rafia Sabih wrote:
> While going through this file I noticed some inconsistencies in the
> comments. Please find attachment for the fix.
Committed. I think only the duplicated word is a clear error, but the
other changes seem like mild improvements, so pushed the
Hello
>> > Also, I'm not entirely sure whether there's anything in our various
>> > replication logic that's dependent on vacuum truncation taking AEL.
>> > Offhand I'd expect the reduced use of AEL to be a plus, but maybe
>> > I'm missing something.
>>
>> It'd be a *MAJOR* plus. One of the
On Wed, Dec 04, 2019 at 05:36:16PM -0800, Jeremy Schneider wrote:
On 9/8/19 14:01, Tom Lane wrote:
Fix RelationIdGetRelation calls that weren't bothering with error checks.
...
Details
---
https://git.postgresql.org/pg/commitdiff/69f883fef14a3fc5849126799278abcc43f40f56
We had two
> On 5 Dec 2019, at 09:32, Michael Paquier wrote:
> From the point of view of the code, the cleanup is not actually that
> amazing I am afraid, a jump directly to 1.1.0 would remove much more
> because the breakages were wider when we integrated it. Anyway, those
> cleanups are part of 0003. I
Hi,
It was observed that when we try to connect through a user/database created
using
simplified Chinese characters on EUC_CN server_encoding, it fails giving
error that
the object does not exists. Whereas if we query the system table we can
find their entries
there.
Data setup:
.) set the
On Tue, Dec 3, 2019 at 11:10 AM Amit Khandekar wrote:
>
> On Wed, 27 Nov 2019 at 14:16, Amit Khandekar wrote:
> > What I found was : We do attempt to close the opened vfds in the
> > PG_CATCH block. In ReorderBufferCommit(), ReorderBufferIterTXNFinish
> > is called both in PG_TRY and PG_CATCH.
When hacking the Zedstore, we need to get a more accurate statistic for
zedstore and we
faced some restrictions:
1) acquire_sample_rows() always use RelationGetNumberOfBlocks to generate
sampling block
numbers, this is not friendly for zedstore which wants to use a logical
block number and
On Wed, Dec 4, 2019 at 9:51 PM Andrew Dunstan
wrote:
>
> On Wed, Dec 4, 2019 at 12:12 AM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > On Tue, Dec 3, 2019 at 10:10 PM Tom Lane wrote:
> > >> Hmm ... just looking at the code again, could it be that there's
> > >> no well-placed
On 05.12.2019 5:37, Kyotaro Horiguchi wrote:
It seems to be useful to me. We also might want statistics of other
session IOs. In that case the table name would be
"pg_stat_session/process_activity". We are aleady collecting most
kinds of the IO activity but it loses session information...
Hello,
While reading pg_upgrade code to restore the objects on the new
cluster, I noticed that 5b570d771b8 didn't adjust the database name in
the comments explaining the requirements for an extra "--clean" for
template1 and postgres databases. While it's true that both databases
will already
> On 5 Dec 2019, at 02:48, Michael Paquier wrote:
>
> On Mon, Dec 02, 2019 at 02:09:51PM +0100, Daniel Gustafsson wrote:
>> However, looking at the signatures detected by autoconf we can however get an
>> idea of which version is used. SSL_clear_options and
>> X509_get_signature_nid()
>> first
Hi,
Thank you for your replay and explanations.
My comments are inside.
On 04.12.2019 22:43, Andres Freund wrote:
Hi,
On 2019-11-25 18:09:29 +0300, Konstantin Knizhnik wrote:
I wonder why even at this query, which seems to be ideal use case for JIT,
we get such modest improvement?
I think
On Thu, Dec 5, 2019 at 12:54 AM Robert Haas wrote:
>
> On Thu, Nov 21, 2019 at 12:32 AM Dilip Kumar wrote:
> > In v33-0001-Add-index-AM-field-and-callback-for-parallel-ind patch, I
> > am a bit doubtful about this kind of arrangement, where the code in
> > the "if" is always unreachable with
Hi all,
So, I have been looking at what we could clean up by removing support
for OpenSSL 0.9.8 and 1.0.0. Here are my notes:
1) SSL_get_current_compression exists before 0.9.8, and we don't
actually make use of its configure check. So I think that it could
just be removed, as per patch 0001.
72 matches
Mail list logo
