On Thu, 30 Jan 2020 at 20:36, Sehrope Sarkuni wrote:
>
> On Wed, Jan 29, 2020 at 3:43 AM Masahiko Sawada
> wrote:
> > Thank you for the suggestion. I like your suggestion. We can do an
> > integrity check of the user input wrapped key by using HMAC when
> > unwrapping. Regarding the output
On Thu, Jan 23, 2020 at 05:54:08PM +0100, Jehan-Guillaume de Rorthais wrote:
> Please find the new version of the patch in attachment.
To be honest, I find the concept of this patch confusing.
pg_stat_wal_receiver is just a one-one mapping with the shared memory
state of the WAL receiver itself
On Fri, 31 Jan 2020 at 02:41, Tom Lane wrote:
>
> Peter Eisentraut writes:
> > On 2019-12-18 14:52, Peter Eisentraut wrote:
> >> We have code paths for Unix socket support and no Unix socket support.
> >> Now add a third variant: Unix socket support but do not use a Unix
> >> socket by default
On Fri, 31 Jan 2020 at 13:27, Michael Paquier wrote:
>
> On Fri, Jan 31, 2020 at 12:47:29PM +1030, Andrew Dunstan wrote:
> > When I was working on the test_json stuff yesterday, I noticed that
> > there are some unexpected (by me at least) things installed when we do
> > an MSVC build:
> >
> > $
On Fri, Jan 31, 2020 at 02:15:42PM +0900, Kyotaro Horiguchi wrote:
> As a cross check, it cleanly applied and worked as expected. The
> fallback definition of StaticAssertDecl for C worked for gcc 8.3.
Thanks for the review.
> - * Macros to support compile-time assertion checks.
> + * Macros to
At Thu, 30 Jan 2020 17:45:36 -0300, Alvaro Herrera
wrote in
> On 2020-Jan-30, Kyotaro Horiguchi wrote:
>
> > Agreed about backbranches. I'd like to preserve the word "transaction"
> > as it is more familiar to users. How about something like the follows?
> >
> > "transactions are completed up
On Fri, Jan 31, 2020 at 12:47:29PM +1030, Andrew Dunstan wrote:
> When I was working on the test_json stuff yesterday, I noticed that
> there are some unexpected (by me at least) things installed when we do
> an MSVC build:
>
> $ ls -l bin| egrep 'regress|isolation'
> -rwxr-xr-x 1 pgrunner None
At Fri, 31 Jan 2020 11:47:01 +0900, Michael Paquier wrote
in
> On Tue, Dec 24, 2019 at 02:47:29PM +0900, Michael Paquier wrote:
> > I am still seeing that a couple of points need an extra lookup:
> > - Addition of a Decl() in at least one header of the core code.
>
> I agree with the addition
On Thu, Jan 30, 2020 at 06:11:22PM +0100, Michael Banck wrote:
> The other question is whether it is possible to end up with a
> pg_internal.init.$PID file in a running cluster. E.g. if an instance
> crashes and gets started up again - are those cleaned up during crash
> recovery, or should
On Fri, Jan 31, 2020 at 1:28 AM Fujii Masao wrote:
> On 2020/01/31 1:02, Tom Lane wrote:
> > Fujii Masao writes:
> >> Thanks for updating the patch! Barring any objection,
> >> I will commit this fix and backport it to all supported versions.
> >
> > Sorry for not having paid closer attention to
On Mon, Oct 21, 2019 at 12:21 PM Thomas Munro wrote:
> On Fri, Jun 21, 2019 at 6:52 AM Andres Freund wrote:
> > On 2019-06-20 14:20:27 -0400, Robert Haas wrote:
> > > I am not convinced that we really need to GUC-ify this. How about
> > > just bumping the value up from 2 to say 5?
> >
> > I'm
On Tue, Dec 24, 2019 at 02:47:29PM +0900, Michael Paquier wrote:
> I am still seeing that a couple of points need an extra lookup:
> - Addition of a Decl() in at least one header of the core code.
I agree with the addition of Decl() definition in a header, and could
not think about something
On Thu, Jan 30, 2020 at 6:10 PM Dilip Kumar wrote:
>
> On Thu, Jan 30, 2020 at 4:11 PM Amit Kapila wrote:
> >
> > Also, if we need to copy the snapshot here, then do we need to again
> > copy it in ReorderBufferProcessTXN(in below code and in catch block in
> > the same function).
> I think so
When I was working on the test_json stuff yesterday, I noticed that
there are some unexpected (by me at least) things installed when we do
an MSVC build:
$ ls -l bin| egrep 'regress|isolation'
-rwxr-xr-x 1 pgrunner None 72192 Jan 30 07:51 isolationtester.exe
-rwxr-xr-x 1 pgrunner None 112640
On Thu, Jan 30, 2020 at 8:47 PM Peter Geoghegan wrote:
> On Wed, Jan 29, 2020 at 11:38 PM Thomas Munro wrote:
> > CreateParallelContext() can return a context with seg == NULL. That
> > causes CREATE INDEX to segfault. Instead, it should fall back to
> > non-parallel build. See attached.
>
>
On Thu, Jan 30, 2020 at 2:13 PM Peter Geoghegan wrote:
> My approach to showing the downsides of the patch wasn't particularly
> obvious, or easy to come up with. I could have contrived a case like
> the insert benchmark, but with more low cardinality non-unique
> indexes.
Sorry. I meant with
On Thu, Jan 30, 2020 at 12:57 PM Robert Haas wrote:
> That seems reasonable.
My approach to showing the downsides of the patch wasn't particularly
obvious, or easy to come up with. I could have contrived a case like
the insert benchmark, but with more low cardinality non-unique
indexes. That
> On Jan 30, 2020, at 12:29 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Would it make sense to catch a qual with unassigned collation
>> somewhere in the planner, where the qual's operator family is
>> estatblished, by checking if the operator family behavior is sensitive
>> to
On Thu, Jan 30, 2020 at 2:40 PM Peter Geoghegan wrote:
> On Thu, Jan 30, 2020 at 11:16 AM Peter Geoghegan wrote:
> > I prefer to think of the patch as being about improving the stability
> > and predictability of Postgres with certain workloads, rather than
> > being about overall throughput.
Robert Haas writes:
> I assume that what would have to happen to implement this is that an
> SQL-callable function would be passed more than one collation OID,
> perhaps one per argument or something like that. Notice, however, that
> this would require changing the way that functions get called.
On 2020-Jan-30, Kyotaro Horiguchi wrote:
> Agreed about backbranches. I'd like to preserve the word "transaction"
> as it is more familiar to users. How about something like the follows?
>
> "transactions are completed up to log time %s"
That's a good point. I used the phrase "transaction
On Mon, Jan 27, 2020 at 7:09 AM Robert Haas wrote:
> Rather than answering your actual question, I'd like to complain about
> this:
>
> if (BufFileRead(file, ptr, BLCKSZ) != BLCKSZ)
> - elog(ERROR, "could not read temporary file: %m");
> + elog(ERROR, "could not read temporary file");
>
> I
Mark Dilger writes:
> Would it make sense to catch a qual with unassigned collation
> somewhere in the planner, where the qual's operator family is
> estatblished, by checking if the operator family behavior is sensitive
> to collations?
> I’m not sure how to do that. pg_opfamily doesn’t seem
> On Jan 30, 2020, at 12:02 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> According to Tom:
>>> (BTW, before v12 the text '=' operator indeed did not care for collation,
>>> so this example would've worked. But the change in behavior is a
>>> necessary consequence of having invented
On Thu, Jan 30, 2020 at 2:44 PM Mark Dilger
wrote:
> 3) Extend the concept of collations to collation sets. Right now, I’m only
> thinking about a collation set as having two values, the lefthand and the
> righthand side, but maybe there are other cases like (Left, (Left,Right))
> that get
Mark Dilger writes:
> According to Tom:
>> (BTW, before v12 the text '=' operator indeed did not care for collation,
>> so this example would've worked. But the change in behavior is a
>> necessary consequence of having invented nondeterministic collations,
>> not a bug.)
> I’m still struggling
>> Would it make sense to catch a qual with unassigned collation
>> somewhere in the planner, where the qual's operator family is
>> estatblished, by checking if the operator family behavior is sensitive
>> to collations?
I’m not sure how to do that. pg_opfamily doesn’t seem to have a field
On Thu, Jan 30, 2020 at 11:16 AM Peter Geoghegan wrote:
> I prefer to think of the patch as being about improving the stability
> and predictability of Postgres with certain workloads, rather than
> being about overall throughput. Postgres has an ungoing need to VACUUM
> indexes, so making
vignesh C writes:
> On Wed, Jan 29, 2020 at 6:54 PM Ahsan Hadi wrote:
>> Can you share a test case or steps that you are using to reproduce this
>> issue? Are you reproducing this using a debugger?
> I could reproduce with the following steps:
> Make cluster setup.
> Create few tables.
> Take
On Thu, Jan 30, 2020 at 9:36 AM Robert Haas wrote:
> How do things look in a more sympathetic case?
I prefer to think of the patch as being about improving the stability
and predictability of Postgres with certain workloads, rather than
being about overall throughput. Postgres has an ungoing
On 2019-Jul-26, Andres Freund wrote:
> Petr, Simon, see the potential issue related to fast forward at the
> bottom.
I think we neglected this bit. I looked at the patch Simon submitted
downthread, and while I vaguely understand that we need to process
NEW_CID records during fast-forwarding, I
> On Jan 29, 2020, at 10:14 PM, Amit Langote wrote:
>
>
> SELECT t1.a, t2.a FROM alpha t1 INNER JOIN beta t2 ON (t1.a = t2.a)
> WHERE t1.a IN ('äbç', 'ὀδυσσεύς');
> ERROR: could not determine which collation to use for string comparison
> HINT: Use the COLLATE clause to set the collation
Using today's HEAD, the regression database cannot be dumped and
restored normally. Since the buildfarm isn't all red, I suppose
it works in --binary-upgrade mode ... but if I just do
$ make installcheck # to set up the test database
$ pg_dump -Fc regression >r.dump
$ createdb r2
$ pg_restore
Peter Eisentraut writes:
> On 2019-12-18 14:52, Peter Eisentraut wrote:
>> We have code paths for Unix socket support and no Unix socket support.
>> Now add a third variant: Unix socket support but do not use a Unix
>> socket by default in the client or the server, only if you explicitly
>>
On 2019-12-18 14:52, Peter Eisentraut wrote:
Next patch: This allows building *with* Unix-domain socket support but
*without* a default Unix socket path. This is needed because on Windows
we don't have a good default location like "/tmp" and we probably don't
want Unix sockets by default at
On 2020-Jan-30, Peter Eisentraut wrote:
> I read the whole thread, I still don't know what this patch is supposed to
> do. I know what the words in the subject line mean, but I don't know how
> this helps a pgbench user run better benchmarks. I feel this is also the
> sentiment expressed by
Fujii Masao writes:
> On 2020/01/31 1:28, Fujii Masao wrote:
>> On 2020/01/31 1:02, Tom Lane wrote:
>>> Sorry for not having paid closer attention to this thread, but ...
>>> is back-patching this behavioral change really a good idea?
> I'm thinking to wait at least half a day before reverting
>
On 2020/01/31 1:28, Fujii Masao wrote:
On 2020/01/31 1:02, Tom Lane wrote:
Fujii Masao writes:
Thanks for updating the patch! Barring any objection,
I will commit this fix and backport it to all supported versions.
Sorry for not having paid closer attention to this thread, but ...
is
On 2020-01-05 10:02, Fabien COELHO wrote:
This patch was marked as RFC on 2019-03-30, but since then there have
been a couple more issues pointed out in a review by Thomas Munro, and
it went through 2019-09 and 2019-11 without any attention. Is the RFC
status still appropriate?
Thomas review
On Thu, Jan 30, 2020 at 1:45 AM Peter Geoghegan wrote:
> There is a regression that is just shy of 2% here, as measured in
> insert benchmark "rows/sec" -- this metric goes from "62190.0"
> rows/sec on master to "60986.2 rows/sec" with the patch. I think that
> this is an acceptable price to pay
On 2020/01/30 12:58, Kyotaro Horiguchi wrote:
At Wed, 29 Jan 2020 23:16:08 +0900, Fujii Masao
wrote in
Hi,
pg_basebackup reports the backup progress if --progress option is
specified,
and we can monitor it in the client side. I think that it's useful if
we can
monitor the progress
Thanks both for looking! I have pushed those, removing the zic.c
changes.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi,
we had a customer who ran pg_checksums on their v12 cluster and got a
confusing error:
|pg_checksums: error: invalid segment number 0 in file name "/PG-
|Data/foo_12_data/pg_tblspc/16402/PG_10_201707211/16390/pg_internal.init
|.10028"
Turns out the customer ran a pg_ugprade in copy mode
On 2020/01/30 20:00, Sergei Kornilov wrote:
Hello
Currently during point-in-time recovery with recovery_target_action = 'pause'
we print log lines:
LOG: recovery has paused
HINT: Execute pg_wal_replay_resume() to continue.
My colleague told me that this is a terrible moment: to continue
Mark Charsley writes:
> This line
> https://github.com/postgres/postgres/blob/30012a04a6c8127397a8ab71e160d9c7e7fbe874/src/interfaces/libpq/fe-exec.c#L1073
> triggers data race errors when run under ThreadSanitizer (*)
> As far as I can tell, the static variable in question is a hack to allow a
On 2020/01/31 1:02, Tom Lane wrote:
Fujii Masao writes:
Thanks for updating the patch! Barring any objection,
I will commit this fix and backport it to all supported versions.
Sorry for not having paid closer attention to this thread, but ...
is back-patching this behavioral change really
Fujii Masao writes:
> Thanks for updating the patch! Barring any objection,
> I will commit this fix and backport it to all supported versions.
Sorry for not having paid closer attention to this thread, but ...
is back-patching this behavioral change really a good idea?
It's not that hard to
On 2020/01/27 14:02, Amit Langote wrote:
Fujii-san,
On Mon, Jan 27, 2020 at 11:19 AM Fujii Masao
wrote:
On 2020/01/23 22:14, Fujii Masao wrote:
Thanks for updating the patch! Barring any objection,
I will commit this fix and backport it to all supported versions.
Attached are the
> On Sun, Nov 17, 2019 at 10:14:26PM -0800, Noah Misch wrote:
>
> > I'm probably missing something, so just wanted to clarify. Do I
> > understand correctly, that thread [1] and this one are independent, and
> > it is assumed in the scenario above that we're at the end of XID space,
> > but not
Hi Hackers,
On 12/1/19 4:45 AM, Michael Paquier wrote:
> For now I have moved the patch to
> next CF, waiting on author.
We have withdrawn this patch for now. The reason for this is, that we
had ideas on how to split it into multiple simpler independent patches,
that can be reviewed and
On 2019-12-31 11:56, Peter Eisentraut wrote:
On 2019-12-04 11:32, Guram Duka wrote:
Master branch got error in configure stage and then compiling like 12.1
branch.
checking how to link an embedded Python application... configure:
error: could not find shared library for Python
čt 30. 1. 2020 v 15:17 odesílatel 曾文旌(义从)
napsal:
>
>
> > 2020年1月29日 下午9:48，Robert Haas 写道：
> >
> > On Tue, Jan 28, 2020 at 12:12 PM 曾文旌(义从)
> wrote:
> >>> Opinion by Pavel
> >>> + rel->rd_islocaltemp = true; <<< if this is valid, then the name
> of field "rd_islocaltemp" is not probably
On Tue, Jan 28, 2020 at 02:52:08PM +0100, Tomas Vondra wrote:
> On Tue, Jan 28, 2020 at 02:26:34PM +0100, Julien Rouhaud wrote:
>> There were already some dependencies between the rows since parallel
>> queries were added, as you could see eg. a parallel worker while no
>> query is currently
On Thu, Jan 30, 2020 at 4:11 PM Amit Kapila wrote:
>
> On Fri, Jan 10, 2020 at 10:14 AM Dilip Kumar wrote:
> >
> > On Mon, Jan 6, 2020 at 2:11 PM Amit Kapila wrote:
> > >
> >
> > >
> > > Few more comments:
> > >
> > >
On Wed, Jan 29, 2020 at 9:10 PM Peter Eisentraut
wrote:
>
> On 2020-01-20 06:30, Justin Pryzby wrote:
> > Rebased against 40d964ec997f64227bc0ff5e058dc4a5770a70a9
>
> I'm not sure that description of parallel vacuum in the middle of
> non-full vs. full vacuum is actually that good.
>
I have done
Hello.
# I'm not sure -hakcers is the place for this, though..
I notieced that the official PG12-devel RPM pacakge for RHEL8 mandates
ccache being installed on building of an extension.
$ grep ccache /usr/pgsql-12/lib/pgxs/src/Makefile.global
CLANG = /usr/lib64/ccache/clang
# ccache loses
On Wed, Jan 29, 2020 at 3:43 AM Masahiko Sawada
wrote:
> Thank you for the suggestion. I like your suggestion. We can do an
> integrity check of the user input wrapped key by using HMAC when
> unwrapping. Regarding the output format you meant to use aes-256
> rather than aes-256-key-wrap? I think
Hello
Currently during point-in-time recovery with recovery_target_action = 'pause'
we print log lines:
> LOG: recovery has paused
> HINT: Execute pg_wal_replay_resume() to continue.
My colleague told me that this is a terrible moment: to continue what exactly?
It sounds like "to continue
On Fri, Jan 10, 2020 at 10:14 AM Dilip Kumar wrote:
>
> On Mon, Jan 6, 2020 at 2:11 PM Amit Kapila wrote:
> >
>
> >
> > Few more comments:
> >
> > v4-0007-Implement-streaming-mode-in-ReorderBuffer
> > 1.
> > +ReorderBufferStreamTXN(ReorderBuffer *rb,
Is there any chance this fix will get into the next minor version of PostgreSQL
scheduled for February?
čt 30. 1. 2020 v 11:02 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 30.01.2020 12:52, Pavel Stehule wrote:
>
>
>
> čt 30. 1. 2020 v 10:44 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>>
>>
>> On 30.01.2020 12:23, Pavel Stehule wrote:
>>
On 30.01.2020 12:52, Pavel Stehule wrote:
čt 30. 1. 2020 v 10:44 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 30.01.2020 12:23, Pavel Stehule wrote:
Building regular index requires two kinds of lock:
1. You have to lock pg_class to
Hello,
As reported over on pgsql-general[1], we leak shared memory when we
run out of DSM slots. To see this, add the random-run-out-of-slots
hack I showed in that thread, create and analyze a table t(i) with a
million integers, run with dynamic_shared_memory_type=mmap, and try
SELECT COUNT(*)
čt 30. 1. 2020 v 10:44 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 30.01.2020 12:23, Pavel Stehule wrote:
>
>
> Building regular index requires two kinds of lock:
>> 1. You have to lock pg_class to make changes in system catalog.
>> 2. You need to lock heap
On 30.01.2020 12:23, Pavel Stehule wrote:
Building regular index requires two kinds of lock:
1. You have to lock pg_class to make changes in system catalog.
2. You need to lock heap relation to pervent concurrent updates
while building index.
GTT requires 1) but not 2).
On 29.01.2020 21:16, Robert Haas wrote:
On Wed, Jan 29, 2020 at 10:30 AM Konstantin Knizhnik
wrote:
I think that the idea of calling ambuild() on the fly is not going to
work, because, again, I don't think that calling that from random
places in the code is safe.
It is not a random place
čt 30. 1. 2020 v 9:45 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 29.01.2020 20:37, Pavel Stehule wrote:
>
>
>
> st 29. 1. 2020 v 18:21 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>>
>>
>> On 29.01.2020 20:08, Pavel Stehule wrote:
>>
>>
>
> Can you test this version, Floris? The second two patches are probably not
> helping here, so it would be useful if you could just test 0001-*, and then
> test
> all three together. I can toss the latter two patches if there is no
> additional
> speedup.
>
Here's the results for runs
On 29.01.2020 20:37, Pavel Stehule wrote:
st 29. 1. 2020 v 18:21 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 29.01.2020 20:08, Pavel Stehule wrote:
2. Actually I do not propose some completely new approach. I
try to
This line
https://github.com/postgres/postgres/blob/30012a04a6c8127397a8ab71e160d9c7e7fbe874/src/interfaces/libpq/fe-exec.c#L1073
triggers data race errors when run under ThreadSanitizer (*)
As far as I can tell, the static variable in question is a hack to allow a
couple of deprecated functions
70 matches
Mail list logo
