> I'm getting this same error and wonder if Tom's fix is sufficient.
>
> IPPROTO_IPV6 is defined in wd2def.h IF _WIN32_WINNT >= 0x0501, but in
> pg_config_os.h _WIN32_WINNT is DEFINED as 0x0500 so
> IPPROTO_IPV6 is left
> undefined.
>
> Regards,
> Dave
>
> ---
> Unfortunatel
> Right now, I do this like this:
>
> if ($err =~ /name_of_first_foreign_key/) {
> $r->error_exit('First error message.')
> }
> elsif ($err =~ /name_of_second_foreign_key/) {
> ...
As an aside comment, a bit more regex foo with \b is indicated here :-)
if ($err =~ /\bname_of_first_foreign_key\b
> Which leads me to the same conclusion: anything as complicated as CASE
> is the wrong design. But perhaps for slightly different reasons.
What I like about the sql CASE is, that it is expression based, and thus
allows full flexibility in partitioning and is highly self documenting.
Do we nee
> Could the list admin please unsubscribe Andreas Zeugswetter from the
> lists until he can fix his vacation-responder-gone-nuts?
I am very sorry, fixed. I forgot to set nomail before setting the out of office
assistant
which my company requires me to do in this braindead way.
But I assume Exch
> > We should delayload this dll since it is only needed
> > for specific configuration. No need to install when it is not used.
>
> That would require building knowledge of DLL names into the code,
> which isn't practical as some projects have a habit of changing them
> regularly (e.g. gettext).
> I did re-install Tune-Up Utilities, Kaspersky, Holdem Manager
> and Daemon
> Tools, so those were probably not the problemcause since it's
> still working.
I think unfortunately it may be the case, that only initdb has a problem.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers
We should delayload this dll since it is only needed
for specific configuration. No need to install when it is not used.
Andreas
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Dann Corbit
> Sent: Friday, Februar
> > One more question I have though is:
> > How do you make sure noone (e.g. autovacuum analyze)
> > unfreezes tuples after the vacuum freeze ?
>
> I will start a new thread to answer this question, but the short answer
> is that the freeze only needs to happen in a fresh initdb database, and
>
> > > I would like to add a --freeze parameter to vacuumdb for use by the
> > > binary upgrade utility, and for symmetry with the existing VACUUM
> > > options; patch attached.
> >
> > Exactly what do you think the upgrade utility is going to do with it?
> > Surely not a database-wide VACUUM FRE
> Yes, I've had CC exported as xlC_r -q64 to do 64 bit builds, and use vacpp
> C++ instead of C. Guess it didn't like that, and ended up with some horrible
> compiler optimization or something that killed it.
Have you determined whether the problem is optimization or 64bit ?
> Are there any othe
> > So if this is a compiler bug, it certainly isn't an obvious one. I'll dig
> > deeper to see how I can convince configure to use -qnooptimize.
>
> Set CFLAGS in its environment. The default is set in src/template/aix
> CFLAGS="-O2 -qmaxmem=16384 -qsrcmsg -qlonglong"
>
> > When I've use
> > I don't think partitioning is really the same thing as row-level security.
>
> Of course not, but it seems to me that it can be used to accomplish most
> of the same practical use-cases. The main gripe about doing it via
> partitioning is that the user's nose gets rubbed in the fact that the
> There is another thing that's bothering me, though, which is that the
> present approach to dumping rules isn't adequate. Consider the
> following scenario:
>
> 1. You create a view that the system considers updatable, so
> it creates
> some automatic rules.
>
> 2. You don't want those rules
> You don't want to just
> modify pg_standby to accept small files, because then you've made it
> harder to make absolutely sure when the file is ready to be
> processed if a non-atomic copy is being done.
It is hard, but I think it is the right way forward.
Anyway I think the size is not rob
> >> So, barring objections, I'll go make this happen. What do we want to
> >> call the intermediate constraint_exclusion value? The first thing
> >> that comes to mind is constraint_exclusion = 'child', but perhaps
> >> someone has a better idea.
>
> > Not a huge fan of 'child' since it implie
> Logically, "xmin horizon" conflicts could be flexible/soft.
> That is, if we implemented the idea to store a lastCleanedLSN for each buffer
> then
> "xmin horizon" conflicts would be able to continue executing until they
> see a buffer with buffer.lastCleanedLSN > conflictLSN.
I think the tro
> it's look well, but I still prefer some combination with =
>
> name: = ''
> name: => '''
> :name = ''
> $name => ..
> $name = ..
I wonder about name := ''.
:= is used in Pascal/Ada to assign a value. Or would that again be an allowed
operator in pg ?
Andreas
--
Sent via pgsql-hackers mail
> If we use some type of integer, I suggest using this structure for
> pg_security:
>
> CREATE TABLE pg_security(
> relid oid,
> secid int2,
> secacl aclitem[],
> secext TEXT
> );
>
> This allows the per-row value to be a sim
> > > > > Ah, that is a good point, that if we have "security
> column" which is
> > > > > usually null then we are requiring the NULL bitmask.
> >
> > Yes, I think that would not be optimal, thus I think "WITH
> > SECURITY_CONTEXT" is needed.
> >
> > > I sure wish others were adding ideas to th
> > > Ah, that is a good point, that if we have "security column" which is
> > > usually null then we are requiring the NULL bitmask.
Yes, I think that would not be optimal, thus I think "WITH SECURITY_CONTEXT"
is needed.
> I sure wish others were adding ideas to this discussion.
One such idea
> > * pg_last_recovered_xact_xid()
> > Will throw an ERROR if *not* executed in recovery mode.
> > returns bigint
> >
> > * pg_last_completed_xact_xid()
> > Will throw an ERROR *if* executed in recovery mode.
> > returns bigint
>
> Should these return xid?
And shouldn't these two be folded togeth
> The user running initdb (or the postmaster) needs
> SeCreateGlobalPrivilege - which is something we cannot really start
Why not ? Doesn't the pg installer already tweak the permissions of the
installation user. On XP you can connect to session 0, so that is an
alternative on XP.
> telling peo
> > We already have an optional OID system column that can be specified
> > during table creation (WITH OIDS). We could have another optional oid
> > column (WITH ROW SECURITY) called security_context which would store the
> > oid of the role that can see the row; if the oid is zero (InvalidOid)
> > I wonder whether the cancel can be delayed until a tuple/page is actually
> > accessed
> > that shows a too new xid.
>
> Yes, its feasible and is now part of the design.
>
> This is all about what happens *if* we need to remove rows that a query
> can still see.
I was describing a procedure
> Simon Riggs wrote:
> > 2. Master ignores Standby's OldestXmin
> > Effects:
> > * Long running queries on standby...
> >Have no effect on primary
> >Can delay apply of WAL records on standby
> > * Queries on standby give consistent answers in all cases.
>
> Just for clarification, if you
> > Don't understand. I am referring to the logic at the top of
> > AdvanceXLInsertBuffer(). We would need to wait for all people reading
> > the contents of wal_buffers.
>
> Oh, I see.
>
> If a slave falls behind, how does it catch up? I guess you're saying
> that it can't fall behind, because th
> > > Proposal: Make the first block of a seq scan cost random_page_cost, then
> > > after that every additional block costs seq_page_cost.
+1
> AFAICS the cost cross-over is much higher than the actual elapsed time
> cross-over for both narrow and wide tables.
Which makes absolute sense, since
> If you accept the idea that column identity should be based on column
> name, then the only two operations that are really necessary are
> "CREATE OR REPLACE VIEW" and "ALTER VIEW RENAME COLUMN", and it is
> 100% clear what the semantics of those operations should be.
+1
I think this would be
> > Changing statement result type is also currently prohibited in
> > StorePreparedStatement. There maybe good reasons for this,
>
> How about "the SQL spec says so"?
Prepare time is often also the time when you bind the result, or more
generally set up the code to handle the result.
Generally
> > I think for low ndistinct values we will want to know the exact
> > value + counts and not a bin. So I think we will want
> additional stats rows
> > that represent "value 'a1' stats".
>
> Isn't that what our most frequent values list does?
Maybe ? Do we have the relevant stats for each ?
But
> Obviously we run into problems when
> a) we have a poor estimate for ndistinct - but then we have
> worse problems
> b) our length measure doesn't correspond well with ndistinct
> in an interval
One more problem with low ndistinct values is that the condition might very well
hit no rows at all.
> So right now I'm thinking I like my original proposal
> http://archives.postgresql.org/pgsql-hackers/2008-05/msg00357.php
> with the exception that we should go with
> SQLSTATE 'xyzzy'
> as the syntax in EXCEPTION lists. Also I'm willing to go with
> ERRCODE rather than CODE as the name o
> > Do we want the following:
>
> > 1. pg_dump issues "set statement_timeout = 0;" to the
> database prior to
> > taking its copy of data (yes/no/default-but-switchable)
> > 2. pg_dump/pg_restore issue "set statement_timeout = 0;" in
> text mode
> > output (yes/no/default-but-switchable)
> >
33 matches
Mail list logo
