t's five
extra years matter anyway? Hey, while we're at it, lets change Pg to
build on Borland C and require K&R style!
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list
On 17 November 2016 at 10:42, Craig Ringer wrote:
> But sure, if it's easier, we can have 5.8.0 in the README. What's five
> extra years matter anyway? Hey, while we're at it, lets change Pg to
> build on Borland C and require K&R style!
Sorry. That was unnecessary.
On 17 November 2016 at 12:23, Michael Paquier wrote:
> On Wed, Nov 16, 2016 at 6:54 PM, Craig Ringer wrote:
>> In all seriousness, though, lets query the buildfarm database for Perl
>> versions. Let it answer.
>
> castoroides, Solaris 10 and perl 5.8.4, no?
> https://ww
On 18 November 2016 at 05:41, Robert Haas wrote:
> On Wed, Nov 16, 2016 at 9:54 PM, Craig Ringer wrote:
>> On 17 November 2016 at 10:42, Craig Ringer wrote:
>>> But sure, if it's easier, we can have 5.8.0 in the README. What's five
>>> extra years matter
On 18 November 2016 at 07:10, Michael Paquier wrote:
> On Thu, Nov 17, 2016 at 2:39 PM, Craig Ringer wrote:
>> I wasted a bunch of time getting set up to test for such an ancient
>> Perl and would love to save the next person along the hassle by
>> documenting the easy way.
it'd be better to make it safe to handle all the
conflict cases within the walsender.
Anyway, this PoC passes regression tests and allows drop database on a
standby to succeed when a slot is in-use. Not for commit as-is.
--
Craig Ringer http://www.2ndQuadrant.com/
Postgre
ver tells us on connect whether it's a standby or not, use that.
Otherwise, ask it.
That way we don't pay the round-trip cost and get the log spam when
talking to newer servers that send us something useful in the startup
packet, but we can still query it on older servers. Gr
t of an
oversight, and it'd definitely be good to address that to make async
mode more usable on Windows. There's some other ugliness in PQsocket
already per the comments there. I think it should be a separate patch,
though.
--
Craig Ringer http://www.2n
On 18 Nov. 2016 13:14, "Kyotaro HORIGUCHI"
wrote:
>
> Hello.
>
> We had too-early WAL recycling during a test we had on a sync
> replication set. This is not a bug and a bit extreme case but is
> contrary to expectation on synchronous replication.
Isn't this prevented by using a physical replicat
d.
>
> True, but raising the bar for this feature so that it doesn't get done
> is also bad. It can be improved in a later patch.
Good point. Starting with the followup query method seems fine.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Develop
On 18 November 2016 at 08:15, Craig Ringer wrote:
> On 18 November 2016 at 07:10, Michael Paquier
> wrote:
>> On Thu, Nov 17, 2016 at 2:39 PM, Craig Ringer wrote:
>>> I wasted a bunch of time getting set up to test for such an ancient
>>> Perl and would love to
On 19 November 2016 at 10:04, Euler Taveira wrote:
> On 01-09-2016 01:41, Craig Ringer wrote:
>> Here's a rebased version of my pg_recvlogical --endpos patch from the
>> 9.5 series, updated to incoroprate Álvaro's changes.
>>
> I should review this patch in th
On 21 November 2016 at 12:23, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Mon, 21 Nov 2016 11:58:34 +0800, Craig Ringer
> wrote in
>> On 18 November 2016 at 08:15, Craig Ringer wrote:
>> > On 18 November 2016 at 07:10, Michael Paquier
>> > wrote:
>>
> GROUP BY 1 ORDER BY 1;
>
> but result is sensitive on locales setting - doesn't work well with czech
> locales.
Simple fix here is to append COLLATE "C" after the ORDER BY.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 2
/CAMsr+YFi-LV7S8ehnwUiZnb=1h_14PwQ25d-vyUNq-f5S5r=z...@mail.gmail.com
* Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from
walsender?
[5]
https://www.postgresql.org/message-id/CAMsr+YFb3R-t5O0jPGvz9_nsAt2GwwZiLSnYu3=x6mr9rnr...@mail.gmail.com
Also relevant:
On 18 November 2016 at 10:57, Craig Ringer wrote:
> Hi all
>
> While adding support for logical decoding on standby I noticed that
> the walsender doesn't respect
> SIGUSR1 with PROCSIG_RECOVERY_CONFLICT_DATABASE set.
I have an update on this after further study.
Surprising
ed to be checked with:
* WinXP, non-admin
* WinXP, admin, should refuse to run
* WinVista / Win7, local admin, UAC on => should run
* WinVista / Win7, local admin, UAC off => should refuse to run
* WinVista / Win7, run cmd.exe using "run as admin" => should refuse to run
*
.
That also offers a handy step on the path toward table-valued
variables and pipelined functions, both of which would be _really_
nice for PL/PgSQL users.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent v
On 22 November 2016 at 11:35, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Mon, 21 Nov 2016 21:39:07 -0500, Robert Haas wrote
> in
>> On Mon, Nov 21, 2016 at 3:21 AM, Craig Ringer wrote:
>> > I'm still interested in hearing comments from experienced folks about
&
On 22 November 2016 at 10:20, Craig Ringer wrote:
> I'm currently looking at making detection of replay conflict with a
> slot work by separating the current catalog_xmin into two effective
> parts - the catalog_xmin currently needed by any known slots
> (ProcArray->replicati
On 22 November 2016 at 15:14, Haribabu Kommi wrote:
>
> On Fri, Nov 18, 2016 at 7:18 PM, Craig Ringer wrote:
>>
>> The latest is what's attached upthread and what's in the git repo also
>> referenced upthread.
>>
>> I haven't been able to updat
d consider any logical replication
downstream a 'master'.
That's fine for now IMO. Determining whether a server is a logical
replica isn't that simple, nor is it a clear-cut yes/no answer, and I
think it's out of the scope of this patch to deal with it. Figure it
out once l
On 22 Feb. 2017 14:14, "Vaishnavi Prabakaran"
wrote:
Thanks for reviewing the patch.
>
Thanks for picking it up! I've wanted to see this process for some time,
but just haven't had the bandwidth for it.
.
Bugfix, should be applied to 9.6 and master.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From ba803ba3c94624ce5e6044e14272b2db2793252c Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Fri, 24 Feb 2017 11:43:30 +0
talog_xmin).
It's only loosely related to this change, but may be relevant.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
manages to get hold of them
and re-use them via CREATE TABLE AS or something. But it seems
unlikely enough that I'm not too fussed if we don't explicitly reserve
them. Nobody is going to have a ref named ""
already, I'm not concerned about BC if we do this.
--
Craig
l clone or
re-cloning from upstream with a local repo as a --reference .
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
ubstituted range.
Still needs applying to pg9.6 and pg10.
From f96b78c19c09fda83b26b75cca500dd35c849002 Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Fri, 24 Feb 2017 11:43:30 +0800
Subject: [PATCH] Fix timeouts in PostgresNode::psql
Newer Perl or IPC::Run versions default to appending the f
t I saw the backport as having minimal chance of getting into core.
I've pushed what I did to
https://github.com/2ndQuadrant/postgres/tree/dev/backport-96-tap-to-95
in case anyone finds it useful.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development
On 9 February 2017 at 21:23, Stas Kelvich wrote:
>> On 2 Feb 2017, at 00:35, Craig Ringer wrote:
>>
>> Stas was concerned about what happens in logical decoding if we crash
>> between PREPSRE TRANSACTION and COMMIT PREPARED. But we'll always go back
>> and d
On 2 March 2017 at 03:19, Peter Eisentraut
wrote:
> On 2/26/17 21:28, Craig Ringer wrote:
>> Amended patch attached after a few Perl-related comments I got on
>> private mail. Instead of
>>
>> $exc_save !~ /^$timeout_exception.*/
>>
>> I've updated to:
be used for that.
Right.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
some points. Can we maybe setup
> skype call to discuss this and post summary here? Craig? Peter?
Let me prep an updated patch. Time zones make it rather hard to do
voice; I'm in +0800 Western Australia, Petr is in +0200...
--
Craig Ringer http://www.2ndQuadrant.com/
On 2 March 2017 at 16:00, Craig Ringer wrote:
> What about if we ROLLBACK PREPARED after
> we made the snapshot visible?
Yeah, I'm pretty sure that's going to be a problem actually.
You're telling the snapshot builder that an xact committed at PREPARE
TRANSACTION time.
On 2 March 2017 at 16:20, Stas Kelvich wrote:
>
>> On 2 Mar 2017, at 11:00, Craig Ringer wrote:
>>
>> We already have it, because we just decoded the PREPARE TRANSACTION.
>> I'm preparing a patch revision to demonstrate this.
>
> Yes, we already have it
or both, as much
> as that is possible.
If it shows a sawtooth pattern for flush lag, that's good, because
it's truthful. We can only flush after we replay commit, therefore lag
is always going to be sawtooth, with tooth size approximating xact
size and the baseline lag trend representi
a needed WAL segment we'll ERROR. So
this is safe, though the error will be something about being unable to
find a wal segment that users might not directly associate with having
set this option. It won't say "slot disabled because needed WAL has
been discarded due to [setting]" or
libpq patch goes in.
That's great, thanks, and thanks also for the fixes. Any chance you
can attach your updated patch?
I looked at modifying psql to support batching when run
non-interactively, but it would've required major restructuring of its
control loop and I ran out of time. I did
be picked up
implicitly.
Two further minor patches follow, one to fix a harmless but confusing
quirk in logical walsender init, and one that adds explanatory
comments to relevant parts of the code (and a couple of spots in the
docs) to avoid future occurrences of the above issues.
--
On 9 March 2017 at 11:17, Craig Ringer wrote:
> Hi all
>
> I've found a minor off-by-one error in the resource retention logic
> for logical slots, where we treat confirmed_flush as meaning "flushed
> up to and including this LSN". Seems reasonable, but the r
ches oldestXid
from the rest for separate review, so I'll update here with a 2-patch
series instead of a squashed single patch soon.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers maili
cause no lock is held throughout all of vac_truncate_clog,
make sure the ordering of the different phases between concurrent
vac_truncate_xlog runs doesn't matter.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ally do
anything useful. The user could've set ridiculous thresholds/delays,
per-table overrides, etc.
So it's not much use for remote support/diagnostics, and might as well go away.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
art, letting users know how
> they can activate single-row mode while using batch processing.
> Let me know your thoughts.
Thanks for looking into this, it's clear that I didn't cover the combo
of single-row-mode and batch mode adequately.
--
Craig Ringer
On 11 March 2017 at 14:32, Craig Ringer wrote:
> I'll extract this part of the patch so it can be looked at separately,
> it'll be clearer that way.
Apparently I thought that last time too since I already posted it
split up. Ahem. Working on too many different things at on
On 13 March 2017 at 10:56, Craig Ringer wrote:
> On 7 March 2017 at 21:08, Simon Riggs wrote:
>
>> Patch 4 committed. Few others need rebase.
>
> Since this patch series and initial data copy for logical replication
> both add a facility for suppressing initial snapshot
split out. The first patch also help with
> Craig's logical decoding on standby so it definitely makes sense to be
> split.
Greatly appreciated.
Committing this in chunks makes sense anyway.
I've attached a slightly version that makes pg_recvlogical skip slot
export. The second
though.
I'm not convinced that a keyword change will do much good, the whole
thing really needs a reassessment to make sure that it's clearer to
users/admins and has fewer moving parts.
So I'm in favour of fixing the docs but I'm not keen on changing the
SQL syntax in a way th
ch will be held
from when we advance the new clogOldestXid field through to when clog
truncation completes.
Most of the rest can stay the same. In particular, the expanded xlog
record for clog truncation will still be required.
--
Craig Ringer http://www.2ndQuadrant.com/
Postgr
rding the gid on 2pc
commit and abort records in the master's WAL, where it's very cheap
and simple.
But I agree that just sending the xid is a viable option if that falls through.
I'm going to try to pick this patch up and amend its interface per our
discussion earlier, see if I can
y to mind such a
lock.
> * Try at first to scan catalog filtering out tuples with xmax bigger than
> snapshot->xmax
> as it was possibly deleted by our tx. Than if nothing found scan in a usual
> way.
I don't think that'll be at all viable with the syscache/relcache
mac
commit-time order.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
te_state
Varies. This can be a bit of a catchall error, encompassing things
that need configuration changes, things that need system state changes
(won't work in recover or whatever), and things that will change in a
short span of time.
In general you'll need classes of retry:
* just reissue
On 14 March 2017 at 19:57, Robert Haas wrote:
> On Mon, Mar 13, 2017 at 10:22 PM, Craig Ringer wrote:
>> I'll introduce a new LWLock, ClogTruncationLock, which will be held
>> from when we advance the new clogOldestXid field through to when clog
>> truncation complete
I still spend a while swearing at Perl, but I can't really imagine
doing nontrivial development without them anymore.
So ... thanks.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mai
ling of bulk loads or bulk updates
> leads to significant latency.
Yeah. If it weren't for that, I'd probably still just pursue locking.
But you're right that we'll have to solve this sooner or later. I'll
admit I hoped for later.
--
Craig Ringer htt
log record from a different xact. We'll probably have to
switch to linear decoding with reordering when someone makes catalog
changes.
TBH, I have no idea how to approach the genam changes for the proposed
double-scan method. It sounds like Stas has some idea how to proceed
though (right?)
--
(which has the same name as
XLogRead in src/backend/replication/walsender.c). I have a draft for a
timeline following readme that would address some of this but don't
expect to be able to finish it off for this release cycle, and I'd
really rather clean it up instead.
--
Craig
committing it.
I think it's mostly an interface issue though. I'd rather say
SnapBuildPushPrepareTransaction and SnapBuildPopPreparedTransaction or
something, to make it clear what we're doing.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 2
On 20 March 2017 at 20:57, Stas Kelvich wrote:
>
>> On 20 Mar 2017, at 15:17, Craig Ringer wrote:
>>
>>> I thought about having special field (or reusing one of the existing fields)
>>> in snapshot struct to force filtering xmax > snap->xmax or xmin = snap
On 20 Mar. 2017 22:10, "Tom Lane" wrote:
FWIW, the problem I've got with the TAP tests is that when one fails
in the buildfarm, you've got to dig through megabytes of all-alike-looking
output just to try to determine which one failed; and once you do, you
still know nothing because the script ou
ybe you can take it
> out, or even add --quiet or --QUIET (see the prove(1) manpage).
If so, please preserve the current behaviour via something like
$(or $(PROVE_VERBOSITY),'--quiet')
since it's very useful to have more output when running individual
tests interactively
ot
writing new logical WAL. This isn't a big deal, it just means we can't
short-circuit UpdateOldestCatalogXmin() calls if
!XLogLogicalInfoActive(). It also means the XLogReportParameters()
stuff can be removed since we don't care about wal_level for tracking
oldestCatalogXmin.
Fixe
be necessary to add a SQL function and/or walsender
command to send feedback on a slot we're not currently replaying
changes from, but I see that as independently valuable and have wanted
it for a number of things already. We'd still have to decode (so we
found the right restart_lsn), bu
xlogreader timeline following without full logical
decoding on standby being available.
>> From 8854d44e2227b9d076b0a25a9c8b9df9270b2433 Mon Sep 17 00:00:00 2001
>> From: Craig Ringer
>> Date: Mon, 5 Sep 2016 15:30:53 +0800
>> Subject: [PATCH 3/3] Logical decoding on sta
another level of security barrier subquery, because
otherwise the planner might execute the other quals (including possible
user defined functions) before the superuser test. Which was the whole
reason for the superuser test in the first place.
--
Craig Ringer http://www
eeing if we can just run as table owner.
Failing that, we could take the approach a certain other RDBMS does and
make the ability to define row security quals a GRANTable right
initially held only by the superuser.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL De
t, but not raise it above the system provided max. Just
like ulimit its self.
So SUSET seems OK to me. I don't think it should be PGC_BACKEND, not
least because I can see the utility of a superuser-owned SECURITY
DEFINER procedure applying system specific policy to who can set what li
s from system calls via LD_PRELOAD,
so PostgreSQL thinks that the user it is running as isn't root. It's
commonly used in testing and packaging systems.
http://man.he.net/man1/fakeroot
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
to sort that out?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 06/17/2014 02:02 AM, Shreesha wrote:
> But I believe, I am looking forward for the exact opposite of it. In
> other words, a possible work around for a root user to execute certain
> executable(s) as an unprivileged user.
>
So you want the su or sudo commands?
--
On 06/18/2014 12:41 AM, Robert Haas wrote:
> On Mon, Jun 16, 2014 at 12:58 AM, Craig Ringer wrote:
>> > On 05/30/2014 11:14 PM, Heikki Linnakangas wrote:
>>> >> Yeah. To recap, the failure mode is that if the master crashes and
>>> >> restarts, the tran
nitdb then 'sed' the config file afterwards" is not an answer)
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 06/18/2014 03:30 PM, Craig Ringer wrote:
> There is, IMO, a significant oversight with the include_dir feature.
>
> If a distributor wants to enable it by default at initdb time, they
> can't just turn it on in postgresql.conf.sample, because initdb will die
> when the post
se it here.
http://www.postgresql.org/message-id/53a10ef9.9060...@2ndquadrant.com
Hopefully it's just PEBKAC.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers
ents of CLOG when taking a snapshot,
> but that would defeat the whole purpose of CSN-based snapshots, which
> is to make the small and fixed-size.
Ah.
Thankyou. I appreciate the explanation.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
e name == user name. If anyone can give some input on the code,
> it would be helpful!
libpq
I think you probably need to move this to pgsql-general, Stack Overflow,
etc. It's not really on topic for pgsql-hackers.
--
Craig Ringer http://www.2ndQuadrant.com/
Postgre
m recovered
if they vanish would also be valuable, IMO.
Not necessarily in the same patch, I'd just rather keep it in mind so
any chosen design doesn't preclude adding that later.
- --
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/22/2014 01:35 PM, Craig Ringer wrote:
> A way to put UNLOGGED objects in such a space and have them
> recovered if they vanish would also be valuable, IMO.
By which I mean "re-created empty, as if after a crash".
- -
For n=1 this can be done
with a simple SQL level aggregate definition, so all it really needs is
to error on dims > 1 IMO.
* Add a built-in aggregate form of array_cat
... probably other things I'm forgetting.
Worth adding some to the TODO marked beginner?
--
Craig Ringer
> way to mix multiple policies there might not be a way to implement this.
I think that's a "later" myself, but we shouldn't design ourselves into
a corner where we can't support deny rules either.
--
Craig Ringer http://www.2ndQuadrant.com/
ndly) behaviour around lost tablespaces is replaced with
something like an `ignore_missing_tablespaces` or
`drop_missing_tablespaces` GUC - akin to our existing
`zero_missing_pages` recovery GUC.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24
there are other funcs that could use TimeZone-insensitive
variants too.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 07/02/2014 11:10 AM, Noah Misch wrote:
> On Tue, Jul 01, 2014 at 11:49:43AM +0800, Craig Ringer wrote:
>> Currently it's unsafe/not possible to use some funtions, like
>> date_trunc, in immutable functions and expression indexes.
>>
>> It'd be really use
od deal more common.
Yep - I see early notice of new gcc "special" behaviour, etc as quite
valuable.
If we're dubious about a result, we wait a few days and see if it goes
away on its own.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL De
caling
though I think just the "-h" flag would be useful here, meaning "wrap in
pg_size_pretty".
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Hi all
After someone reported somewhat less than informative errors in bytea
decoding (http://stackoverflow.com/q/24588866/398670) I thought I'd put
together a quick patch to improve the errors here.
Please merge.
--
Craig Ringer http://www.2ndQuadrant.com/
Postg
On 07/08/2014 07:44 AM, Robert Haas wrote:
> On Sun, Jul 6, 2014 at 4:17 AM, Craig Ringer wrote:
>> After someone reported somewhat less than informative errors in bytea
>> decoding (http://stackoverflow.com/q/24588866/398670) I thought I'd put
>> together a quick patch
ing side of row security and the corresponding challenges
with the semantics around RETURNING.
It's already a decent sized amount of work on top of the existing row
security patch.
If we start adding policy groups, etc, this will never get done.
--
Craig Ringer http://www
gged like that. For that matter,
> they really ought not complain about strings like "9.5devel" or
> "9.5alpha2" either.
Yeah, that's horrible. We should be using server_version_num .
It should be a quick enough fix, I'll take a look.
--
Craig Ringer
will give us trouble when we do try to fix
> that.
It's worth noting that pg_ident.conf uses SQL-like case-folding and
quoting, though I don't think it's documented.
We should certainly be using the same thing in pg_hba.conf IMO.
--
Craig Ringer http://www.2nd
y well be
> impossible to make it atomic *and* make it perform in the general
> case.
>
> So, +1 UPSERT.
I totally agree. Particularly because MERGE-like behaviour is already
possible with wCTEs and/or table locking. It's not beautiful, but
neither is MERGE.
- --
Craig Ringer
h questions about pg_hba.conf, connection issues on OS
X, etc.
I'd be very keen to see atomic upsert in Pg. Please Cc me on any patches
/ discussion, I'll be an eager tester.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Se
>
There's a lot of detail on how to do this in the BDR codebase, see
contrib/bdr in
http://git.postgresql.org/gitweb/?p=2ndquadrant_bdr.git;a=summary
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent
On 07/23/2014 09:46 AM, Craig Ringer wrote:
> There's a lot of detail on how to do this in the BDR codebase, see
> contrib/bdr in
> http://git.postgresql.org/gitweb/?p=2ndquadrant_bdr.git;a=summary
Oh, sorry: in the bdr-next branch. Should've mentioned.
http://git.postg
S crashes, the system loses
power, etc.
Exiting a program without calling cleanup is in many ways just a
particularly friendly kind of crash, and it's often actually much more
efficient than doing cleanup. Why neatly tidy the floor when you're
about to demolish the house? Tot
s relying on that always happening that's a problem. In your case
Oracle will clean up dead connections after a while, for example (or
quite promptly as the OS will rapidly TCP RST them). So it's just nicer.
Point taken though.
--
Craig Ringer http://www.2ndQuadrant.
hy having the server report it automatically
seems useful.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t-value flags, so we could
store and work with native integers for common values.
There's NumericShort and NumericLong, but no NumericNative or
NumericInt32 or whatever. OTOH, by the time you handle alignment and
padding requirements and the cost of deciding which numeric format the
On 08/08/2014 03:54 AM, Tom Lane wrote:
> Craig Ringer writes:
>> Hi all
>> To support transparent client-side failover in BDR, it's necessary to
>> know what the LSN of a node was at the time a transaction committed and
>> keep track of that in the client/proxy.
&
401 - 500 of 2076 matches
Mail list logo
