On Sat, Jul 20, 2019 at 4:17 AM Peter Geoghegan wrote:
>
> On Fri, Jul 19, 2019 at 12:52 PM Robert Haas wrote:
> > Right, that's definitely a big part of the concern here, but I don't
> > really believe that retaining locks is absolutely required, or even
> > necessarily desirable. For instance,
On Fri, Jul 19, 2019 at 10:58 PM Robert Haas wrote:
>
> One other thing that seems worth noting is that we have to consider
> what happens after a restart. After a crash, and depending on exactly
> how we design it perhaps also after a non-crash restart, we won't
> immediately know how many outst
On Fri, Jul 19, 2019 at 6:35 PM Robert Haas wrote:
>
> On Fri, Jul 19, 2019 at 12:10 AM Amit Kapila wrote:
> > We are doing exactly what you have written in the last line of the
> > next paragraph "stop the transaction from writing undo when the hash
> > table is already too full.". So we will
>
On Fri, Jul 19, 2019 at 6:37 PM Robert Haas wrote:
>
> On Fri, Jul 19, 2019 at 7:54 AM Amit Khandekar wrote:
> > + * We just want to mask the cid in the undo record header. So
> > + * only if the partial record in the current page include the undo
> > + * record header then we need to mask the c
On Fri, Jul 19, 2019 at 12:32 PM Peter Geoghegan wrote:
> On Fri, Jul 19, 2019 at 10:53 AM Anastasia Lubennikova
> wrote:
> > Patch 0002 (must be applied on top of 0001) implements preserving of
> > correct TID order
> > inside posting list when inserting new tuples.
> > This version passes all r
On Fri, Jul 19, 2019 at 08:30:38AM -0400, Andrew Dunstan wrote:
> My tests of the VS2017 stuff used this install mechanism on a fresh
> Windows instance:
>
> choco install -y visualstudio2017-workload-vctools --package-parameters
> "--includeOptional"
>
> This installed Windows Kits 8.1 and 10, a
On Fri, Jul 19, 2019 at 10:40:42PM +0900, Ian Barwick wrote:
> Good point, it does actually fail with an error if an impossible slot name
> is provided, so the escaping is superfluous anyway.
FWIW, ReplicationSlotValidateName() gives the reason behind that
restriction:
Slot names may consist out o
On Fri, Jul 19, 2019 at 4:14 PM Robert Haas wrote:
> I don't think this matters here at all. As long as there's only DML
> involved, there won't be any lock conflicts anyway - everybody's
> taking RowExclusiveLock or less, and it's all fine. If you update a
> row in zheap, abort, and then try to u
On Fri, Jul 19, 2019 at 6:47 PM Peter Geoghegan wrote:
> I believe that the primary reason why certain other database systems
> retain locks until rollback completes (or release their locks in
> reverse order, as UNDO processing progresses) is that application code
> will often repeat exactly the
On Fri, Jul 19, 2019 at 06:12:20AM +, Jamison, Kirk wrote:
On Tuesday, July 9, 2019, Tomas Vondra wrote:
>apparently v1 of the ALTER STATISTICS patch was a bit confused about
>length of the VacAttrStats array passed to statext_compute_stattarget,
>causing segfaults. Attached v2 patch fixes t
On Fri, Jul 19, 2019 at 12:52 PM Robert Haas wrote:
> Right, that's definitely a big part of the concern here, but I don't
> really believe that retaining locks is absolutely required, or even
> necessarily desirable. For instance, suppose that I create a table,
> bulk-load a whole lotta data int
Hi,
On 2019-07-19 17:11:10 -0400, Alvaro Herrera wrote:
> On 2019-Jul-19, Andres Freund wrote:
> > > - slot = ExecDelete(node, tupleid, oldtuple,
> > > planSlot,
> > > -
> > > &node->mt_epqstate, estate,
> > > +
On 2019-Jul-19, Andres Freund wrote:
> On 2019-07-19 17:52:20 +0900, Amit Langote wrote:
> > The first one (0001) deals with reducing the core executor's reliance
> > on es_result_relation_info to access the currently active result
> > relation, in favor of receiving it from the caller as a functi
On 19.07.2019 6:36, Ryan Lambert wrote:
Here's what I found tonight in your latest patch (9). The output from
git apply is better, fewer whitespace errors, but still getting the
following. Ubuntu 18.04 if that helps.
git apply -p1 < builtin_connection_proxy-9.patch
:79: tab in indent.
On Mon, Jul 8, 2019 at 9:37 PM Tomas Vondra
wrote:
> Now, consider this example:
>
> create table t (a int, b int, c int);
> insert into t select mod(i,100),mod(i,100),i from
> generate_series(1,1000) s(i);
> create index on t (a);
> analyze t;
> explain select a,b,sum(c) from t gro
On Wed, 2019-04-03 at 23:20 +, Raymond Martin wrote:
> Hi Christoph,
>
> > you sent the patch as UTF-16, could you re-send it as plain ascii?
>
> Apologies. I re-attached the plain ascii version.
Committed. Thanks!
Regards,
Jeff Davis
On Fri, Jul 19, 2019 at 4:29 PM Tom Lane wrote:
>
> Mike Palmiotto writes:
> > We probably need to polish this a bit more, but what do you think
> > about something similar to the attached patches? They should hopefully
> > reduce some of the complexity of running these regression tests.
>
> I ca
Mike Palmiotto writes:
> We probably need to polish this a bit more, but what do you think
> about something similar to the attached patches? They should hopefully
> reduce some of the complexity of running these regression tests.
I can confirm that the 0001 patch fixes things on my Fedora 30 box
On 2019-07-19 15:57:45 -0400, Robert Haas wrote:
> On Fri, Jul 19, 2019 at 3:12 PM Andres Freund wrote:
> > Isn't that pretty inherently required? How are otherwise ever going to
> > be able to roll back a transaction that holds an AEL on a relation it
> > also modifies? I might be standing on my
On Fri, Jul 19, 2019 at 3:12 PM Andres Freund wrote:
> On 2019-07-19 14:50:22 -0400, Robert Haas wrote:
> > On Fri, Jul 19, 2019 at 2:04 PM Andres Freund wrote:
> > > It doesn't seem that hard - and kind of required for robustness
> > > independent of the decision around "completeness" - to find
On Fri, Jul 19, 2019 at 11:19 AM Tom Lane wrote:
>
> I got around to trying this, and lookee here:
>
> $ sudo sesearch -A -s sepgsql_regtest_user_t -t passwd_file_t
> allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
> allow domain file_type:chr_file map; [ domain_can_mmap_files
On Fri, Jul 19, 2019 at 2:57 PM Peter Geoghegan wrote:
> On Fri, Jul 19, 2019 at 10:28 AM Robert Haas wrote:
> > In scenario #2, the undo work is going to have to be retried in the
> > background, and perforce that means reacquiring locks that have been
> > released, and so there is a chance of l
On Fri, Jul 19, 2019 at 10:53 AM Anastasia Lubennikova
wrote:
> Patch 0002 (must be applied on top of 0001) implements preserving of
> correct TID order
> inside posting list when inserting new tuples.
> This version passes all regression tests including amcheck test.
> I also used following scrip
Hi,
On 2019-07-19 14:50:22 -0400, Robert Haas wrote:
> On Fri, Jul 19, 2019 at 2:04 PM Andres Freund wrote:
> > It doesn't seem that hard - and kind of required for robustness
> > independent of the decision around "completeness" - to find a way to use
> > the locks already held by the prepared t
On Fri, Jul 19, 2019 at 10:28 AM Robert Haas wrote:
> In scenario #2, the undo work is going to have to be retried in the
> background, and perforce that means reacquiring locks that have been
> released, and so there is a chance of long lock waits and/or deadlock
> that cannot really be avoided.
I wrote:
> Michael Paquier writes:
>> This is causing a compilation warning on Windows:
> ...so I think your compiler has a point. I shall complain to upstream.
The IANA folk want to fix it like this:
diff --git a/zic.c b/zic.c
index 8bf5628..a84703a 100644
--- a/zic.c
+++ b/zic.c
@@ -2145,7 +2
I would like to help review this documentation. Can you please point me in
the right direction?
Thanks
Steve
On Fri, Jul 19, 2019 at 2:02 AM Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Jul 18, 2019 at 5:08 PM Thom Brown wrote:
> > On Tue, 16 Jul 2019 at 19:44, Alexander Koro
On Fri, Jul 19, 2019 at 2:04 PM Andres Freund wrote:
> It doesn't seem that hard - and kind of required for robustness
> independent of the decision around "completeness" - to find a way to use
> the locks already held by the prepared transaction.
I'm not wild about finding more subtasks to put o
Tomas Vondra writes:
> [ mcv fixes ]
These patches look OK to me.
regards, tom lane
Hi,
On 2019-07-19 13:54:59 +1200, David Rowley wrote:
> On Thu, 18 Jul 2019 at 14:30, Andres Freund wrote:
> > I think the AM part of this patch might be the wrong approach - it won't
> > do anything meaningful for an AM that doesn't directly map the ctid to a
> > specific location in a block (e.
I wrote:
> So I think we're probably stuck with the approach of adding new internal
> dependencies. If we go that route, then our options for the released
> branches are (1) do nothing, or (2) back-patch the code that adds such
> dependencies, but without a catversion bump. That would mean that o
Hi,
On 2019-07-19 13:28:14 -0400, Robert Haas wrote:
> I want to consider three specific scenarios that could cause undo
> application to fail, and then offer some observations about them.
>
> Scenario #1:
>
> 1. Sessions 1..N each begin a transaction and write a bunch of data to
> a table (at l
On Tue, Jul 16, 2019 at 9:38 PM Michael Paquier wrote:
> I think we should really document the caveat with priority-based sets
> of standbys as much as quorum-based sets. For example if a user sets
> synchronous_commit = remote_apply in postgresql.conf, and then sets
> s_s_names to '2(pg_receivew
17.07.2019 19:36, Anastasia Lubennikova:
There is one major issue left - preserving TID order in posting lists.
For a start, I added a sort into BTreeFormPostingTuple function.
It turned out to be not very helpful, because we cannot check this
invariant lazily.
Now I work on patching _bt_bins
On Tue, Jul 16, 2019 at 6:23 PM Andres Freund wrote:
> Yea, that seems like a question independent of the "completeness"
> requirement. If desirable, it seems trivial to either have
> RollbackHashEntry have per-persistence level status (for one entry per
> xid), or not (for per-persistence entries
Hi,
On 2019-07-10 15:31:11 +0200, Magnus Hagander wrote:
> In re-reading this, I notice there are a lot of references to Intterrupt
> (with two t). I'm guessing this is just a spelling error, and not something
> that actually conveys some meaning?
Just a spelling error. I think I wrote the patch
Hi,
On 2019-07-07 10:00:35 -0700, Noah Misch wrote:
> On Tue, Nov 20, 2018 at 01:20:04AM -0800, Andres Freund wrote:
> > On 2018-11-14 21:02:41 -0800, Andres Freund wrote:
> > > > The point of the test is to exercise OidGenLock by issuing many parallel
> > > > GetNewOidWithIndex() and verifying ab
Hi,
On 7/18/19 9:09 PM, Michael Paquier wrote:
pg_receivewal -D /tmp/wal -S replica1 --synchronous -h localhost -p 5432 -U
repluser -W
psql -c 'SELECT * FROM pg_stat_replication;' postgres
psql -c 'SELECT * FROM pg_replication_slots;' postgres
psql -c 'CREATE DATABASE test' postgres
In what sce
Hi,
On 7/18/19 9:27 PM, Michael Paquier wrote:
The location of the warning is
also harder to catch for the reader, so instead let's move it to the
top where we have an extra description for --synchronous. I am
finishing with the attached that I would be fine to commit and
back-patch as needed.
Hi,
On 2019-07-19 17:52:20 +0900, Amit Langote wrote:
> Attached are two patches.
Awesome.
> The first one (0001) deals with reducing the core executor's reliance
> on es_result_relation_info to access the currently active result
> relation, in favor of receiving it from the caller as a functio
On Thu, Jul 18, 2019 at 11:16:08AM -0400, Tom Lane wrote:
Tomas Vondra writes:
I've pushed the fixes listed in the previous message, with the exception
of the collation part, because I had some doubts about that.
Sorry for being slow on this.
Now, for the collation part - after some more th
Mike Palmiotto writes:
> The sepgsql_regtest_user_t domain should be allowed to read any file
> labeled "passwd_file_t". We can check that with the `sesearch` tool,
> provided by the "setools-console" package on F30:
> % sudo sesearch -A -s sepgsql_regtest_user_t -t passwd_file_t
> allow domain f
Mike Palmiotto writes:
> On Thu, Jul 18, 2019 at 11:06 PM Tom Lane wrote:
>>> $ runcon -t sepgsql_regtest_user_t psql --help
>>> psql: fatal: could not look up effective user ID 1000: user does not exist
> You can rule out SELinux for this piece by running `sudo setenforce
> 0`. If the `runcon .
Tomas Vondra wrote:
> On Fri, Jul 19, 2019 at 12:04:36PM +0200, Antonin Houska wrote:
> >Tomas Vondra wrote:
> >
> >> On Mon, Jul 15, 2019 at 03:42:39PM -0400, Bruce Momjian wrote:
> >> >On Sat, Jul 13, 2019 at 11:58:02PM +0200, Tomas Vondra wrote:
> >> >> One extra thing we should consider is a
On Thu, Jul 18, 2019 at 2:55 AM Etsuro Fujita wrote:
> I.e., partition_bounds_merge() is performed for each pair of input
> partitioned relations for a join relation in try_partitionwise_join().
> Since partition_bounds_merge() would need a lot of CPU cycles, I don't
> think this is acceptable; IS
On 7/19/19 7:45 PM, Sergei Kornilov wrote:
Hi
Oh. Replication slot name currently can contains only a-z0-9_ characters. So
we can not actually write such recovery.conf, pg_basebackup will stop
before. But perform escape_quotes on string and not use result - error anyway.
Good point, it does ac
On Thu, Jul 18, 2019 at 11:06 PM Tom Lane wrote:
>
> Mike Palmiotto writes:
> > On Wed, Jul 17, 2019 at 12:32 PM Tom Lane wrote:
> >> $ runcon -t sepgsql_regtest_user_t psql --help
> >> psql: fatal: could not look up effective user ID 1000: user does not exist
You can rule out SELinux for this
On Fri, Jul 19, 2019 at 7:54 AM Amit Khandekar wrote:
> + * We just want to mask the cid in the undo record header. So
> + * only if the partial record in the current page include the undo
> + * record header then we need to mask the cid bytes in this page.
> + * Otherwise, directly jump to the n
On Fri, Jul 19, 2019 at 12:10 AM Amit Kapila wrote:
> We are doing exactly what you have written in the last line of the
> next paragraph "stop the transaction from writing undo when the hash
> table is already too full.". So we will
> never face the problems related to repeated crash recovery.
On 7/19/19 1:08 AM, Michael Paquier wrote:
> Hi all,
>
> Just browsing through the logs of the buildfarm, I have noticed that
> some buildfarm animals complain with warnings (jacana uses MinGW):
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=jacana&dt=2019-07-19%2001%3A45%3A28&st
On 7/19/19 5:51 AM, Michael Paquier wrote:
>
>> I'm also very curious on how hamerkop and bowerbird build postgres with
>> VS2017. Looks like hamerkop and bowerbird both exist before VS2017
>> and maybe they get SDK v8.1 from previous VS installations. I will
>> contact admin of hamerkop and bow
> On 17 Jul 2019, at 22:35, Tom Lane wrote:
>
> Thinking more about the public/private field distinction we just
> specified --- it's always annoyed me that SPITupleTable doesn't
> provide a number-of-valid-rows field, so that callers have to
> look at the entirely separate SPI_processed variable
On Fri, Jul 19, 2019 at 01:32:01PM +0200, Antonin Houska wrote:
Tomas Vondra wrote:
On Mon, Jul 15, 2019 at 06:11:41PM -0400, Bruce Momjian wrote:
>On Mon, Jul 15, 2019 at 11:05:30PM +0200, Tomas Vondra wrote:
>> On Mon, Jul 15, 2019 at 03:42:39PM -0400, Bruce Momjian wrote:
>> > On Sat, Jul 1
On Fri, Jul 19, 2019 at 12:04:36PM +0200, Antonin Houska wrote:
Tomas Vondra wrote:
On Mon, Jul 15, 2019 at 03:42:39PM -0400, Bruce Momjian wrote:
>On Sat, Jul 13, 2019 at 11:58:02PM +0200, Tomas Vondra wrote:
>> One extra thing we should consider is authenticated encryption. We can't
>> just
On Thu, 9 May 2019 at 12:04, Dilip Kumar wrote:
> Patches can be applied on top of undo branch [1] commit:
> (cb777466d008e656f03771cf16ec7ef9d6f2778b)
>
> [1] https://github.com/EnterpriseDB/zheap/tree/undo
Below are some review points for 0009-undo-page-consistency-checker.patch :
+ /* Calcu
Tomas Vondra wrote:
> On Mon, Jul 15, 2019 at 06:11:41PM -0400, Bruce Momjian wrote:
> >On Mon, Jul 15, 2019 at 11:05:30PM +0200, Tomas Vondra wrote:
> >> On Mon, Jul 15, 2019 at 03:42:39PM -0400, Bruce Momjian wrote:
> >> > On Sat, Jul 13, 2019 at 11:58:02PM +0200, Tomas Vondra wrote:
> >> > > O
Hi,
Thanks for the review. Please find my comments in-line.
On Fri, Jul 19, 2019 at 8:33 AM Kyotaro Horiguchi
wrote:
>
> Hello.
>
>
> +ECPG: CallStmtCALLfunc_application
>
> Even though it is the default behavior, but as a written rule
> this needs the postfix "block".
>
Done.
> +$$ = ca
On Mon, Jul 8, 2019 at 5:03 PM Etsuro Fujita
wrote:
> On Wed, Jul 3, 2019 at 3:44 PM Etsuro Fujita
> wrote:
> > On Tue, Jul 2, 2019 at 1:47 PM amul sul wrote:
> > > Attached version is rebase atop of the latest master head(c74d49d41c),
> thanks.
> >
> > Thanks! Will review.
>
> I started revie
Hi
Oh. Replication slot name currently can contains only a-z0-9_ characters. So we
can not actually write such recovery.conf, pg_basebackup will stop before. But
perform escape_quotes on string and not use result - error anyway.
regards, Sergei
Tomas Vondra wrote:
> On Mon, Jul 15, 2019 at 03:42:39PM -0400, Bruce Momjian wrote:
> >On Sat, Jul 13, 2019 at 11:58:02PM +0200, Tomas Vondra wrote:
> >> One extra thing we should consider is authenticated encryption. We can't
> >> just encrypt the pages (no matter which AES mode is used - XTS/C
On Fri, Jul 19, 2019 at 03:39:49PM +0800, Peifeng Qiu wrote:
> I updated the patch to only include the WindowsTargetPlatformVersion node
> if WindowsSDKVersion is present. I can confirm that this issue no
> longer exists for VS2019. So only VS2017 is problematic.
(Could you please avoid to top-po
On Thu, Jul 18, 2019 at 5:08 PM Thom Brown wrote:
> On Tue, 16 Jul 2019 at 19:44, Alexander Korotkov
> wrote:
> >
> > On Tue, Jul 16, 2019 at 9:22 PM Thom Brown wrote:
> > > Now I'm looking at the @? and @@ operators, and getting a bit
> > > confused. This following query returns true, but I ca
On Thu, Jul 11, 2019 at 9:17 AM Dilip Kumar wrote:
>
> On Thu, Jul 11, 2019 at 12:38 AM Robert Haas wrote:
> >
> > I don't like the fact that undoaccess.c has a new global,
> > undo_compression_info. I haven't read the code thoroughly, but do we
> > really need that? I think it's never modified
On Thu, Jul 18, 2019 at 4:50 PM Amit Langote wrote:
> On Thu, Jul 18, 2019 at 2:53 PM Andres Freund wrote:
> > On 2019-07-18 14:24:29 +0900, Amit Langote wrote:
> > > On Thu, Jul 18, 2019 at 10:09 AM Andres Freund wrote:
> > Or perhaps the actually correct fix is to remove es_result_relation_inf
Hi
In pg_basebackup's GenerateRecoveryConf() function, the value for
"primary_slot_name" is escaped, but the original, non-escaped value
is written. See attached patch.
This has been present since the code was added in 9.6 (commit 0dc848b0314).
Regards
Ian Barwick
--
Ian Barwick
Hi Michael. Thanks for your review.
I updated the patch to only include the WindowsTargetPlatformVersion node
if WindowsSDKVersion is present.
I can confirm that this issue no longer exists for VS2019. So only VS2017
is problematic.
I'm also very curious on how hamerkop and bowerbird build postgre
66 matches
Mail list logo
