On Wed, May 02, 2012 at 12:20:39PM +0200, Albe Laurenz wrote:
> >>> 1) Expose WIDTH_THRESHOLD in commands/vacuum.h and add documentation
> >>>so that the authors of foreign data wrappers are aware of the
> >>>problem and can avoid it on their side.
> >>>This would be quite simple.
>
>
I've been trying to figure out why my recent attempt to latch-ify the
stats collector didn't work well on the Windows buildfarm machines.
After a good deal of staring at our code and Microsoft's documentation
I have a theory, which I intend to try out shortly. However, it appears
to me that this c
I think that pgbench should it make it easy to assess the impact of
foreign key constraints.
The attached adds a --foreign-keys option to initialization mode which
creates all the relevant constraints between the default tables.
I changed the order of the table DDLs so that upon reinitialization
On 13 May 2012 02:48, Tom Lane wrote:
> One possible answer is to just legislate that callers mustn't specify
> WL_SOCKET_WRITABLE without WL_SOCKET_READABLE (either just as
> documentation, or probably better with an Assert check). The existing
> callers would all be fine with this, and I'm not
Peter Geoghegan writes:
> I think that we might have avoided accepting the poll()-based
> implementation in the first place if these subtleties were considered
> earlier, since IIRC the justification for introducing it was rather
> weak.
I'm not exactly sure that the select-based implementation i
On 13 May 2012 18:07, Jeff Janes wrote:
> I think that pgbench should it make it easy to assess the impact of
> foreign key constraints.
I agree in principle. I favour being more inclusive about pgbench
options, even if the need for such options is only marginal, which
this isn't - I personally
Doing some beta testing, managed to produce this issue using the daily
snapshot from Tuesday:
1. Created master server, loaded it with a couple dummy databases.
2. Created standby server.
3. Did pg_basebackup -x stream on standby server
4. Started standby server.
5. Realized I'd forgotten to c
More issues: the pg_basebackup -x stream on the cascading replica won't
complete until the xlog rotates on the master. (again, this is
Tuesday's snapshot).
Servers:
.226 == master-master, the writeable master
.227 == master-replica, a direct replica of master-master
.228 == replica-replica, a cas
On 12 May 2012 01:37, Robert Haas wrote:
> Right. It's not a new feature; it's a performance improvement. We've
> had group commit for a long time; it just didn't work very well
> before. And it's not batching the commits better; it's reducing the
> lock contention around realizing that the bat
More issues: promoting intermediate standby breaks replication.
To be a bit blunt here, has anyone tested cascading replication *at all*
before this?
So, same setup as previous message.
1. Shut down master-master.
2. pg_ctl promote master-replica
3. replication breaks. error message on replic
On 13 May 2012 20:23, Josh Berkus wrote:
> More issues: the pg_basebackup -x stream on the cascading replica won't
> complete until the xlog rotates on the master. (again, this is
> Tuesday's snapshot).
This is already on the open items list:
http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_I
Many comment references to PGPROC and MyProc should now refer to PGXACT and
MyPgXact. This patch attempts to cover all such cases. In some places, a
comment refers collectively to all the xid-related fields, which span both
structures. I variously changed those to refer to either or both structu
On Sun, May 13, 2012 at 12:12 AM, David E. Wheeler
wrote:
> I need a constraint that ensures that a text[] column has only unique values
> -- that is, that there is no overlap of values between rows. I thought this
> was a made-to-order for an exclusion constraint. So I tried it:
>
> david=# cre
This code is our pre-9.2 group commit implementation, pretty much in
its entirety:
if (CommitDelay > 0 && enableFsync &&
MinimumActiveBackends(CommitSiblings))
pg_usleep(CommitDelay);
This code is placed directly before the RecordTransactionCommit() call
of XLogFlush(). It seeks t
On Sun, May 13, 2012 at 7:17 PM, Peter Geoghegan wrote:
> Have I missed something? Why do we keep around this foot-gun that now
> appears to me to be at best useless and at worst harmful? I can see
> why the temptation to keep this setting around used to exist, since it
> probably wasn't too hard
Hello, I've returned from my overseas trip for just over one week.
# and I'll leave Japan again after this...
> > restorePtr <= replayPtr <= receivePtr
> >
> > But XLByteLT(recievePtr, replayPtr) this should not return true
> > under the condition above.. Something wrong in my assumption?
>
> Date: Fri, 11 May 2012 15:59:51 +0200
> From: s...@keybit.net
> To: robertmh...@gmail.com
> CC: kevin.gritt...@wicourts.gov; a...@cybertec.at; j...@agliodbs.com;
> and...@anarazel.de; alvhe...@commandprompt.com;
> heikki.linnakan...@enterprisedb.com; cbbro...@gmail.com;
> neil.con...@gmail.co
Hi,
Recently we faced an issue with postgres server where it is throwing error:
ERROR: catalog is missing 2 attribute(s) for relid 16584
CONTEXT: automatic analyze of table "DBRNW.public.act_wsta"
I checked in the database and found that this table is not present but the
entry for the same is
That is, if you request FD_WRITE events for a pre-existing socket with
WSAEventSelect, you will not get one until the outbound network buffer has
been filled and then has partially emptied. (This is incredibly broken,
but Microsoft evidently has no intention of fixing it.)
I think you should di
On 14 May 2012 00:45, Robert Haas wrote:
> On Sun, May 13, 2012 at 7:17 PM, Peter Geoghegan
> wrote:
>> Have I missed something? Why do we keep around this foot-gun that now
>> appears to me to be at best useless and at worst harmful? I can see
>> why the temptation to keep this setting around u
On Mon, May 14, 2012 at 2:07 AM, Simon Riggs wrote:
> Keeping a parameter without any clue as to whether it has benefit is
> just wasting people's time.
No, arguing that we should remove a parameter because it's useless
when you haven't bothered to test whether or not it actually is
useless is wa
On 14.05.2012 02:17, Peter Geoghegan wrote:
One illuminating way of quickly explaining the new group commit code
is that it also inserts a delay at approximately the same place (well,
more places now, since the delay was previously inserted only at the
xact.c callsite of XLogFlush(), and there ar
On 14 May 2012 07:30, Heikki Linnakangas
wrote:
> That said, I wouldn't mind removing commit_delay and commit_siblings.
> They're pretty much impossible to tune correctly, assuming they work as
> advertised. Some hard data would be nice, though, as Robert suggested.
Those parameters were already
23 matches
Mail list logo
