> "Andrew" == Andrew Gierth writes:
Andrew> And again to fix the windows build
And again to see if it actually compiles now...
--
Andrew (irc:RhodiumToad)
diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/float.c
index cf9327f885..24d41c2e89 100644
--- a/src/backend/util
On 14/12/2018 01:23, Michael Paquier wrote:
> On Thu, Dec 13, 2018 at 07:14:57PM -0500, Stephen Frost wrote:
>> Based on at least a quick looking around, the actual grammar rule seems
>> to match my recollection[1], adverbs should typically go AFTER the
>> verb + object, and the adverb shouldn't ev
On 14/12/2018 01:14, Stephen Frost wrote:
reindex table CONCURRENTLY test;
>>
>> By the way, does this syntax make sense? I haven't seen a discussion on
>> this anywhere in the various threads. I keep thinking that
>>
>> reindex concurrently table test;
>>
>> would make more sense. How
On Thu, Dec 13, 2018 at 01:51:48PM +0300, Sergei Kornilov wrote:
> Depends on this discussion:
> https://www.postgresql.org/message-id/20181212053042.gk17...@paquier.xyz
> If walreceiver will use GUC conninfo for startup - then yes, we can
> remove such static variables. If walreceiver will still
On 14/12/2018 06:41, David Fetter wrote:
> There are problems tab completion, e.g. its catalog queries, could
> cause in production that would be difficult to simulate elsewhere.
Where are all these reports of tab completion query problems that we are
building elaborate infrastructure to diagnose?
Matsumura-san,
> > I meaned that existing applications that receive data of bytea
> > column
> > with using sqlda will encounter their unknown type(=ECPG.bytea) in
> > sqlvar_struct.sqltype.
> >
> > You mean if they are not recompiled? If so, yes, how else could
> > that be
> > handled?
>
> Even
Hi,
+++ Andreas Karlsson [13/12/18 01:30 +0100]:
On 12/11/18 3:52 PM, Pablo Iranzo Gómez wrote:
I came to this old thread while trying to figure out on how to setup
postgres replication behind OpenShift/Kubernetes behind a route
(which only forwards 80 or 443 traffic), but could work if SNI is
While looking code further around this, I realized that we need
similar kind of fix for bitmap as well as index only scan as well.
Here is the patch, which does similar fix for bitmap and indexonly
scans.
Thanks,
On Fri, Nov 23, 2018 at 6:47 PM Rushabh Lathia
wrote:
>
>
> On Fri, Nov 23, 2018
On Fri, Dec 14, 2018 at 12:23:17AM -0500, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Dec 13, 2018 at 07:43:52PM +0100, Peter Eisentraut wrote:
> >> I'm not sure that this should be a run-time option.
>
> > Given the often onerous givens of installing new software on
> > production machine
čt 13. 12. 2018 v 10:23 odesílatel Simon Riggs
napsal:
> Currently, tables provide MVCC access semantics as the only option.
>
> A more complete list of desirable semantics in applications are
>
> * MVCC - provide latest consistent view
> * Historical - keep all old row versions so that queries c
David Fetter writes:
> On Thu, Dec 13, 2018 at 07:43:52PM +0100, Peter Eisentraut wrote:
>> I'm not sure that this should be a run-time option.
> Given the often onerous givens of installing new software on
> production machines, I'm thinking it actually should be.
What's that have to do with it
Hi,
On 2018/12/12 10:48, Michael Paquier wrote:
> On Fri, Dec 07, 2018 at 11:46:05AM +0900, Michael Paquier wrote:
>> On Thu, Dec 06, 2018 at 10:48:59PM -0300, Alvaro Herrera wrote:
>>> I think adding a pg_partition_root() call to as many pg_partition_tree
>>> tests as you modified is overkill ...
Andres Freund writes:
> On December 13, 2018 6:01:04 PM PST, Tom Lane wrote:
>> Has anyone tried to reproduce this on other platforms?
> I recently also hit this locally, but since that's also Debian unstable...
> Note that removing openssl "fixed" the issue for me.
FWIW, I tried to reproduce
On Thu, Dec 13, 2018 at 07:43:52PM +0100, Peter Eisentraut wrote:
> On 13/12/2018 12:07, Kyotaro HORIGUCHI wrote:
> > - v6-0002-Add-psql-g-option-to-control-debug-print.patch
> >
> > Applies on top of 0001. Code is always active, -g addition to
> > -L activates debug print into the log file. I
On 2018/11/09 14:04, Amit Langote wrote:
> On 2018/11/09 4:39, Alvaro Herrera wrote:
>> I included the test case for collations to the three branches, but no
>> code changes. We can patch master for the handling of collations per
>> your patch,
>
> Okay, but should we back-patch it by adding WARN
Tomas Vondra writes:
> On 11/8/18 1:07 PM, Tomas Vondra wrote:
>> Not sure what to do about this - maybe we should wildcard this first
>> frame, to accept all wcsnlen variants. Opinions?
> I've committed this with the first frame wirldcarded, and backpatched it
> all the way back to 9.4.
So I ju
Hi,
Currently nbtree and hash indexes (and soon gist, where it's missing due
to oversight) compute an xid that is used to resolve recovery conflicts.
They do so by visiting all the heap pages
xl_btree_delete/xl_hash_vacuum_one_page point to item-by-item.
That's problematic for two projects I'm wo
On 2018/12/10 0:57, Amit Langote wrote:
> On Sun, Dec 9, 2018 at 8:13 PM David Rowley
> wrote:
>> listp1 was scanned twice (loops=2), listp2 was scanned just once.
>>
>> Now it is true that if the subplan was executed 0 times that it will
>> appear as "(never executed)", but do we really need to e
On Fri, Dec 14, 2018 at 1:15 PM Andres Freund wrote:
> On December 13, 2018 6:01:04 PM PST, Tom Lane wrote:
> >Thomas Munro writes:
> >> Since libcrypto.so is implicated, Andres asked me off-list if my
> >> changes to random number state initialisation might be linked to
> >> skink's failures be
On December 13, 2018 6:01:04 PM PST, Tom Lane wrote:
>Thomas Munro writes:
>> Since libcrypto.so is implicated, Andres asked me off-list if my
>> changes to random number state initialisation might be linked to
>> skink's failures beginning 12 or 15 days ago. It appears not, as it
>> was gree
Thomas Munro writes:
> Since libcrypto.so is implicated, Andres asked me off-list if my
> changes to random number state initialisation might be linked to
> skink's failures beginning 12 or 15 days ago. It appears not, as it
> was green for several runs after that commit.
> ...
> It's Debian unst
Hello,
Since libcrypto.so is implicated, Andres asked me off-list if my
changes to random number state initialisation might be linked to
skink's failures beginning 12 or 15 days ago. It appears not, as it
was green for several runs after that commit. Looking at the report:
==2802== VALGRINDERRO
Meskes-san
> > > > The patch does not support ECPG.bytea in sqltype of "struct
> > > > sqlvar_struct"
> > > > because of compatibility.
> >
> > Sorry I do not really understand what you mean. Could you please
> > explain?
>
> I meaned that existing applications that receive data of bytea column
On 12/13/18 08:07, Andreas Karlsson wrote:
> But I will attach my small patch for this, which I am now opposed to, anyway
> so the code exists if a use case turns up in the future (or if it turns out
> my reasoning above is incorrect).
Here's the same patch with one small copy-pasto fixed.
-Chap
Andres Freund writes:
> [ separation of FirstBootstrapObjectId and FirstGenbkiObjectId ]
It seems like we should also add a check to genbki.pl that the ending
value of GenbkiNextOid is <= FirstBootstrapObjectId, so that we'll
certainly notice when it's necessary to adjust those boundaries.
(Ther
Hi,
On 2018-12-13 19:32:19 -0500, Robert Haas wrote:
> On Wed, Dec 12, 2018 at 3:41 PM Andres Freund wrote:
> > I don't like the approach of managing the catalog horizon via those
> > periodically logged catalog xmin announcements. I think we instead
> > should build ontop of the records we alre
On Wed, Dec 12, 2018 at 3:41 PM Andres Freund wrote:
> I don't like the approach of managing the catalog horizon via those
> periodically logged catalog xmin announcements. I think we instead
> should build ontop of the records we already have and use to compute
> snapshot conflicts. As of HEAD
On Thu, Dec 13, 2018 at 03:34:56PM +0900, Amit Langote wrote:
> Thank you Michael for taking care of this. I agree with the consensus
> that instead of throwing an error for unsupported relkinds,
> pg_partition_tree should rather return single row containing NULL for all
> columns.
Cool, thanks f
On Thu, Dec 13, 2018 at 03:28:15PM -0800, Andres Freund wrote:
> nbtxlog.c has a fairly large section of code commented out with #ifdef
> UNUSED. With a node justifying that with:
>
> +* This section of code is thought to be no longer needed, after
> +* analysis of the calling paths. It is
On Thu, Dec 13, 2018 at 07:14:57PM -0500, Stephen Frost wrote:
> Based on at least a quick looking around, the actual grammar rule seems
> to match my recollection[1], adverbs should typically go AFTER the
> verb + object, and the adverb shouldn't ever be placed between the verb
> and the object.
On Thu, Dec 13, 2018 at 11:53:53AM -0500, David Steele wrote:
> I also think we should consider back-patching this change. It's hard to
> imagine that archive commands would have trouble with this reordering
> and the current ordering causes real pain in HA clusters.
I would like to hear opinion
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 09/12/2018 19:55, Sergei Kornilov wrote:
> >> reindex table CONCURRENTLY test;
>
> By the way, does this syntax make sense? I haven't seen a discussion on
> this anywhere in the various threads. I keep thinking that
>
On Thu, Dec 13, 2018 at 02:58:02PM -0300, Alvaro Herrera wrote:
> On 2018-Dec-13, Michael Paquier wrote:
>> Attached is an updated version for that as 0001. Thanks for the
>> review. Does that part look good to you now?
>
> +1.
Thanks for the review, I have applied this part.
> Hmm ... "routin
On Thu, Dec 13, 2018 at 2:29 PM David Steele wrote:
> Good question.
>
> We could leave the third parameter (changing the default to false) and
> error if it has any value but false. It's a bit ugly but it does
> maintain compatibility with the current non-exclusive backup interface.
> And, the
Hi,
nbtxlog.c has a fairly large section of code commented out with #ifdef
UNUSED. With a node justifying that with:
+* This section of code is thought to be no longer needed, after
+* analysis of the calling paths. It is retained to allow the code
+* to be reinstated if a flaw is rev
On 09/12/2018 19:55, Sergei Kornilov wrote:
>> reindex table CONCURRENTLY test;
By the way, does this syntax make sense? I haven't seen a discussion on
this anywhere in the various threads. I keep thinking that
reindex concurrently table test;
would make more sense. How about in combinati
On 2018-12-11 15:08:02 -0800, Andres Freund wrote:
> Hi,
>
> On 2018-12-09 18:43:14 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2018-12-09 17:14:42 -0500, Tom Lane wrote:
> > >> Well, that's just a different very-easily-broken assumption. There are
> > >> a lot of things that make
On 2018-Dec-13, Andrew Gierth wrote:
> And again to fix the windows build - why does Mkvcbuild.pm have its own
> private copy of the file list for src/common?
I think at some point the Makefile parsing code was too stupid to deal
with the src/port Makefile, so it was hardcoded; later probably I
c
> "Andrew" == Andrew Gierth writes:
Andrew> This code in particular was very heavily into using mixed
Andrew> declarations and code throughout. Removing those was moderately
Andrew> painful.
Andrew> And it turns out I missed one, sigh.
Andrew> Updated patch.
And again to fix the windo
On Fri, Dec 14, 2018 at 8:00 AM Andres Freund wrote:
> Hi,
>
> On 2018-12-13 20:53:23 +, Andrew Gierth wrote:
> > > "Andres" == Andres Freund writes:
> >
> > >> This code in particular was very heavily into using mixed
> > >> declarations and code throughout. Removing those was moderate
> "Andrew" == Andrew Gierth writes:
Andrew> This code in particular was very heavily into using mixed
Andrew> declarations and code throughout. Removing those was moderately
Andrew> painful.
Andrew> And it turns out I missed one, sigh.
Updated patch.
--
Andrew (irc:RhodiumToad)
diff
> "Andrew" == Andrew Gierth writes:
Andrew> This code in particular was very heavily into using mixed
Andrew> declarations and code throughout. Removing those was moderately
Andrew> painful.
And it turns out I missed one, sigh.
--
Andrew (irc:RhodiumToad)
Hi,
On 2018-12-13 20:53:23 +, Andrew Gierth wrote:
> > "Andres" == Andres Freund writes:
>
> >> This code in particular was very heavily into using mixed
> >> declarations and code throughout. Removing those was moderately
> >> painful.
>
> Andres> I wonder if we should instead rela
> "Andres" == Andres Freund writes:
>> This code in particular was very heavily into using mixed
>> declarations and code throughout. Removing those was moderately
>> painful.
Andres> I wonder if we should instead relax those restriction for the
Andres> largely foreign pieces of code?
Hi pgsql-hackers,
I have an extension for postgresql. The extension works across some
databases, and needs to save some data. The data might be modified
dynamically by the extension, and all the changed result must be saved. I
have considered some methods.
1. Use GUC
I find no easy way to write th
Hi,
On 2018-12-13 20:23:51 +, Andrew Gierth wrote:
> > "Andres" == Andres Freund writes:
>
> >> From the upstream, I've taken only specific files which are
> >> Boost-licensed, removed code not of interest to us, removed
> >> C99-isms, applied project style for things like type names
> "Andres" == Andres Freund writes:
>> From the upstream, I've taken only specific files which are
>> Boost-licensed, removed code not of interest to us, removed
>> C99-isms, applied project style for things like type names and use
>> of INT64CONST, removed some ad-hoc configuration #ifs
On 2018-12-13 14:50:53 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-12-13 15:05:40 +0100, Peter Eisentraut wrote:
> >> On 12/12/2018 18:56, Andres Freund wrote:
> >>> Why isn't this integrated into fmgr_info()?
>
> >> fmgr_info() looks up stuff in pg_proc. pg_newlocale_...() looks
Hi,
On 2018-12-13 19:41:55 +, Andrew Gierth wrote:
> This is a mostly cleaned-up version of the test patch I posted
> previously for floating-point output using the Ryu algorithm.
Nice!
> From the upstream, I've taken only specific files which are
> Boost-licensed, removed code not of inter
Andres Freund writes:
> On 2018-12-13 15:05:40 +0100, Peter Eisentraut wrote:
>> On 12/12/2018 18:56, Andres Freund wrote:
>>> Why isn't this integrated into fmgr_info()?
>> fmgr_info() looks up stuff in pg_proc. pg_newlocale_...() looks up
>> stuff in pg_collation. There is no overlap between
On Thu, Dec 13, 2018 at 10:46 PM Andres Freund wrote:
> On 2018-12-13 22:40:59 +0300, Alexander Korotkov wrote:
> > It doesn't mater, because we release all locks on every buffer at one
> > time. The unlock order can have effect on what waiter will acquire
> > the lock next after ginRedoDeletePag
Hi,
On 2018-12-13 22:40:59 +0300, Alexander Korotkov wrote:
> It doesn't mater, because we release all locks on every buffer at one
> time. The unlock order can have effect on what waiter will acquire
> the lock next after ginRedoDeletePage(). However, I don't see why one
> unlock order is bette
This is a mostly cleaned-up version of the test patch I posted
previously for floating-point output using the Ryu algorithm.
Upstream source: github.com/ulfjack/ryu/ryu at commit 795c8b57a
>From the upstream, I've taken only specific files which are
Boost-licensed, removed code not of interest to
On Thu, Dec 13, 2018 at 8:06 PM Andrey Borodin wrote:
> > if (BufferIsValid(lbuffer))
> > UnlockReleaseBuffer(lbuffer);
> > if (BufferIsValid(pbuffer))
> > UnlockReleaseBuffer(pbuffer);
> > if (BufferIsValid(dbuffer))
> > UnlockReleaseBuffer(dbuffer);
> > ==>
> > if (BufferIsValid(pbuffer))
> > Un
Hi,
On 2018-12-13 15:05:40 +0100, Peter Eisentraut wrote:
> On 12/12/2018 18:56, Andres Freund wrote:
> >> This makes the collation lookup more similar to the function lookup. In
> >> many cases they now happen right next to each other.
> >> pg_newlocale_from_collation() becomes analogous to fmgr
On 12/13/18 2:00 PM, Peter Eisentraut wrote:
> On 11/12/2018 23:24, David Steele wrote:
>> @@ -845,7 +838,7 @@ test ! -f
>> /mnt/server/archivedir/000100A90065 && cp pg_wal/0
>> rights to run pg_start_backup (superuser, or a user who has been
>> granted
>> EXECUTE on the f
Peter Eisentraut writes:
> On 12/12/2018 16:57, Tom Lane wrote:
>> * Probably this conflicts to some extent with Peter's "Reorganize
>> collation lookup" patch, but I haven't studied that yet.
> I've looked it over, and it's nothing that can't be easily fixed up. In
> fact, it simplifies a few t
On 12/13/18 2:02 PM, Peter Eisentraut wrote:
> On 12/12/2018 05:09, David Steele wrote:
>> I think the patch stands on its own. Exclusive backup mode is broken
>> and is know to cause problems in the field.
>
> Is this breakage documented anywhere for users?
Yes:
https://www.postgresql.org/docs
Hi,
On 2018-12-13 12:35:15 -0500, Tom Lane wrote:
> I happened to notice today that the initializer macro for dlist_head
> variables is
>
> #define DLIST_STATIC_INIT(name) {{&(name).head, &(name).head}}
>
> However, all the functions that work with dlists are prepared to handle
> a dlist_head that
On 12/12/2018 05:09, David Steele wrote:
> I think the patch stands on its own. Exclusive backup mode is broken
> and is know to cause problems in the field.
Is this breakage documented anywhere for users?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On 11/12/2018 23:24, David Steele wrote:
> @@ -845,7 +838,7 @@ test ! -f /mnt/server/archivedir/000100A90065
> && cp pg_wal/0
> rights to run pg_start_backup (superuser, or a user who has been granted
> EXECUTE on the function) and issue the command:
>
> -SELECT pg_start_
On 12/12/2018 05:31, Robert Haas wrote:
> Most of the features I've been involved in removing have been
> deprecated for 5+ years. The first release where this one was
> deprecated was only 2 years ago. So it feels dramatically faster to
> me than what I think we have typically done.
I was just
On 12/13/18 11:53 AM, David Steele wrote:
> Hackers,
>
> The alphabetical ordering of pgarch_readyXlog() means that on promotion
> 000100010001.partial will be archived before 0002.history.
>
> This appears harmless, but the .history files are what other potential
> primaries use
On 13/12/2018 12:07, Kyotaro HORIGUCHI wrote:
> - v6-0002-Add-psql-g-option-to-control-debug-print.patch
>
> Applies on top of 0001. Code is always active, -g addition to
> -L activates debug print into the log file. If only -g is
> specified it is forcibly turned off.
>
> > $ psql postgr
On 2018-Dec-13, Michael Paquier wrote:
> > I support 0001 other than those two points.
>
> Attached is an updated version for that as 0001. Thanks for the
> review. Does that part look good to you now?
+1.
> > +SELECT * FROM pg_identify_object_as_address('pg_proc'::regclass, 0, 0); --
> > no
On 12/13/18 8:35 AM, David Steele wrote:
> On 12/12/18 7:17 PM, Michael Paquier wrote:
>> On Wed, Dec 12, 2018 at 07:54:05AM -0500, David Steele wrote:
>
>>> But, we could at least use the . notation and end up with something like
>>> 000100010001.0002.partial or perhaps
>>> 00
I happened to notice today that the initializer macro for dlist_head
variables is
#define DLIST_STATIC_INIT(name) {{&(name).head, &(name).head}}
However, all the functions that work with dlists are prepared to handle
a dlist_head that starts out as zeroes, so that this could also be
#define DLIS
Hi!
> 13 дек. 2018 г., в 17:03, Alexander Korotkov
> написал(а):
>
> Thank you. I've revised your patch and pushed it. As long as two
> other patches in this thread.
That's great! Thanks!
> 13 дек. 2018 г., в 20:12, chjis...@163.com написал(а):
>
>
> hi
> I Have a question. Why the order
Hackers,
The alphabetical ordering of pgarch_readyXlog() means that on promotion
000100010001.partial will be archived before 0002.history.
This appears harmless, but the .history files are what other potential
primaries use to decide what timeline they should pick. The additiona
Bruce Momjian writes:
> I am seeing this warning in the 9.4 branch:
> ginxlog.c:756:5: warning: ‘lbuffer’ may be used uninitialized
> in this function [-Wmaybe-uninitialized]
I'm also getting that, just in 9.4, but at a different line number:
ginxlog.c: In function 'ginRedoDeletePage
On Thu, Dec 13, 2018 at 03:03:54PM +0300, Alexander Korotkov wrote:
> On Wed, Dec 12, 2018 at 4:08 PM Andrey Borodin wrote:
> > > 12 дек. 2018 г., в 3:26, Alexander Korotkov
> > > написал(а):
> > >
> > > BTW, I still can't see you're setting deleteXid field of
> > > ginxlogDeletePage struct anyw
hiI Have a question. Why the order of unlocking is not adjusted in this patch? like this:if (BufferIsValid(lbuffer))UnlockReleaseBuffer(lbuffer);if (BufferIsValid(pbuffer))UnlockReleaseBuffer(pbuffer);if (BufferIsValid(dbuffer))UnlockReleaseBuffer(dbuffer);==>if (BufferIsValid(pbuffer))UnlockReleas
Chapman Flack writes:
> On 12/13/18 04:41, Simon Riggs wrote:
>> [ we should allow this: ]
>> SELECT 'infinity'::interval;
>> ERROR: invalid input syntax for type interval: "infinity"
> ... and if that is made to work, perhaps then arithmetic should be
> updated as well,
That wouldn't be option
Andrew Dunstan writes:
> But the block inside parentheses feels kinda funny, doesn't it?
+1. I think this is a good concept, but let's put in enough effort to
not require weird syntax.
regards, tom lane
On 12/12/2018 18:56, Andres Freund wrote:
>> This makes the collation lookup more similar to the function lookup. In
>> many cases they now happen right next to each other.
>> pg_newlocale_from_collation() becomes analogous to fmgr_info() and
>> pg_locale_t to FmgrInfo *.
> Why isn't this integrat
On 12/13/18 04:41, Simon Riggs wrote:
> SELECT 'infinity'::timestamp;
> works
>
> SELECT 'infinity'::interval;
> ERROR: invalid input syntax for type interval: "infinity"
... and if that is made to work, perhaps then arithmetic should be
updated as well, with this producing an infinite interval
On 12/13/18 7:26 AM, Kyotaro HORIGUCHI wrote:
> At Thu, 13 Dec 2018 11:33:39 +0100, Peter Eisentraut
> wrote in
>
>>
>> I've played with a way to express this more compactly:
>>
>> PG_TRY();
>> {
>> ... code that might throw ereport(ERROR) ...
>> }
>> PG_FINALLY({
>>
On 12/12/18 7:17 PM, Michael Paquier wrote:
> On Wed, Dec 12, 2018 at 07:54:05AM -0500, David Steele wrote:
>> But, we could at least use the . notation and end up with something like
>> 000100010001.0002.partial or perhaps
>> 000100010001.T0002.partial? Maybe
>> 0
On 12/13/18 5:33 AM, Peter Eisentraut wrote:
> This is a common pattern:
>
> PG_TRY();
> {
> ... code that might throw ereport(ERROR) ...
> }
> PG_CATCH();
> {
> cleanup();
> PG_RE_THROW();
> }
> PG_END_TRY();
> cleanup(); /* the same as ab
On 12/13/18 7:43 AM, Pablo Iranzo Gómez wrote:
haproxy is what is used behind, the idea is that haproxy by default when
enabled via a 'route' does allow http or https protocol ONLY, BUT
(https://docs.openshift.com/container-platform/3.9/architecture/networking/routes.html),
routers do support
At Thu, 13 Dec 2018 11:33:39 +0100, Peter Eisentraut
wrote in
> This is a common pattern:
>
> PG_TRY();
> {
> ... code that might throw ereport(ERROR) ...
> }
> PG_CATCH();
> {
> cleanup();
> PG_RE_THROW();
> }
> PG_END_TRY();
> cleanup()
On Wed, Dec 12, 2018 at 4:08 PM Andrey Borodin wrote:
> > 12 дек. 2018 г., в 3:26, Alexander Korotkov
> > написал(а):
> >
> > BTW, I still can't see you're setting deleteXid field of
> > ginxlogDeletePage struct anywhere.
> Oops. Fixed.
> >
> > Also, I note that protection against re-usage of re
Hello.
At Wed, 28 Nov 2018 17:28:39 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20181128.172839.242071562.horiguchi.kyot...@lab.ntt.co.jp>
> I'm not sure how much it is wanted but it's easy to do. Using
> psql variable doesn't seem to make sense since the debug print
> (currently)
Hello
> Do we no longer need static version of conninfo/slotname in
> walreceiver.c? We can detect a change of the variables without
> them (as you did in the previous version.).
Depends on this discussion:
https://www.postgresql.org/message-id/20181212053042.gk17...@paquier.xyz
If walreceiver w
This is a common pattern:
PG_TRY();
{
... code that might throw ereport(ERROR) ...
}
PG_CATCH();
{
cleanup();
PG_RE_THROW();
}
PG_END_TRY();
cleanup(); /* the same as above */
I've played with a way to express this more compactly:
PG_T
At Tue, 11 Dec 2018 13:16:23 +0300, Sergei Kornilov wrote in
<9653601544523...@iva8-37fc2ad204cd.qloud-c.yandex.net>
sk> oops, forgot attach patch
sk>
sk> 11.12.2018, 13:14, "Sergei Kornilov" :
sk> > Hello
sk> >
sk> > After some thinking i can rewrite this patch in another way.
sk> >
sk> > This
At present we have a timestamp of 'infinity' and infinite ranges, but no
infinite interval
SELECT 'infinity'::timestamp;
works
SELECT 'infinity'::interval;
ERROR: invalid input syntax for type interval: "infinity"
Seems a strange anomaly that we should fix.
--
Simon Riggshttp:
Currently, tables provide MVCC access semantics as the only option.
A more complete list of desirable semantics in applications are
* MVCC - provide latest consistent view
* Historical - keep all old row versions so that queries can access data as
it used to be
* TTL=Duration - keep committed row
88 matches
Mail list logo
