lly. But I'll let you argue the case
for using pd_pagesize_version for that with your esteemed colleagues.
It would be pretty safe to just let it wrap.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mail
On Tue, Mar 6, 2012 at 5:56 PM, Bruce Momjian wrote:
> On Mon, Mar 05, 2012 at 03:03:18PM +0000, Simon Riggs wrote:
>> To avoid any confusion as to where this proposed feature is now, I'd
>> like to summarise my understanding, make proposals and also request
>&
On Mon, Mar 5, 2012 at 8:35 PM, Simon Riggs wrote:
>>> * Why do we need multixact to be persistent? Do we need every page of
>>> multixact to be persistent, or just particular pages in certain
>>> circumstances?
>>
>> Any page that contains at least one m
stored in the table; the minimum of all such values is stored in a pg_database
> column. VACUUM computes the minimum across all pg_database values, and
> removes pg_multixact segments older than the minimum.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Developm
ATE should be called
> something else - essentially NONKEY UPDATE, though I don't much like
> that name.
No, because that would stop it from doing what it is designed to do.
The lock modes are correct, appropriate and IMHO have meaningful
names. No redesign required here.
Not sure
There is much wisdom there and much wisdom in leaving ancient warnings
as we find them.
Are these the words you object to?
"we don't need to
> * check commit time against the start time of this transaction
> * because 2ph locking protects us from doing the wrong thing.&
tored procedures". Maybe we
want that, but its a completely separate thing. Please lets not get
distracted from a very simple thing because of the existence of other
requirements.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
the bottleneck
that is slowing such workloads.
So +1 to Heikki keeping the spinlock, as is, and not redesign anything.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-h
useful way to help with this patch right now is to run
performance investigations and see if there are non-optimal cases. We
can then see how the patch handles those. Theory is good, but it needs
to drive experimentation, as I myself re-discover continually.
--
Simon Riggs
won't take any
> locks.
Please explain in detail your idea of how it will work.
--
Simon Riggs 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 Wed, Mar 7, 2012 at 11:45 AM, Fujii Masao wrote:
> Attached patch extends pg_stat_statements so that it reports the
> planning time. Thought?
If we successfully aggregate SQL in the current patch then this might
be useful as well. Until we do that it's not much use.
--
mechanisms
using broad brush descriptions. It is possible you may find an
improvement and if you do, people will be interested but that seems an
unlikely thing to happen here and now.
If you have specific comments or tests on this patch those are very welcome.
--
Simon Riggs
ance.
I agree the effect you point out can exist, I just don't want to slow
down the main case as a result.
--
Simon Riggs 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 Wed, Mar 7, 2012 at 2:59 PM, Robert Haas wrote:
> All true.
So gentlemen, do we think this is worth pursuing further for this release?
I'm sure usual arguments apply all round, so I'll skip that part.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQ
On Wed, Mar 7, 2012 at 4:09 PM, Kevin Grittner
wrote:
> What part of it do you find to be accurate or helpful?
I think its funny and scary, as well as being of historical interest.
But please suggest a new wording so we can discuss it.
--
Simon Riggs http://
On Wed, Mar 7, 2012 at 5:39 PM, Robert Haas wrote:
> On Wed, Mar 7, 2012 at 10:26 AM, Simon Riggs wrote:
>> On Wed, Mar 7, 2012 at 2:59 PM, Robert Haas wrote:
>>> All true.
>>
>> So gentlemen, do we think this is worth pursuing further for this release?
>>
&
On Wed, Mar 7, 2012 at 5:28 PM, Robert Haas wrote:
> On Tue, Mar 6, 2012 at 2:27 PM, Bruce Momjian wrote:
>> The feature is no where near complete, and we should not be designing
>> features at this stage.
>
> I agree, on both counts. Although Simon did a good job pulling
On Wed, Mar 7, 2012 at 7:55 PM, Merlin Moncure wrote:
> On Wed, Mar 7, 2012 at 2:15 AM, Simon Riggs wrote:
>> We talked about this at last year's Dev meeting. And we got
>> sidetracked into "what we really want is stored procedures". Maybe we
>> want that,
On Wed, Mar 7, 2012 at 8:21 PM, Robert Haas wrote:
> On Wed, Mar 7, 2012 at 2:06 PM, Simon Riggs wrote:
>>> I am not thrilled with the design as it stands, but bulk loading is a
>>> known and serious pain point for us, so it would be awfully nice to
>>> improv
On Fri, Mar 9, 2012 at 3:46 AM, Robert Haas wrote:
> On Wed, Mar 7, 2012 at 5:41 PM, Simon Riggs wrote:
>>> Case #2 is certainly a problem for FrozenXID as well, because anything
>>> that's marked with FrozenXID is going to look visible to everybody,
>>> in
On Thu, Mar 8, 2012 at 1:20 PM, Robert Haas wrote:
> Are we still considering trying to do this for 9.2? Seems it's been
> over a month without a new patch, and it's not entirely clear that we
> know what the design should be.
It's important, but not
time as postmaster, without any pain.
It's a considerable convenience to be able to design this aspect once
and then have all things linked to the postmaster follow that. It
means people will be able to write code that runs on all OS easily,
without everybody having similar but sli
n on
the display, so we know whether a patch needs one assigned.
--
Simon Riggs 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 Sat, Mar 10, 2012 at 2:55 PM, Robert Haas wrote:
> On Sat, Mar 10, 2012 at 9:04 AM, Simon Riggs wrote:
>> * FOR KEY SHARE locks looks in very good shape and so I'm spending
>> time on that with a view to committing it next week if all goes well
>
> Álvaro is a
On Sat, Mar 10, 2012 at 3:47 PM, Tom Lane wrote:
> Simon Riggs writes:
>> * pg_stat_statements looks good also, I hope someone is looking at that
>
> I will take that one, if it ever gets marked RFC, but in the meantime
> I plan to spend my time elsewhere.
>
>> At
e want
to have programs that are intimately connected to the database, so
that nobody needs to change the operational instructions when they
start or stop the database.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
S
roblems, not least the normal test that xmax matches xmin across an
update.
--
Simon Riggs 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
what you think the worst cases would be, so
those can be tested? That would avoid wasting time or getting anything
backwards.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailin
On Tue, Mar 13, 2012 at 2:50 AM, Tom Lane wrote:
> Info appreciated.
Email seen, will reply when I can later today.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-
Am I correct or the number is execessive?
Meta page access was optimised away some time ago.
Descending the index tree can easily take that long, perhaps longer
when the table is larger and the tree is deeper.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development,
MMITTED is much help, because committed !=
> all-visible.
So because committed does not equal all visible there will be
additional lookups on mxids? That's complete rubbish.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
in points for new
> users.
This comment is completely superfluous. It's a complete waste of time
to turn up on a thread and remind people that if they commit something
and it doesn't actually work that it would be a bad thing. Why, we
might ask do you think that thought needs to be ex
complicated performance patch, and we can't predict the
> impact of it on real-world scenarios without testing. There is
> clearly some additional overhead, and it makes sense to measure it and
> hopefully discover that it isn't excessive. Still, I'm a bit
> relieved.
Ver
On Thu, Mar 15, 2012 at 1:17 AM, Alvaro Herrera
wrote:
> As things stand today
Can I confirm where we are now? Is there another version of the patch
coming out soon?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & S
On Thu, Mar 15, 2012 at 9:54 PM, Alvaro Herrera
wrote:
>
> Excerpts from Simon Riggs's message of jue mar 15 18:38:53 -0300 2012:
>> On Thu, Mar 15, 2012 at 2:26 AM, Robert Haas wrote:
>
>> > But that would only make sense if
>> > we thought that getting ri
f data? Is it worth
considering using this for the libpq copy protocol and therefore
streaming replication also?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Thu, Mar 15, 2012 at 10:13 PM, Alvaro Herrera
wrote:
>
> Excerpts from Simon Riggs's message of jue mar 15 19:04:41 -0300 2012:
>>
>> On Thu, Mar 15, 2012 at 9:54 PM, Alvaro Herrera
>> wrote:
>> >
>> > Excerpts from Simon Riggs's message of
ct/(Max - Min) for
integer types. That is useful because integers are commonly used as
keys and so some special attention there is not unwarranted.
Other ideas welcome.
--
Simon Riggs 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 Fri, Mar 16, 2012 at 9:39 PM, Jeff Davis wrote:
> On Fri, 2012-03-16 at 18:25 +0000, Simon Riggs wrote:
>> Any time we apply a LIMIT clause to a plan with a SeqScan or
>> unqualified IndexScan, we shouldn't assume the scan will do less than
>> say 10% of the table. I
On Fri, Mar 16, 2012 at 9:11 PM, Tom Lane wrote:
> Simon Riggs writes:
>> 2. We assume that if values do exist that they have rows uniformly
>> distributed across the whole table like rungs on a ladder.
>
> Well, yeah. That's sometimes wrong, but not always. In th
On Sat, Mar 17, 2012 at 11:33 AM, Greg Stark wrote:
> On Sat, Mar 17, 2012 at 9:34 AM, Simon Riggs wrote:
>> My wish was to register this as both a common and significant bug,
>
> It has definitely come up here before many times.
>
> However at root the problem is part of
x27;t kill it for the common case.
But would the idea deliver much value? Is line pointer bloat a
problem? (I have no idea if it is/is not)
--
Simon Riggs 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
y if you wanted to tackle that yourself.
--
Simon Riggs 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
d_current_snapshot() - OK
Standby pg_controldata - OK txid_current_snapshot() - lower value
Are there just 2 standbys? So all standbys have acted identically?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
pdates.
The main thing we're waiting on are the performance tests to confirm
the lack of regression.
You are working on that, right?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailin
indicating the accuracy
of the answer, as well as the answer itself.
That way we could respond better in a wide range of circumstances.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hacke
review a
patch. That way sponsors are forced to spend money on review time for
stuff they may not care about as a trade for getting reviews on stuff
they do. This would take pressure off the few.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
y. That would be April 6, 2012, ten days from today.
>
> Anybody, anybody? Can we try to get some agreement on this?
I agree.
I have a few projects still on the table myself, but my main concern
is Alvaro's FK locks patch. Depending on how the bones lie I will
finish up some com
On Wed, Mar 28, 2012 at 9:48 PM, Marko Kreen wrote:
> On Fri, Mar 23, 2012 at 08:52:40AM +0000, Simon Riggs wrote:
>> Master pg_controldata - OK txid_current_snapshot() - OK
>> Standby pg_controldata - OK txid_current_snapshot() - lower value
>
> On Skytools list is rep
On Wed, Mar 28, 2012 at 10:24 PM, Simon Riggs wrote:
> On Wed, Mar 28, 2012 at 9:48 PM, Marko Kreen wrote:
>> On Fri, Mar 23, 2012 at 08:52:40AM +0000, Simon Riggs wrote:
>>> Master pg_controldata - OK txid_current_snapshot() - OK
>>> Standby pg_controldata - OK txid
On Wed, Mar 28, 2012 at 10:54 PM, Simon Riggs wrote:
> On Wed, Mar 28, 2012 at 10:24 PM, Simon Riggs wrote:
>> On Wed, Mar 28, 2012 at 9:48 PM, Marko Kreen wrote:
>>> On Fri, Mar 23, 2012 at 08:52:40AM +, Simon Riggs wrote:
>>>> Master pg_controldata - O
On Thu, Mar 29, 2012 at 11:12 AM, Marko Kreen wrote:
> On Thu, Mar 29, 2012 at 10:37:54AM +0100, Simon Riggs wrote:
>> When the standby receives the checkpoint record, it stores the
>> information in 2 places:
>> i) directly into ControlFile->checkPointCopy
>> ii
On Thu, Mar 29, 2012 at 12:06 PM, Simon Riggs wrote:
> Patch coming in a few hours.
This is more straightforward than I was thinking. We just need to
initialise XLogCtl at the right place.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Supp
On Thu, Mar 29, 2012 at 3:04 PM, Marko Kreen wrote:
> On Thu, Mar 29, 2012 at 02:46:23PM +0100, Simon Riggs wrote:
>> On Thu, Mar 29, 2012 at 12:06 PM, Simon Riggs wrote:
>> > Patch coming in a few hours.
>>
>> This is more straightforward than I was thinking.
ld
show up as a wait for a content lock. That might happen to updates
where checkpoint write occurs between the search and write portions of
the update.
The next logical step in measuring lock waits is to track the reason
for the lock wait, not just the lock wait itself.
--
Simon Riggs
waiting for a clog page to be read?
So what we should be logging is the list of lwlocks held when the lock
wait occurred.
That would differentiate call paths somewhat better than just looking
at the current lock request.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL D
they are rare,
the semantics work against us.
We should either implement 1) non-queue jump semantics for certain
cases 2) put a limit on the number of queue jumps that can occur
before we let the next x lock proceed instead. (2) sounds better, but
keeping track might well cause greater overhead
On Sun, Apr 1, 2012 at 1:34 PM, Robert Haas wrote:
> On Sun, Apr 1, 2012 at 7:07 AM, Simon Riggs wrote:
>> First, we need to determine that it is the clog where this is happening.
>
> I can confirm that based on the LWLockIds. There were 32 of them
> beginning at lock id 81,
On Sun, Apr 1, 2012 at 11:12 PM, Greg Stark wrote:
> On Sun, Apr 1, 2012 at 10:27 PM, Simon Riggs wrote:
>> So lock starvation on the control lock would cause a long wait after
>> each I/O, making it look like an I/O problem.
>
> Except that both of the locks involved in
? Is there work
> already being done on this?
>
> Being able to regularly execute a postgres function every so often
> would be really nice. It would simplify lots of deployments.
I'm working on this. Glad to hear someone else wants this also.
--
Simon Riggs
ds of times.
That's a valid concern but I don't think the instrumentation would
show that as a single long wait because the locks would be released
and be retaken each time around the loop - I guess that's for Robert
to explain how it would show up.
If it doesn't show it, th
On Mon, Apr 2, 2012 at 8:36 AM, Simon Riggs wrote:
> On Mon, Apr 2, 2012 at 1:17 AM, Joe Van Dyk wrote:
>
>> Anyone else want event scheduling / cron / temporal triggers in
>> postgresql? http://dev.mysql.com/doc/refman/5.1/en/events-overview.html
>> shows how it work
On Mon, Apr 2, 2012 at 11:49 AM, Greg Stark wrote:
> On Mon, Apr 2, 2012 at 8:15 AM, Simon Riggs wrote:
>> Not true, please refer to code at line 544, as I already indicated.
>>
>> My understanding of the instrumentation is that the lock acquired at
>> line 526 will s
irty. That way we don't need to write or
fsync at all and the bgwriter can pick up the pieces. So my earlier
patch to get the bgwriter to clean the clog would be superfluous.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Serv
s idea of background-writing
> SLRU pages.
Agreed. No longer anywhere near as important. I'll take a little
credit for identifying the right bottleneck, since you weren't a
believer before.
--
Simon Riggs 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
saction rate.
>
> What this statement means to me is that the number of slru buffers
> should be configurable, not compile-time fixed.
I think the compile time fixed allows it to be loop unrolled and
executed in parallel.
Using a parameter makes the lookups slower. Worth testing. Life
> 1
million transactions old? Do you believe those numbers? Looks weird.
Perhaps we should retest the clog history patch?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsq
#x27;t rely on pgbench as a general
workload, nor should we solely tune Postgres for throughput without
regard to response time. But that point is not relevant to this
specific issue.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &a
at the system *quickly*
switches around so that *all* backends choose to wait behind that same
I/O, which is mad.
There is no doubt that your I/Os are slow here and that the specific
test accentuates that, but neither of those things are rare.
If it was an optimiser bug that made something ru
m not that fussed about throughput because it just hides the
detail. I am concerned about the distribution of response times, so
I'd like to see the numbers about that if you don't mind. i.e. does
the patch remove long waits.
--
Simon Riggs http://www.2ndQuadrant.com/
Pos
These patches aren't marked with a committer
FK arrays
ECPG fetch
foreign stats
command triggers
check function
parallel pg_dump
Does that mean myself or others should be claiming them for commit/reject?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Develo
On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas wrote:
> On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs wrote:
>> These patches aren't marked with a committer
>>
>> FK arrays
>> ECPG fetch
>> foreign stats
>> command triggers
>> check function
>>
> such bugs in later versions because of backwards compatibility worries.
> It'd be a lot better to be pushing this in at the start of a devel cycle
> than the end.
OK, that's clear. I would have taken it, but not now.
--
Simon Riggs http://www.2ndQuadrant.com/
done what I can to alter that, but I think its the right decision
at this point. I would say its been the largest and most subtle patch
submitted, so please don't be down by that.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &a
reasons, cos such excuses aren't good enough,
whoever they come from.
--
Simon Riggs 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
or we could just leave it.
Do nothing is easy, though so are the others, so we can choose
anything we want. What do we want it to say?
--
Simon Riggs 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
that is why it is
being read incorrectly.
I see that the comment in InitXLOGAccess() is incorrect
"ThisTimeLineID doesn't change so we need no lock to copy it", which
seems worth correcting since there's no need to save time in a once
only function.
Continuing to investigate
he patch attached? It avoids the update of
>> recoveryTargetTLI and recoveryTargetIsLatest if the node has been shutdown
>> while in recovery.
>> Another possibility could be to add in the assertion some conditions based
>> on the state of controlFile but I think it is more co
On 20 May 2013 18:47, Heikki Linnakangas wrote:
> On 19.05.2013 17:25, Simon Riggs wrote:
>> So while I believe that the checkpointer might have an incorrect TLI
>> and that you've seen a bug, what isn't clear is that the checkpointer
>> is the only process that
the
user interpret the log message correctly.
I suggest we use RequestCheckpoint(CHECKPOINT_CAUSE_TIME) instead,
since it is literally time for a checkpoint.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent
On 20 May 2013 20:40, Heikki Linnakangas wrote:
> On 20.05.2013 22:18, Simon Riggs wrote:
>>
>> On 20 May 2013 18:47, Heikki Linnakangas wrote:
>>>
>>> Not sure what the best fix would be. Perhaps change the code in
>>>
>>> Cre
On 21 May 2013 07:46, Heikki Linnakangas wrote:
> On 21.05.2013 00:00, Simon Riggs wrote:
>>
>> When we set the new timeline we should be updating all values that
>> might be used elsewhere. If we do that, then no matter when or how we
>> run GetXLogReplayRecPtr, it can
using that flag.
This would mean we can't use the secondary checkpoint record, but we
already gave that up so should be OK.
Three people, three suggestions; so I will agree to this suggestion so
we can get on with it.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQ
On 21 May 2013 09:26, Simon Riggs wrote:
> I'm OK with that principle...
Well, after fighting some more with that, I've gone with the, er,
principle of slightly less ugliness.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Supp
t high, or at least won't be by end 2014
and will be annoying sometime before 2020.
Solution seems to be to support something potentially bigger than INT
for GUCs. So we can reclassify GUC_UNIT_MEMORY according to the
platform we're on.
Opinions?
--
Simon Riggs http:/
CF, for now, but I'll also take
responsibility for this for 9.4, barring objections.
--
Simon Riggs 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
ing copyright with the
PGDG.
As a result, while it sounds interesting, people should be aware of
that and I suggest we shouldn't discuss that code on this list, to
avoid any disputes should we decide to include a similar facility in
core Postgres in the future.
--
Simon Riggs
e needs of multiple areas at once, so we come up with
a more useful design that covers more than just one use case, please?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-h
On 24 May 2013 18:40, Andres Freund wrote:
> That pattern looks dangerous. Setting the lsn of the heap page will
> prevent the next action from doing a FPI even if it would be required.
Can you be more specific about the danger you see?
--
Simon Riggs http
On 24 May 2013 20:26, Andres Freund wrote:
> On 2013-05-24 19:09:57 +0100, Simon Riggs wrote:
>> On 24 May 2013 18:40, Andres Freund wrote:
>>
>> > That pattern looks dangerous. Setting the lsn of the heap page will
>> > prevent the next action from doing a
still in beta. Why? Because once we begin using the topXid as the
filename we can't then change later to using the vxid.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgs
together into one
release.
By doing this now we give ourselves lots of time to plan changes that
will see us good for another decade. If we don't do this, then we
simply risk losing the iniative by continuing to support legacy
formats and approaches.
--
Simon Riggs
we manage to merge the WAL actions for
most of the time.
Some other related thoughts:
ISTM that if we really care about keeping xids for debug purposes that
it could be a parameter. For the mainline, we just freeze blocks at
the same time we do page pruning.
I think the right way is actually to
On 25 May 2013 18:13, Jeff Davis wrote:
> On Sat, 2013-05-25 at 10:39 +0100, Simon Riggs wrote:
>> The constraint on such changes is that we've decided that we must have
>> an upgrade path from release to release.
>
> Is this proposal only relaxing the binary upgrade
n for that suggestion is that nobody ever
reported this bug, so either few people use binary mode or they use
the old syntax. Of course, that is not a normal suggestion, so feel
free to walk up and down my spine with boots on for suggesting it.
Thoughts?
--
Simon Riggs http://www
On 25 May 2013 21:44, Bruce Momjian wrote:
> On Sat, May 25, 2013 at 10:39:30AM +0100, Simon Riggs wrote:
>> There are a number of changes we'd probably like to make to the way
>> things work in Postgres. This thread is not about discussing what
>> those are, just to s
{
> + $$ = makeDefElem($1, (Node *)
> makeString("binary"));
> + }
So, no that doesn't work.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
o many people are
bothered, since no complaints in 3 years. Documenting 'binary' seems
better.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
say we're
> going to have such a release and then look for reasons.
Agreed.
I was trying to establish a realistic timeline for such events, so
that the planning was able to be taken seriously. Yes, it wass a "work
backwards" or "what if" type of planning. But n
ead of the list being a 2 byte
addition to the block header. Which could be used to reduce the
overhead of multixactid use.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hac
901 - 1000 of 8523 matches
Mail list logo
