On 2020-12-19 06:00, Craig Ringer wrote:
Patch 1 fixes a bogus tracepoint where an lwlock__acquire event would be
fired from LWLockWaitForVar, despite that function never actually
acquiring the lock.
This was added in 68a2e52bbaf when LWLockWaitForVar() was first
introduced. It looks like a
The symptoms sound consistent with using bleeding-edge Xcode on a
Catalina machine ... please report exact OS and Xcode versions.
macOS 10.15.7 (19H2)
Xcode 12.3 (12C33)
macOS SDK 11.1 (20C63)
Everything is fine if I run "configure" with
PG_SYSROOT=/Library/Developer/CommandLineTools/SDKs/Mac
On 2021/01/12 9:06, Jeff Davis wrote:
Commit 5ee2197767 (about 4 years old) introduced the error:
"IDENTIFY_SYSTEM has not been run before START_REPLICATION"
But it seems like running START_REPLICATION first works (at least in
the simple case).
We should either:
1. Document that IDENTIF
At Thu, 14 Jan 2021 06:46:35 +, Li Japin wrote in
>
> On Jan 14, 2021, at 12:56 PM, Ashutosh Bapat
> mailto:ashutosh.bapat@gmail.com>> wrote:
>
> Hi Japin,
> Thanks for the report.
>
> I think that comment is correct. It refers to the following code
> blocks of XLogSendPhysical()
>
>
"Daniel Westermann (DWE)" writes:
>> in "src/tutorial/funcs.source" there is this block:
>> ...
>> Actually it does work and I do not see a reason why this still should be
>> commented. Thoughts?
>Agreed and done.
Thanks, Tom
On Jan 14, 2021, at 12:56 PM, Ashutosh Bapat
mailto:ashutosh.bapat@gmail.com>> wrote:
Hi Japin,
Thanks for the report.
I think that comment is correct. It refers to the following code
blocks of XLogSendPhysical()
2744 /*
2745 * OK to read and send the slice.
2746 */
2747
On 2021/01/14 14:38, Masahiko Sawada wrote:
On Wed, Jan 13, 2021 at 1:55 PM Fujii Masao wrote:
On Tue, Jan 12, 2021 at 11:09 AM Fujii Masao wrote:
On Tue, Jan 12, 2021 at 10:00 AM Masahiko Sawada wrote:
On Mon, Jan 11, 2021 at 11:00 PM Peter Eisentraut
wrote:
On 2021-01-05 10:56, M
On Wed, Jan 13, 2021 at 5:07 PM Amit Kapila wrote:
>
> On Tue, Jan 12, 2021 at 6:17 PM Peter Smith wrote:
> >
> > On Mon, Jan 11, 2021 at 3:32 PM Amit Kapila wrote:
> > The workers for removed tables are now immediately stopped (like
> > DropSubscription does). Although I did include the AccessE
Hi
rebase
Regards
Pavel
schema-variables-20210114.patch.gz
Description: application/gzip
Hi all,
I have just noticed that aef8948 has removed the last reference to
PG_SHA256_DIGEST_STRING_LENGTH in the code (this was getting used to
know the length of a SHA256 digest encoded to hex for checksum
manifests, but pg_hex_enc_len() calculates the same in a more
consistent way). Attached is
On Wed, Jan 13, 2021 at 11:28:55PM +0900, Fujii Masao wrote:
> On Wed, Jan 13, 2021 at 10:51 PM John Naylor
> wrote:
>> It is strange, now that I think about it. My thinking was that the
>> former wording of "replication timeout" was a less literal
>> reference to the replication_timeout paramete
On Thu, Dec 10, 2020 at 12:16:02PM -0500, Stephen Frost wrote:
> Attached is a patch to change it from a GUC to a compile-time #define
> which is set to 0.9, with accompanying documentation updates.
All the references to checkpoint_target_completion are removed (except
for bgwriter.h as per the pa
On Wed, Jan 13, 2021 at 1:55 PM Fujii Masao wrote:
>
> On Tue, Jan 12, 2021 at 11:09 AM Fujii Masao wrote:
> >
> > On Tue, Jan 12, 2021 at 10:00 AM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Jan 11, 2021 at 11:00 PM Peter Eisentraut
> > > wrote:
> > > >
> > > > On 2021-01-05 10:56, Masahik
On Wed, Jan 13, 2021 at 9:18 PM Amit Kapila wrote:
>
> On Wed, Jan 13, 2021 at 11:18 AM Peter Smith wrote:
> >
> > On Mon, Jan 4, 2021 at 10:48 PM Amit Kapila wrote:
> > > 7.
> > > @@ -905,7 +905,7 @@ replorigin_advance(RepOriginId node,
> > > LWLockAcquire(&replication_state->lock, LW_EXCLUSI
Hi Amit.
PSA the v15 patch for the Tablesync Solution1.
Main differences from v14:
+ Addresses review comment, posted 13/Jan [ak13]
[ak13] =
https://www.postgresql.org/message-id/CAA4eK1KzNbudfwmJD-ureYigX6sNyCU6YgHscg29xWoZG6osvA%40mail.gmail.com
Features:
* The tablesync slot is now p
On Wed, Jan 13, 2021 at 5:40 PM Bharath Rupireddy
wrote:
>
> On Wed, Jan 13, 2021 at 3:16 PM Bharath Rupireddy
> wrote:
> >
> > On Wed, Jan 13, 2021 at 2:36 PM japin wrote:
> > > > In summary, I feel we need to fix the publisher sending the inserts
> > > > even though the table is dropped from t
Michael Paquier writes:
> On Thu, Jan 14, 2021 at 01:17:57AM +, Hou, Zhijie wrote:
Thanks. I am thinking to backpatch this even though there is no
problem reported from any production system. What do you think?
> text_to_cstring() indeed allocates a new string, so the extra
> alloca
On Wed, Jan 13, 2021 at 04:39:40PM +0300, Alexey Kondratov wrote:
> + bits32 options;/* bitmask of
> CLUSTEROPT_* */
>
> This should say '/* bitmask of CLUOPT_* */', I guess, since there are only
> CLUOPT's defined. Otherwise, everything looks as per discussed
On Thu, Jan 14, 2021 at 01:17:57AM +, Hou, Zhijie wrote:
>>> Thanks. I am thinking to backpatch this even though there is no
>>> problem reported from any production system. What do you think?
>>
>> No objections from me.
>
> +1
text_to_cstring() indeed allocates a new string, so the extra
a
Hi Japin,
Thanks for the report.
I think that comment is correct. It refers to the following code
blocks of XLogSendPhysical()
2744 /*
2745 * OK to read and send the slice.
2746 */
2747 resetStringInfo(&output_message);
2748 pq_sendbyte(&output_message, 'w');
2749
2750 p
Hi,
While reading the code about logical replication, I found that
WalSndPrepareWrite function says it use XLogSendPhysical to fill out the
sendtime, however, it actually done by WalSndWriteData. It looks like a
typo, attaching a very small patch to correct it.
--
Regrads,
Japin Li.
ChengDu We
At Thu, 14 Jan 2021 12:34:01 +0900, Fujii Masao wrote
in
> On Thu, Jan 14, 2021 at 10:10 AM Kyotaro Horiguchi
> wrote:
> >
> > At Wed, 13 Jan 2021 16:51:32 -0300, Alvaro Herrera
> > wrote in
> > > On 2021-Jan-13, Fujii Masao wrote:
> > >
> > > > Thanks for the review!
> > > > I'm ok with this
On Wed, Jan 13, 2021 at 10:11:54PM -0500, Tom Lane wrote:
> Should the CF entry for this be closed? The cfbot is still trying to
> apply the patch, and unsurprisingly failing.
Yes, I was going to close it once I was sure that the buildfarm had
nothing to say. Done now.
--
Michael
signature.asc
Hi
2021年1月4日(月) 15:04 torikoshia :
>
> On 2021-01-02 06:49, Justin Pryzby wrote:
> > On Tue, Dec 15, 2020 at 11:47:23AM +0900, torikoshia wrote:
> >> So I'm now thinking about adding a new column in pg_locks which
> >> keeps the time at which locks started waiting.
> >>
> >> Attached a patch.
> >
On Thu, Jan 14, 2021 at 10:10 AM Kyotaro Horiguchi
wrote:
>
> At Wed, 13 Jan 2021 16:51:32 -0300, Alvaro Herrera
> wrote in
> > On 2021-Jan-13, Fujii Masao wrote:
> >
> > > Thanks for the review!
> > > I'm ok with this change (i.e., insert only single row).
> > > Attached is the updated version
Bruce Momjian writes:
> On Thu, Jan 14, 2021 at 11:17:40AM +0900, Michael Paquier wrote:
>> Thanks, Sehrope. I have reviewed the code this morning and fixed
>> that, adjusted a couple of elog() strings I found inconsistent after
>> review and ran pgindent. And applied it.
> Thanks. All my key
On Thu, Jan 14, 2021 at 6:24 AM Tom Lane wrote:
>
> I wrote:
> > Having said that, I'm fine with the idea of just marking these
> > parallel-restricted in HEAD and ignoring the problem in the back
> > branches.
>
> Hearing no complaints, done that way.
Although I thought that backpatching would b
On Thu, Jan 14, 2021 at 11:17:40AM +0900, Michael Paquier wrote:
> On Wed, Jan 13, 2021 at 10:00:49AM -0500, Sehrope Sarkuni wrote:
> > The length functions in src/common/hex.c should cast srclen to uint64 prior
> > to the shift. The current hex_enc_len(...) in encode.c performs such a
> > cast.
>
On Wed, Jan 13, 2021 at 10:00:49AM -0500, Sehrope Sarkuni wrote:
> The length functions in src/common/hex.c should cast srclen to uint64 prior
> to the shift. The current hex_enc_len(...) in encode.c performs such a
> cast.
Thanks, Sehrope. I have reviewed the code this morning and fixed
that, ad
> >>> Your observation seems correct to me, though I have not tried to
> >>> test your patch.
> >>
> >> +1 to apply, this looks correct and passes tests. Scanning around I
> >> +didn't see
> >> any other occurrences of the same pattern.
> >
> > Thanks. I am thinking to backpatch this even though t
From: Tomas Vondra
> FWIW the attached v8 patch does this - most of the conditions are moved to the
> GetModifyBatchSize() callback. I've removed the check for the BatchInsert
> callback, though - the FDW knows whether it supports that, and it seems a bit
> pointless at the moment as there are no
At Wed, 13 Jan 2021 16:51:32 -0300, Alvaro Herrera
wrote in
> On 2021-Jan-13, Fujii Masao wrote:
>
> > Thanks for the review!
> > I'm ok with this change (i.e., insert only single row).
> > Attached is the updated version of the patch.
>
> Looks good to me, thanks!
+1
regards.
--
Kyotaro H
On Tue, Jan 12, 2021 at 01:46:53PM -0500, Bruce Momjian wrote:
> On Tue, Jan 12, 2021 at 01:15:44PM -0500, Bruce Momjian wrote:
> > Well, we have eight unused bits in the IV, so we could just increment
> > that for every hint bit change that uses the same LSN, and then force a
> > dummy WAL record
From: Kyotaro Horiguchi
> > XLogSetRecordFlags(XLOG_MARK_UNIMPORTANT |
> XLOG_MARK_ESSENTIAL);
> > XLogRegisterData((char *) &dummy, sizeof(dummy));
> >
> > (Here's a word play - unimportant but essential, what's that?)
>
> Hmm. Food may not be important to someone but it is essential for
On Wed, Jan 6, 2021 at 7:43 PM Peter Geoghegan wrote:
> More concretely, we could perhaps lower vacuum_cost_page_miss to 5. It
> has had the value as 10 as its default since 2004 (just like
> vacuum_cost_page_dirty, whose default has also not been changed since
> the start). These defaults were de
James Coleman writes:
> On Wed, Jan 13, 2021 at 5:00 PM Tom Lane wrote:
>> [ raised eyebrow ] Surely REINDEX and VACUUM can't run on the same
>> table at the same time.
> + Like any long-running transaction, CREATE INDEX on a
> + table can affect which tuples can be removed by concurrent
> + VA
On Tue, Jan 12, 2021 at 5:49 AM Heikki Linnakangas wrote:
> I did a bit of cleanup on the function signature. The .sql script
> claimed that gist_page_items() took bytea as argument, but in reality it
> was a relation name, as text. I changed it so that it takes a page image
> as argument, instead
I wrote:
> So I'm a little confused as to why this test is failing to fail
> with (I assume) newer Xcode. Can we see the relevant part of
> config.log on your machine?
After further digging I believe I understand what's happening,
and it's a bit surprising we've not been bit by it before.
If the
On Wed, Jan 13, 2021 at 5:00 PM Tom Lane wrote:
>
> James Coleman writes:
> > On Wed, Jan 13, 2021 at 4:29 PM Tom Lane wrote:
> >> but the antecedent of "a table" is a bit unclear; people might
> >> wonder if it means the table being reindexed.
>
> > It does mean the table being reindexed; the l
On Thu, Jan 14, 2021 at 9:26 AM Tom Lane wrote:
> * You need to remove pread.o and pwrite.o from the hard-wired
> part of the list in src/port/Makefile, else they get built
> whether needed or not.
Right, done.
> * I don't much like this in fd.h:
>
> @@ -46,6 +46,7 @@
> #include
>
>
> +struct
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> > On 2020-Dec-10, Stephen Frost wrote:
> > > * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > > > On Tue, 2020-12-08 at 17:29 +, Bossart, Nathan wrote:
> > > > > +1 to setting check
James Coleman writes:
> On Wed, Jan 13, 2021 at 4:29 PM Tom Lane wrote:
>> but the antecedent of "a table" is a bit unclear; people might
>> wonder if it means the table being reindexed.
> It does mean the table being reindexed; the last phrase says "any
> table" meaning "any other table".
[ ra
On Wed, Jan 13, 2021 at 4:29 PM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > On 2021-Jan-13, James Coleman wrote:
> This is true. So I propose
> Like any long-running transaction, REINDEX can
> affect which tuples can be removed by concurrent
> VACUUM
> on any table.
Alvaro Herrera writes:
> On 2021-Jan-13, James Coleman wrote:
This is true. So I propose
Like any long-running transaction, REINDEX can
affect which tuples can be removed by concurrent VACUUM
on any table.
>> Looks like what got committed is "REINDEX on a table" not "on any",
I wrote:
> Having said that, I'm fine with the idea of just marking these
> parallel-restricted in HEAD and ignoring the problem in the back
> branches.
Hearing no complaints, done that way.
regards, tom lane
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> > Thanks. I'll do some testing/benchmarking once my machines are free, in
> > a couple days perhaps. But as I said before, I don't expect this to
> > behave very differently from other
On 2021-Jan-13, James Coleman wrote:
> On Wed, Jan 13, 2021 at 4:05 PM Alvaro Herrera
> wrote:
> >
> > On 2021-Jan-13, James Coleman wrote:
> >
> > > On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera
> > > wrote:
> >
> > > > This is true. So I propose
> > > >
> > > > Like any long-running t
On 2021-Jan-13, Alvaro Herrera wrote:
> I wondered about noting whether only processes in the current database
> are affected, but then I noticed that the current code since commit
> dc7420c2c927 uses a completely different algorithm than what we had with
> GetOldestXmin() and does not consider da
On Wed, Jan 13, 2021 at 4:05 PM Alvaro Herrera wrote:
>
> On 2021-Jan-13, James Coleman wrote:
>
> > On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera
> > wrote:
>
> > > This is true. So I propose
> > >
> > > Like any long-running transaction, REINDEX can
> > > affect which tuples can be
On 2021-Jan-13, James Coleman wrote:
> On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera
> wrote:
> > This is true. So I propose
> >
> > Like any long-running transaction, REINDEX can
> > affect which tuples can be removed by concurrent
> > VACUUM
> > on any table.
>
> That sounds
"Daniel Westermann (DWE)" writes:
> in "src/tutorial/funcs.source" there is this block:
> ...
> Actually it does work and I do not see a reason why this still should be
> commented. Thoughts?
Agreed and done.
regards, tom lane
Thomas Munro writes:
> On Thu, Jan 14, 2021 at 5:13 AM Tom Lane wrote:
>> Looks like we need to be more careful about not including pread.c
>> in the build unless it actually has code to contribute.
> I did it that way because it made it easy to test different
> combinations of the replacements
Fabien COELHO writes:
>> What remains that we could do now, and perhaps back-patch, is point (2)
>> i.e. disallow digits as the first character of a pgbench variable name.
> I'm fine with that.
>> That would be enough to "solve" the original bug report, and it does seem
>> like it could be back-
On Thu, Jan 14, 2021 at 5:13 AM Tom Lane wrote:
> I have a different complaint, using Big Sur and Xcode 12.3:
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
> file: libpgport.a(pread.o) has no symbols
> /Applications/Xcode.app/Contents/Developer
On 2021-Jan-13, Fujii Masao wrote:
> Thanks for the review!
> I'm ok with this change (i.e., insert only single row).
> Attached is the updated version of the patch.
Looks good to me, thanks!
--
Álvaro Herrera39°49'30"S 73°17'W
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Dec 4, 2020 at 02:00:23PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > Yes, that is pretty much the same thing I was suggesting, except that
> > > each rename has its own _original_ URL link, which I
On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera wrote:
>
> On 2021-Jan-13, James Coleman wrote:
>
> > On Wed, Jan 13, 2021 at 12:58 AM Michael Paquier
> > wrote:
> > >
> > > On Tue, Jan 12, 2021 at 04:51:39PM -0300, Alvaro Herrera wrote:
> > > > I looked into this again, and I didn't like what I
On 13 January 2021 13:53:39 EET, Heikki Linnakangas wrote:
>Buildfarm animal thorntail is still not happy:
>
>> ---
>> /home/nm/farm/sparc64_deb10_gcc_64_ubsan/HEAD/pgsql.build/../pgsql/contrib/pageinspect/expected/gist.out
>> 2021-01-13 13:38:09.721752365 +0300
>> +++
>> /home/nm/farm/sparc
Hmmm ... I can further report that on Catalina + Xcode 12.0,
everything seems fine. configure correctly detects that preadv
and pwritev aren't there:
configure:15161: checking for preadv
configure:15161: ccache gcc -o conftest -Wall -Wmissing-prototypes -Wpointer-ar\
ith -Wdeclaration-after-state
On 13 January 2021 20:04:10 EET, Heikki Linnakangas wrote:
>
>
>On 13 January 2021 13:53:39 EET, Heikki Linnakangas wrote:
>>Looks like the LSN on the page is not set to GistBuildLSN as expected.
>>Weird.
>>
>>Thorntail is a sparc64 system, so little-endian, but the other
>>little-endian buildf
>
> In addition to that, a following case would be solved with this approach:
> When many processes are referencing many tables defined foreign key
> constraints thoroughly, a huge amount of memory will be consumed
> regardless of whether referenced tables are partitioned or not.
>
> Attached the p
On Mon, Jan 11, 2021 at 9:26 PM Peter Geoghegan wrote:
> I'm going to proceed with committing the original version of the patch
> -- I feel that this settles it.
Pushed both patches from the patch series just now.
Thanks for the code reviews and benchmarking work!
--
Peter Geoghegan
On 1/13/21 3:43 PM, Tomas Vondra wrote:
>
> ...
>
> Thanks for the report. Yeah, I think there's a missing check in
> ExecInsert. Adding
>
> (!resultRelInfo->ri_TrigDesc->trig_insert_after_row)
>
> solves this. But now I'm wondering if this is the wrong place to make
> this decision. I mean, wh
On 2021-Jan-13, James Coleman wrote:
> On Wed, Jan 13, 2021 at 12:58 AM Michael Paquier wrote:
> >
> > On Tue, Jan 12, 2021 at 04:51:39PM -0300, Alvaro Herrera wrote:
> > > I looked into this again, and I didn't like what I had added to
> > > maintenance.sgml at all. It seems out of place where
I wrote:
> Sergey Shinderuk writes:
note: 'pwritev' has been marked as being introduced in macOS 11.0 here,
but the deployment target is macOS 10.15.0
> The symptoms sound consistent with using bleeding-edge Xcode on a
> Catalina machine ... please report exact OS and Xcode versions.
I
On Tue, 2020-10-27 at 21:07 +0100, Daniel Gustafsson wrote:
> > On 20 Oct 2020, at 21:15, Andres Freund wrote:
> >
> > > +static SECStatus
> > > +pg_cert_auth_handler(void *arg, PRFileDesc * fd, PRBool checksig, PRBool
> > > isServer)
> > > +{
> > > + SECStatus status;
> > > + Port *
Heikki Linnakangas writes:
> On 13/01/2021 11:46, Andrey Borodin wrote:
>> Maybe we can just omit key_data from tests?
> Make sense, fixed it that way. Thanks!
thorntail, at least, is still unhappy.
regards, tom lane
Sergey Shinderuk writes:
> On 13.01.2021 12:56, Thomas Munro wrote:
>> On Wed, Jan 13, 2021 at 10:40 PM Sergey Shinderuk
>> wrote:
>>> note: 'pwritev' has been marked as being introduced in macOS 11.0 here,
>>> but the deployment target is macOS 10.15.0
>> Hrm... So why did "configure" think yo
Hello Tom,
Hi, this entry is "Waiting on Author" and the thread was inactive for a
while. I see this discussion still has some open questions. Are you
going to continue working on it, or should I mark it as "returned with
feedback" until a better time?
IMHO the proposed fix is reasonable an
"David G. Johnston" writes:
> On Wed, Jan 13, 2021 at 6:59 AM Ashutosh Bapat
> wrote:
>> +01 indicates that there's timezone information added to the data, so
>> the rows aren't identical. Here's some more SQL run on my laptop which
>> shows that
> This is indeed true but examples that use the t
On Wed, Jan 13, 2021 at 12:58 AM Michael Paquier wrote:
>
> On Tue, Jan 12, 2021 at 04:51:39PM -0300, Alvaro Herrera wrote:
> > I looked into this again, and I didn't like what I had added to
> > maintenance.sgml at all. It seems out of place where I put it; and I
> > couldn't find any great spot
On Wed, Jan 13, 2021 at 6:59 AM Ashutosh Bapat
wrote:
> +01 indicates that there's timezone information added to the data, so
> the rows aren't identical. Here's some more SQL run on my laptop which
> shows that
>
This is indeed true but examples that use the textual representation of the
data d
The length functions in src/common/hex.c should cast srclen to uint64 prior
to the shift. The current hex_enc_len(...) in encode.c performs such a
cast.
diff --git a/src/common/hex.c b/src/common/hex.c
index 0123c69697..e87aa1fd7f 100644
--- a/src/common/hex.c
+++ b/src/common/hex.c
@@ -178,7 +178
On 1/13/21 10:15 AM, Amit Langote wrote:
> Hi Tomas, Tsunakawa-san,
>
> Thanks for your work on this.
>
> On Tue, Jan 12, 2021 at 11:06 AM Tomas Vondra
> wrote:
>> AFAICS the discussions about making this use COPY and/or libpq
>> pipelining (neither of which is committed yet) ended with the conc
On Wed, Jan 13, 2021 at 10:51 PM John Naylor
wrote:
>
>
> On Tue, Jan 12, 2021 at 9:37 PM Fujii Masao wrote:
> >
> > Thanks for the patch! I think this change makes sense.
> >
> > - (errmsg("terminating walsender process
> > due to replication timeout")));
> > +
On Fri, Jan 8, 2021 at 3:43 PM Drouvot, Bertrand wrote:
>
>
> On 1/8/21 7:24 AM, Fujii Masao wrote:
> > CAUTION: This email originated from outside of the organization. Do
> > not click links or open attachments unless you can confirm the sender
> > and know the content is safe.
> >
> >
> >
> > On
On Fri, Jan 8, 2021 at 2:15 PM Drouvot, Bertrand wrote:
>
> Hi,
>
> On 1/8/21 5:19 AM, Fujii Masao wrote:
> >
> > On 2021/01/08 11:17, Kyotaro Horiguchi wrote:
> >> At Fri, 8 Jan 2021 01:32:11 +0900, Fujii Masao
> >> wrote in
> >>>
> >>> Attached is the updated version of the patch. This can be a
On Wed, Jan 13, 2021 at 4:24 PM Dorian Hoxha wrote:
>
> Hi team,
>
> I have a table with a column of "timestamp without timezone" and I want to
> alter it to a column of "timestamp with timezone" without rewriting the rows.
>
> Looking at the docs, and doing some quick tests, the data-on-disk is
On Tue, Jan 12, 2021 at 9:37 PM Fujii Masao wrote:
>
> Thanks for the patch! I think this change makes sense.
>
> - (errmsg("terminating walsender process
> due to replication timeout")));
> + (errmsg("terminating walsender process
> due
On 2021-01-13 14:34, Michael Paquier wrote:
On Wed, Jan 13, 2021 at 05:22:49PM +0900, Michael Paquier wrote:
Yeah, that makes sense. I'll send an updated patch based on that.
And here you go as per the attached. I don't think that there was
anything remaining on my radar. This version still
> On 13 Jan 2021, at 14:09, Amit Kapila wrote:
>
> On Wed, Jan 13, 2021 at 2:55 PM Daniel Gustafsson wrote:
>>
>>> On 13 Jan 2021, at 07:10, Amit Kapila wrote:
>>
>>> Your observation seems correct to me, though I have not tried to test
>>> your patch.
>>
>> +1 to apply, this looks correct a
On Wed, Jan 13, 2021 at 2:55 PM Daniel Gustafsson wrote:
>
> > On 13 Jan 2021, at 07:10, Amit Kapila wrote:
>
> > Your observation seems correct to me, though I have not tried to test
> > your patch.
>
> +1 to apply, this looks correct and passes tests. Scanning around I didn't
> see
> any othe
On 2021-Jan-13, Simon Riggs wrote:
> On Sun, Jan 10, 2021 at 1:44 AM Tomas Vondra
> wrote:
> > 8) varlena.c
> >
> > Again, why are these changes to length checks in a MERGE patch?
>
> Nothing I added, IIRC, nor am I aware of why that would exist.
Sorry, this was a borked merge.
--
Álvaro Her
On 1/11/21 9:34 AM, Peter Eisentraut wrote:
> On 2020-12-20 18:09, Andrew Dunstan wrote:
>> On 12/19/20 11:19 AM, Andrew Dunstan wrote:
>>> This turns out to be remarkably short, with the use of a little eval
>>> magic.
>>>
>>> Give the attached, this test program works just fine:
>>>
>>> #!
On 1/13/21 11:20 AM, Simon Riggs wrote:
On Sun, Jan 10, 2021 at 1:44 AM Tomas Vondra
wrote:
5) WHEN AND
I admit the "WHEN AND" conditions sounds a bit cryptic - it took me a
while to realize what this refers to. Is that a term established by SQL
Standard, or something we invented?
As Vik
> On 17 Dec 2020, at 22:37, Andrew Dunstan wrote:
> I've been giving some thought to $subject. The initial impetus is the
> promise I made to assist with testing of clients built with NSS against
> servers built with openssl, and vice versa.
Thanks for tackling!
> My main question is: do we wan
On Wed, Jan 13, 2021 at 3:35 PM Dilip Kumar wrote:
>
> On Wed, Jan 13, 2021 at 3:27 PM Yugo NAGATA wrote:
> >
> > On Thu, 10 Dec 2020 11:25:23 +0530
> > Dilip Kumar wrote:
> >
> > > > > However, I wonder users don't expect pg_is_wal_replay_paused to wait.
> > > > > Especially, if max_standby_str
On Wed, Jan 13, 2021 at 3:16 PM Bharath Rupireddy
wrote:
>
> On Wed, Jan 13, 2021 at 2:36 PM japin wrote:
> > > In summary, I feel we need to fix the publisher sending the inserts
> > > even though the table is dropped from the publication, that is the
> > > patch patch proposed by japin. This so
On Wed, Jan 13, 2021 at 5:15 PM Dilip Kumar wrote:
>
> On Wed, Jan 13, 2021 at 3:08 PM Bharath Rupireddy
> wrote:
> >
> > On Wed, Jan 13, 2021 at 2:53 PM Dilip Kumar wrote:
> > > > IIUC the logical replication only replicate the tables in publication,
> > > > I think
> > > > when the tables tha
On 13/01/2021 12:34, Heikki Linnakangas wrote:
On 13/01/2021 11:46, Andrey Borodin wrote:
13 янв. 2021 г., в 13:41, Heikki Linnakangas
написал(а):
One more question: will bytea tests run correctly on
32bit\different-endian systems?
Good question. Somehow I thought we were printing esseantil
On Wed, Jan 13, 2021 at 3:08 PM Bharath Rupireddy
wrote:
>
> On Wed, Jan 13, 2021 at 2:53 PM Dilip Kumar wrote:
> > > IIUC the logical replication only replicate the tables in publication, I
> > > think
> > > when the tables that aren't in publication should not be replicated.
> > >
> > > Attach
On Tue, Jan 12, 2021 at 6:17 PM Peter Smith wrote:
>
> On Mon, Jan 11, 2021 at 3:32 PM Amit Kapila wrote:
> >
> > On Fri, Jan 8, 2021 at 8:20 AM Amit Kapila wrote:
> > >
> > > On Fri, Jan 8, 2021 at 7:14 AM Peter Smith wrote:
> > > >
> > > > FYI, I was able to reproduce this case in debugger. P
On Wed, Jan 13, 2021 at 05:22:49PM +0900, Michael Paquier wrote:
> Yeah, that makes sense. I'll send an updated patch based on that.
And here you go as per the attached. I don't think that there was
anything remaining on my radar. This version still needs to be
indented properly though.
Though
> On Sat, Dec 19, 2020 at 01:00:01PM +0800, Craig Ringer wrote:
>
> The attached patch set follows on from the discussion in [1] "Add LWLock
> blocker(s) information" by adding the actual LWLock* and the numeric
> tranche ID to each LWLock related TRACE_POSTGRESQL_foo tracepoint.
>
> This does not
Hi team,
I have a table with a column of "timestamp without timezone" and I want to
alter it to a column of "timestamp with timezone" without rewriting the
rows.
Looking at the docs, and doing some quick tests, the data-on-disk is
identical for both columns. But when doing an alter table, looks l
Hi,
in "src/tutorial/funcs.source" there is this block:
-
-- Creating SQL Functions with multiple SQL statements
-- you can also create functions that do more than just a SELECT.
--
-- 14MAR99 Clark Evans: Does not quite work, commented out for now.
--
--
On 13/01/2021 11:46, Andrey Borodin wrote:
13 янв. 2021 г., в 13:41, Heikki Linnakangas
написал(а):
One more question: will bytea tests run correctly on
32bit\different-endian systems?
Good question. Somehow I thought we were printing esseantilly text
values as bytea. But they are Points, wh
On Sun, Jan 10, 2021 at 1:44 AM Tomas Vondra
wrote:
> 5) WHEN AND
>
> I admit the "WHEN AND" conditions sounds a bit cryptic - it took me a
> while to realize what this refers to. Is that a term established by SQL
> Standard, or something we invented?
As Vik notes, this refers to the WHEN [NOT]
On Wed, Jan 13, 2021 at 11:18 AM Peter Smith wrote:
>
> On Mon, Jan 4, 2021 at 10:48 PM Amit Kapila wrote:
> > 7.
> > @@ -905,7 +905,7 @@ replorigin_advance(RepOriginId node,
> > LWLockAcquire(&replication_state->lock, LW_EXCLUSIVE);
> >
> > /* Make sure it's not used by somebody else */
> >
On 13.01.2021 12:56, Thomas Munro wrote:
On Wed, Jan 13, 2021 at 10:40 PM Sergey Shinderuk
wrote:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include/sys/uio.h:104:9:
note: 'pwritev' has been marked as being introduced in macOS 11.0 her
1 - 100 of 123 matches
Mail list logo
