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
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 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
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
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
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,
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
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 that, and it also makes sure
> >we print warnings about
On Fri, Jul 19, 2019 at 2:35 AM Michael Paquier wrote:
>
> On Thu, Jul 18, 2019 at 09:45:14AM +0900, Michael Paquier wrote:
> > On Wed, Jul 17, 2019 at 07:46:10PM +0200, Julien Rouhaud wrote:
> >> Is it ok to call pg_free(slots) and let caller have a pointer pointing
> > to freed memory?
> >
> >
On Fri, 2019-07-19 at 10:27 +0900, Michael Paquier wrote:
> On Thu, Jul 18, 2019 at 08:40:36AM -0400, Jesper Pedersen wrote:
> > On 7/18/19 1:29 AM, Michael Paquier wrote:
> > > Or more simply like that?
> > > "Note that while WAL will be flushed with this setting,
> > > pg_receivewal never
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
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
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
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
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
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
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 -
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
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
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.
> +$$ =
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:
> >> > >
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 :
+ /*
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 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
> 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
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
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=2019-07-19%2001%3A45%3A28=make
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 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
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 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
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;
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
Tomas Vondra writes:
> [ mcv fixes ]
These patches look OK to me.
regards, tom lane
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
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
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
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.
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
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
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
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 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 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
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
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
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 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
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 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
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,
> > > -
> > > >mt_epqstate, estate,
> > > +
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
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
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 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
69 matches
Mail list logo
